Quote from Scawen :

Left or Right mouse button?

IMO, left mouse button is more natural as it is more universal.
For example, left will select text in a browser and right won't. Also, right is usually used as an alternative function, whereas in this case the ctrl+click selection would be primary.

There may be something funky with filesystem permissions preventing LFS from reading/writing some things properly.

The driver names are just .ply files in LFS/data/misc - you can try checking permissions on the offending file or, failing that, rename it.

Quote from Scawen :

Strange that you are the only one to report that error (so far). I'd better include a more informative error message in that case.

It was also reported here

There seems to be a bug with the LCS_ constants - in InSim.NET, LCS_HORN_5 has the value 2162696, but should be 327688.

To avoid some of the confusing magic numbers, you could define the horns by shifting:

Quote from BeNoM :

[...]
Even if they did change the collision model, you wouldn't go "flying" you would just get hit normally with invisible parts of the car or you would morph through a car a tiny bit.
[...]

Wrong.

If your VOB collision is smaller than the original (which can be a significant difference btw), then your car will not slow down until your car (on their screen) is actually inside the other player's. Due to internet latency and relatively low packet rates, your car can be inside theirs a significant way before their collision detection responds.
When the detection triggers, it will then push the other player's car away - how fast depends on how far your car was inside theirs. If it's more than a few inches, that can be quite fast.
You can test this effect by deliberately warping cars in to each other - there are a few ways of doing that without needing mods.

LFS uses some pretty good prediction to minimise or even eliminate this under normal circumstances, when collision meshes are synchronised. However, if the meshes are different across clients, it doesn't really work any more.


Even if the collision is slow enough to not cause significant warping (very difficult with internet latency), it is possible to push the other car away without it appearing to even touch yours on your screen.
In servers where there is close racing or other contact, that can give a clear advantage - if you can push them and they can't push you - and will ruin everyone else's enjoyment.


I've been admining servers where this has been a significant problem for several years. To the untrained eye, the problems often look like lag hits, but there are other clues and ways of testing for problems.
It's less of an issue these days now most collision mesh changes are caught by the new-ish OOS checks, however there are still some problems either due to certain VOBs/hacks bypassing the checks somehow, or when cars are damaged. The former was more common soon after the OOS changes, but I'm sure there are still a few around.



*The way the collisions work between different players with different apparent collision meshes is quite complex and hard to explain - I've probably missed something out.

First replay shows both the roundabout and bridge I posted videos of.

Second replay shows the one from crazyboy's second image - I haven't been able to reproduce the other one.

Last edited by Degats, Sun, 22 Jan 2017 15:09.

Quote from Scawen :

How do you make that happen? I may have a way to deal with this but to help me spend less time, I'd like to know a quick way to see these bad cases of vanishing ground.

If you drive towards the roundabout from the western outer road, it happens basically every time: https://youtu.be/Xr1nTJVUoP4

There are a lot other places where a small area doesn't load in fast enough, but it happens so fast you only really see a flicker. I spotted a few while driving around, but most don't happen the second time through.
I also had it happen quite badly, where most of a bridge didn't render until I was a couple of feet away, but I can't reproduce it now even by re-tracing my route.

Edit: Caught it from the replay: https://youtu.be/-yeBGBV4shU Happens if you stick to the far left of the bridge after joining from the track and hug/cut the apex onto the bridge - it won't do it if you go too far right at any point.

Also spotted a gap in the skidmarks while trying to reproduce:

Last edited by Degats, Sun, 22 Jan 2017 01:23.

Quote from pik_d :

Are you saying that the new tire physics are related to editor functions, or that you wanted to update Eric's build a single time after you had both physics and editor functions ready? I'm a bit confused if the two are somehow linked or not.

My guess is that Scawen wouldn't want to give Eric a broken version of the physics that would prevent him play-testing whatever he's working on. (Assuming the editor is part of/intertwined with the main game code somehow or would otherwise make changes incompatible)

Edit: To clarify, I wouldn't think Eric would need a new version for every physics change, but it would need to generally be in a working state when giving Eric updates that he needs.

Last edited by Degats, Wed, 4 Jan 2017 23:44.

Quote from leviii94 :

people know that a lot of kids play this game , now tell me what can I make.. I get 9 pounds a week converted from ron (50) that is 4 weeks without money and you'd say sure you can make that money but tell me now how the hell do I get a credit card at 16 to be able to buy the game.and no, parents don't have those kind of cards

£9/week is 4 times what I got at 16 and I managed to save up for games I enjoyed (like the Half-Life black box, which was about £35 at the time - over £50 today, adjusted for inflation).

As for the credit card argument - you can put money into PayPal from a bank account, which you can either do yourself if you have one, or ask your parents/guardians/etc to do it for you and give them the money. Usually they'll be more than happy to help you if you've put the effort in to save for it.

If you try hard to save money (which doesn't have to be all you get, you can put aside part of it each week), it's much more rewarding when you finally get what you've been working towards.



I won't lie, I've pirated games in the past but for things like LFS, which I've enjoyed who knows how many thousands of hours of playtime, the £36 (plus hundreds of extra skin slots paid for) has been more than worth it several times over.

I noticed something regarding the wing-mirrors: The adjustments are based on left and right mirrors, which means when you swap sides of the car the adjustment is out. Normally, you'd have the two sides adjusted differently, because of the angles.

IMO it would make more sense for the driver's side adjustments to stay on the driver's side regardless of which side the driver is on (i.e. swap the left and right adjustments).

Quote from Scawen :

Yes, it is independent. It depends on the mirror's width and your position relative to it. The central mirror is flat and the side ones are convex.

Ah, that explains a lot - I was about to suggest a different FOV for the central mirror in particular.

IRL all car mirrors are convex; the wing mirrors moreso than the centre.
In my experience in road cars, the central mirror is generally tuned to more or less show the full view out the rear window*.
Full fat race cars tend to have very wide convex central mirrors to give a bit of a view out the rear side windows as well to account for limited head movement. Probably not such a big deal in LFS.

The current mirrors, especially the centre, seem a bit distracting to me because there's more movement of the world when cornering than I'm used to IRL. It's much more noticeable now there are nearby reference points.


*Corsa C is precisely matched down to the shape, even accounting for stereoscopic vision; Focus Mk.II IIRC is about right for height but slightly narrow; Meriva B is slightly small both ways.

Last edited by Degats, Tue, 23 Aug 2016 21:11.

An update on the WOULDBLOCK tweak:

After ~7 hours of a (most of the time) full server, there were a total of 66 occurrences; the vast majority of which had sequentially increasing numbers (often 10+ at a time), so probably due to occasional lag/cpu spikes. 11 were TCP instead of UDP.

Looks like the fix worked

Quote from Scawen :

I'm still working on the graphical update and hope to release a compatible test this weekend.

FOR HOSTING ONLY

For hosts, if you have experienced the WOULDBLOCK error, I have updated the first post with an update for the dedicated server.

The send buffer for UDP car position packets has been increased in size.
This may prevent errors such as "UDP ERROR (27) : WOULDBLOCK" on busy servers.

https://www.lfs.net/forum/thread/89703-Test-Patch-0-6P2

40 connections on a 6P2 server - so far so good, no WOULDBLOCK

(For reference, our stdout is usually >95% WOULDBLOCK messages on a full server)

I've just spent a few mins testing some of the controller stuff and it seems to work nicely.

I notice the steering limit is softer than the wheel's built in one. Not sure if that's even solvable by the game, but it does the job well enough as is

Quote from Scawen :

Today I did the auto-centering function.
...
I think this will be helpful as it does often happen that the wheel is rotated 360 degrees.

I managed to do that in a league race recently

While you're working in this area of code, how easy would it be to implement a soft-stop at full lock? (Useful when using turn compensation for a 1:1 wheel turn in any car without messing with settings)

Quote from Scawen :

The single controller selection is now done and is easy to use, as you can see in the attached screenshots.

That should be very useful for when I'm feeling lazy and use my 360 controller - I won't have to mess around unplugging my 3(!) other controllers


--------

Quote from SimulatorRental.com :

Anyone have one of the larger i7 processors?
Like the 6950x...
How many instances of LFS running a full grid race of AI, can you run on this chip, before the frame rates start tanking?

I wouldn't bother if I were you, many-core Xeon equivalents are generally significantly cheaper from what I've read. The Broadwell-Es are mostly for the bragging rights.

Quote from Scawen :

TEST REQUEST 1:

If anyone is around who has a game controller with combined trigger axes, please can you confirm this - if you use the triggers, the yellow/blue bar on the LFS screen moves in the 'wrong' direction. To the left when you use the right trigger, and right when you use the left trigger.

Confirmed. (XBox360 on Win10 64)

Quote from Scawen :

TEST REQUEST 2:

Also, does anyone have a joystick? Please can you tell me which way the yellow/blue axis moves when you move the joystick forward or back?

Left has no yellow, right is full yellow (Divider follows the expected direction).
Forward has no yellow, back is all yellow. (Divider moves left when pushing forwards)
LFS looks to set both axes correctly without me messing with any settings. All axes have invert 0.
Edit: In other words, a standard Joystick behaves in the same way as the two joysticks on the XBox360 controller.

Last edited by Degats, Tue, 12 Apr 2016 18:21.

Quote from Scawen :

I'll try to release N4 tomorrow afternoon so you can test them.

I wasn't paying attention and forgot they weren't available yet No rush.


Regarding calibration, being able to manually set min/max values would be very useful for all the worn out Logitech pedals that constantly flicker between 0~20% even when not pressed. The profiler's deadzone function is useless, because it adds the zone in the middle not the end(s).

Would it be feasible to be able to set a hands off "centre" point? For example, the rotation axis on my Saitek joystick never calibrated to the centre (it's waaay off), so I couldn't use it as a look axis.

Edit: I'll test how LFS interprets the joystick's axes tonight.

Quote from Scawen :

Of course, Logitech driver will then not stop your wheel turning past the limit of the in-game car. For me that's no problem. But if you want your wheel to hit the stoppers then you'll have to change it in Logitech settings and LFS "Wheel turn" to match.

Speaking of, how hard would it be for LFS to implement a soft stop instead of freely spinning past the car's limit?
I know some other games do it and it's quite helpful to have the soft stops while spinning wildly out of control


I'll test the Thrustmaster defaults tomorrow.

I think it's the way the Logitech profiler does its game detection - my G25 doesn't even load the Global settings until I either load a game it knows about or open the profiler window.

If you're wanting some default settings for other wheels, I'm about to test the Thrustmaster T300.
In the meantime for reference, the Thrustmaster T150, T300 & T500 wheels all have 1080 degrees (I have no idea about the T100/T80).

---

Right, so the Thrustmaster range is quite complicated because there are several different rims and buttons are labelled/positioned differently.

The various T300s report as "Thrustmaster T300RS Racing Wheel", I assume the T500RS is similar.

The following seem to be the same for all T300/T500 rims:

Last edited by Degats, Sat, 9 Apr 2016 21:23.

Quote from bobloblaw :

As far as managing different controllers goes, I think that most controllers will provide a serial number alongside the Standard USB Identifier (vendor-code:model-code), so maybe a .con file could be unique to each controller.

DirectInput does provide a couple of GUIDs, one for the device model (product) and one for the instance. The product one is unique to the manufacturer+model, but two controllers of the same model will share the same GUID. The instance one will be unique even if multiple of the same model controller are connected, but there's no guarantee that it'll be consistent for a specific controller if you plug into a different USB port (it probably won't) and it certainly isn't consistent across different machines/drivers.

I have no idea if it's possible to map a DirectInput device to the USB hardware information (which *may* contain a unique serial number, but rarely does) - I suspect not.


Regarding the combined axes on the triggers - IIRC you *have* to use XInput to be able to split the axes on the XBox/XBox360 controllers. I have no idea about XBoxOne.

Edit:
I've been messing around with DirectInput lately - I'll see if I can do anything useful with the X360 controller this weekend if I get time.

Last edited by Degats, Thu, 7 Apr 2016 20:48.

LFS automatically loads the layout with the most recent modified date.

/axload <layout> should bump the modified date of that layout, so the most recently loaded will be loaded next time.

Quote from Scawen :

It seems more like you need a way to switch on lights or sound a horn through InSim. Because the way it has to be done now sounds like quite a nasty hack!

Well, the basic principle of sending keys to LFS isn't too much of a hack, though it does require messing with some low-level windows APIs - I don't know if it even works on linux/wine.
The only available methods of avoiding problems however, are very hacky and don't even work reliably.
You do also have to be very careful about the flashing rates - go too fast and it won't show up properly (or at all) to other players in multiplayer.
There is also a small bug where if someone has the horn on when you join the server, you won't hear it at all until they turn it off and on again.


Anywho, rambling aside, if you're considering some InSim support here are some thoughts:

As Dave said, a built in lights pattern would certainly be more efficient - moreso than it is now - and more reliable in multiplayer. Similarly, built-in support for toggling the horn(s) should also be more reliable. Custom patterns with sane update rates may not be too bad though, as it would use somewhat less data and fewer packets than, say, MCI.
It certainly wouldn't be this level of insanity: https://www.youtube.com/watch?v=hKbyyC_M9vM

For the pattern itself, a simple 1-2Hz "wig-wag" for the front/rear headlights would probably be plenty, if possible. I'm personally not a fan of using left/right indicators because it removes the possibility of letting other players know your intentions. More complex patterns with multiple light sections would be nice, but I know that's opening another can of worms, so I wouldn't bother with that any time soon (probably something for a new lighting engine tbh).

A way for servers to prevent use of flashing lights/sirens for specific users, or at least some kind of InSim notification that they're active, would be very helpful I think.

I've discovered an annoying downside of the choice of "backspace" for the on-screen keyboard.

Various strobe-light programs(*1) will send a backspace key after every keypress to prevent it from spamming 37890 etc in the text input boxes while sending messages. The backspace method has thus far been the most reliable way of preventing this, as there is no way of knowing if a text input box is open.

I can think of a few potential solutions to this:

1. Use a different key for on-screen keyboard, or at least allow it to be changed (although the latter would mean that everyone using one of those programs would need to rebind it)
   
2. Provide some way in InSim/OutGauge to indicate when a text input box is open
   
3. Implement proper safety cars with an option to add a lightbar, flashing lights and siren(*2) for every road/tin-top car
   

I'm not going to get my hopes up for #3, but it would be nice


(*1) They automatically do flashing light patterns and hold down the horn key for a siren; popular in cruising (for police etc) and drifting.

(*2) Yes, the FIA safety cars used for F1 and other major international series do indeed have sirens.

Surely you only care if there are any cars in the 'red trigger', if not then any cars in the 'yellow trigger' otherwise set it to green?

Either way, you'd have to make sure the timing/trigger areas are enough to let a car safely leave if the light is only green for a short time before someone triggers it again.

Yes.