One final quality of life suggestion - especially useful when dealing with a lot of closely packed objects and spinning the camera round:

Would it be possible to mark/highlight the copied/source objects* somehow?
Currently, you can't tell exactly which source objects you are about to move with M. Also if you press O, it's not obvious that the source objects - which you can later move with M - are the newly placed ones rather than the originals.



* The UN-COPY buffer I think you called it - the ones still in the world, not in-hand

Works really well

Quote from Scawen :

Would it be helpful if the M key was allowed to work after you have pressed CTRL+C?

I haven't tried it yet but it seems possible. As you know, the CTRL+C is reversible because the editor knows which objects were copied. So it seems that in those cases where you have a tricky move as you described, you would then be able to see the originals and the new position at the same time before pressing M.

Yeah, I think that would help

I remember playing with that briefly several years ago - it was very lively to say the least

I have to agree that moving objects - especially if you're not 100% sure you actually want to move it yet - is a lot more complicated.

You either have to:

• ctrl+c, place a new one where you want and hope you can properly select the old one (and not the new one) if it's a tiny adjustment, which I can see being a real pain in some cases. This would be more of a nightmare if it's a multi-object selection as you'd then have to re-select every one of the old objects.
  
• or commit to moving it by doing ctrl+x and lose the original position if you can't find a better one.
  

Compare with the old behaviour: Click (immediately seeing if it's the correct selection or not), play around finding a better position, M to commit the new one or do nothing to give up.

An undo (ctrl+z) would help in the second case (and probably in other areas too), but even so it's more clunky than before. Unfortunately, I haven't thought of a nice solution that would work with the new split selection behaviour yet.


I'm yet to have a proper play with the rest of the new system, so I'm not going to say its worse in general, but I can see the move issue being a problem especially when trying to tweak "curved" sections where you have to be very precise and it's very easy to make things worse or make mistakes.


Edit:

Quote from chucknorris :

-Possible solution 2: Mark the selected object visually, i.e. with an outline ... So I can tell whether its a wall, floor, or line.

This would be really nice actually - it's something that a few games do with shaders. No idea how long it'd take to do however

Last edited by Degats, Sat 28 Apr 2018, 15:48.

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.