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.

Quote from Scawen :

Good point. The host does have that info so it should be possible to provide some info in a compatible version. I've added a note to consider it.

Thanks


While we're still in incompatible mode, any news/thoughts on per-player forced handicaps? Would it be too complicated to do in this patch cycle? Perhaps IS_HCP.Zero could be re-purposed to be UCID/PLID?

Quote from Scawen :

That would be a big discussion. People do like the ready system. For now if a player has gone AWOL it's probably better just to spectate him, so he doesn't end up on the grid while he's away.

In which case, would it be possible for insim to give some kind of notification of who is/isn't ready so this can be automated? (Or is it already possible and I've missed something?)

Quote from DarkTimes :

Yes, I meant those little portable start light things.

Anyway, I figured out the problem, you need to add the AXO_START_LIGHTS objects to a layout, save the layout and then reload it for them to start working. Maybe this was common knowledge, I don't know much about AutoX or the layout editor.

You don't have to reload, just press the optimise button (or set the flag if loading via insim). That was mentioned a few posts ago.

Sounds like a good idea to me.

It would also be very useful to have a special checkpoint that behaves in a similar way, perhaps including a timestamp of when the line was crossed.
Circles aren't always a convenient shape; having a straight line would make joker laps/alternate routes, multiple simultaneous races (especially with the timestamp), pit exit line enforcement (important for Rockingham especially) much easier.

Quote from Whiskey :

Couldn't we create a packet sniffer/rely that always outputs IS_MSO / IS_III / IS_ACR as full size so that outdated programs still work?

I had thought that some kind of relay would do the trick - it could even be very simple, as it would only need to bother converting packets with known problems.


Interestingly, both the InSim applications that I maintain seem to be able to handle these shorter packets fine (both are custom implementations written independently by different people, no third party libraries).
At first glance at the code, the CInSim (0.7) library should be able to handle them fine as well.

Airio was paid software (it had a pro version at least) and afaik, no source is available for the program itself. It appears to be linked against a custom dll, so I guess no source is available for the library either.

Similarly, the LFS External library has no source available, although that is horribly out of date anyway and people have been having problems with it for years. No idea if that'll work... probably not.

AFAIK, all other publicly available libraries are maintained or at least are open source.

First glance: Variable IS_III & IS_ACR are not documented in insim.txt (and no K10 -> K11 changelog)

I'll see if anything breaks later tonight if I'm still awake.

Yeah Dave, Scawen already mentioned that (post 4)

The far edges/corners; the parts you'd want to line up accurately with something else.
It might take a little longer to set up the prefabs, as you'd have to make a version with only those edge objects (perhaps by deleting all the others once you've captured the full prefab) but it would save a lot of time and effort in the long run.

+1 for the ability to fill the Shift+U clipboard using InSim - could be very useful for placing large prefabs with some finesse.

Prefabs wouldn't need to be limited to 30 objects either; you could load the objects at the extremities into the clipboard for easy alignment, then have InSim automatically add the rest of the prefab when you paste.

Maybe better to disallow the lap (not upload to LFSW or something) if the car has teleported during the lap?

Limiting the JRR behaviour would get complicated and is just going to restrict its potential uses.

Edit: Having said that, people can already use tweak to fake PB times, so maybe it isn't such an issue.

Quote from vitaly_m :

It is not pointless one! If he ends up editing setup after his car was already on the track, he will abuse the restrictions we want to enforce, so we need that extra final JRR

Changed settings aren't applied to the car after it's joined the track. The car on track will have whatever the original setup contained before editing started (i.e. the same as if you clicked undo). Therefore the first NPL will be correct.

Quote from Scawen :

I've made the IS_MSO packet have variable length. The maximum is still the same so the packet structure is not changed in any way. It's really a very simple change (one line) and should be very simple to fix external programs to handle the variable (usually smaller, never bigger) size. So I thought I should really do it for the IS_III and IS_ACR as well. Any objections?

My C++ based InSim can already handle all that - it honours the size byte, so incoming variable length packets should be no problem.

The CityDriving InSim will probably need tweaking, though I'd have to test it (a Java get() function may throw). If it does need changing, it should be very simple.


However, it's possible some old/no-longer maintained apps may not handle it well.
It won't affect me, but LFS External (which people should really stop using anyway as it's so far behind already) and Airio would need testing. They seem to be the two most common unmaintained apps afaik.

Found an issue (IIRC I mentioned this possibility the other day):

1. User is in setup/colour edit screen and /ujoin is called on that user.
2. Car is spawned on track (position determined by JRR). The player can drive the car, however the setup screen is still rendered on screen.
3. Player clicks OK, setup screen goes away and "<player> already has a car" message is shown in chat.

Edit: the above happens when the user starts from spectate. If they had done shift+p to get to the setup screen from the track, "User is already in the race" message is shown when /ujoin is called and afaict the car *is not* spawned

Last edited by Degats, Sat 30 Jan 2016, 17:51.

Quote from cargame.nl :

So eehh this JRR... What Index needs to be used @StartPos?

I've just been using zero for the Index so far and it seems to work ok. We're not actually dealing with layout objects, so Index doesn't really have a meaning.