Edit: By the way, initially I misread your question and thought you were asking for the original image rather than the original creator. I did spend a little time trying to find the original source but only came up with not very legitimate looking "free" clipart sites that did not appear to give proper credit in any of their images (like this one, for example).
Made another small little adjustment so that line breaks (<br>) are not stripped from the feed. I took me 5 years to realize that I had made a mistake. But now long posts are easier to read. I use Flym but it should work equally well in Feedly and other RSS readers.
Yeah, no. I won't. I stand by my previous conclusion.
Also, I just noticed another Feedly "quirk" It doesn't display post times correctly. Rather than displaying when a post was published (as described in the <pubDate> element), it displays the time the was received (eg: when Feedly refreshed my feed).
Perhaps you've noticed that both entries in your notification appears to have been posted "8 minutes ago" when, in fact, they were posted an hour apart. Perhaps that may add to the confusion.
Edit: For my own piece of mind I'll post each visit by Feedly's "fetcher" bot throughout the day:
Feedly just refreshed (after being idle for about 3 hours), and like clockwork the notification(s) appeared in Feedly Notifier. The posts that eclipsed and gu3st created meanwhile did not trigger any notifications.
Also, now that Feedly has refreshed it might have read the ttl setting that I had added since the last visit. if Feedly does in fact adhere to that setting the somewhat arbitrary reresh intervals should be fixed too. We'll see.
Edit: Nope. Looks like Feedly will update whenever it feels like it:
Right now we have a "pending" post by Scawen posted at 18:47. Oops, actually two (another one at 18:51). They have already been added to my feed, but they're not showing up in Feedly yet (the time is 19:01). It'll be interesting to see when they're added to Feedly (I'll see it in the access logs) and when the notification appears.
Note that pressing the refresh button in Feedly won't actually make it refresh the feed. It's just a GUI thing.
Edit: I went ahead and added the <ttl> element. Hopefully it'll make Feedly refresh more regularly.
Again, that's just a coincidence. Neither my feed or Feedly knows when someone posts, so notifications can not be triggered by such an event - The information simply isn't there (unless Feedly has created their own scraper for lfsforum.net and - for some reason - concatenates it with my feed. But that would be some next-level insanity )
That said, once I get around making the fix I mentioned earlier, I'll add an <ttl> element indicating that aggregators such as Feedly should update more regularly.
Anyway. When I find the time (probably tomorrow) I'll make a little adjustment to the feed to correct a small issue I noticed with Feedly. The item title (as well as the "Visit Website" button that appears when you expand an item) leads nowhere rather than to the post. This happens because Feedly (to me, incorrectly) uses the Feed's <guid> element rather than the <link> element as the reference for the links.
I suspect that this change will cause a large number of duplicate items.
Basically, my "scraper" visits the forum, searches for posts by Scawen (as well as Victor and Eric) and adds the content of the posts to a RSS feed.
I wasn't familiar with with Feedly or the Feedly Notifier extension, but after looking at them quickly I gather that it'd work something like this:
The scraper visits the forum and searches for developer posts.
New posts are added to the "original" RSS feed.
In Feedly, you've added the RSS feed as a source, effectively creating a "copy" of the feed.
In Firefox, you've installed Feedly Notifier and logged in with your Feedly account, allowing the extension to monitor Feedly's copy.
So, when a new post is added to the original RSS feed, Feedly adds it to it's own copy, and finally Feedly Notifier displays a notification in Firefox / your desktop.
Since I can't find any posts by Flotch in the original RSS feed (view-source:https://www.liveforspeed.se/lfsdev-rss) or in Feedly (see screenshot) the problem must be with the Feedly Notifier extension -- Though I did not get any notifications from Flotch when setting it up in Firefox.
Since the posts sometimes contain HTML (for example when people are quoting or including links or images) I would not be surprised that certain parsers may interpret the feed incorrectly, but since the feed does in fact validate I can't really think of something I could do differently.
That said, I'll keep the Feedly Notifier extension in Firefox for a while and keep an eye on it.
Edit: Would you too please log in to Feedly and check if any posts by Flotch are showing up there? If not, the problem is most definitely with Feedly Notifier.
Hmm .... As I understand it, LFS doesn't know/care whether the PS3 controller is connected via USB or Bluetooth -- If the device is indeed properly paired and it works with other games with just a Bluetooth connection you should be good to go, without having to mess around with sixad/sixpair.
Can you please confirm whether jstest registers input from /dev/input/js0 (or whatever device the PS3 controller is registered as)?.
If you have been able to successfully pair the PS3 controller as a device with the OS (you can test this with the "jstest" utility, for example), LFS should not have any problems using the controller -- But you need to configure the axes and buttons manually. Instructions can be found on the wiki.
I did a quick test with my Playstation 3 controller. With USB, it worked out of the box. But with Bluetooth, however, it would not pair without some hassle (this a problem with Ubuntu, not LFS).
That said, I was able to get my PS3 controller working with a patched version of the "sixpair" utility. I followed the "For older versions of RetroPie" instructions which were rather straight forward.
In the attached screenshot, LFS using using my PS3 controller connected via Bluetooth.
What do you mean by output, exactly? Are you simply referring to the physics simulation or are you thinking of OutSim and/or OutGauge?
As for the simulation, sure. Each tire may, individually, slip/loose traction when accelerating, braking or turning, and many parameters such as surface, tire type, tire temperature, whether the tire has dirt on it or not and so on may also result in loss of traction for each individual tire.
You can use the Forces View (F) and Tyre temperature/wear & clutch temperature display (F9) to verify this.
The Brakes section of the Advanced Setup Guide has an example of how the Forces View can be used to determine that the brake balance is set too low, forcing the rear wheels to lock up/loose traction while the front are still gripping, for example.
Thank you for doing these! Not only do I personally enjoy these comparisons, but they, along with ScaViEr's progress reports, are also valuable when I (once a year) get in touch with the sponsors of liveforspeed.se. Showing them these comparisons and a summary of the progress since the year before is an effective way to show them that LFS is still very much alive and it's worth keeping the website online.
So it's broken, huh? Would you please reach out to the maintainer (mmtrt) and create and issue describing the problem you encounter installing the snap? Having a broken LFS installer in the Ubuntu Snap Store doesn't benefit anyone. I suppose creating an issue in his GitHub repo is the way to do it.
Edit: As for this configuration:
// optional: local specified ip address //ip=xxx.xxx.xxx.xxx
I haven't managed an LFS host in years, but I'm guessing /ip= is the equivalent of "listen on" or "bind to" configuration options seen in most server software. Meaning that you should specify the IP address of the interface that you wish to accepting incoming connections on.
For example, consider the following:
ifconfig | egrep 'flags|inet '
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 33152 inet 127.0.0.1 netmask 0xff000000 em0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500 inet 213.x.y.z netmask 0xfffff800 broadcast 213.x.y.z em1: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500 inet 192.168.0.3 netmask 0xffffff00 broadcast 192.168.0.255
In this case, em0 is my external IP. If I was to configure an LFS host to accept connections from the Interhet, I would specify that IP. em1, on the other hand (obviously) is the IP address on the LAN, so if I was to accept only connections from the LAN, I would specify that IP.
I'm guessing that since this configuration is optional, leaving it commented out would bind the host to 0.0.0.0, meaning that connections would be accepted from either interface. So I'm not really sure if it's necessary for you to worry about that setting at all.
Edit 2: Alright so I was right about the /ip= setting. the host does bind to the IP address that you specify, eg: