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.
/axload <layout> should bump the modified date of that layout, so the most recently loaded will be loaded next time.
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) 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.
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:
- 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)
- Provide some way in InSim/OutGauge to indicate when a text input box is open
- Implement proper safety cars with an option to add a lightbar, flashing lights and siren(*2) for every road/tin-top car
(*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.
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.
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?
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?)
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.
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.
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.
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.
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.
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.
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.
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.
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.
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
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, .
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.
Even for practice/qualifying and custom race types? The ready system wouldn't *have* to be overridden, it just may be useful in some situations.
A timeout then spec can already be done using InSim, but if noone clicks ready, the session start can be delayed - then there are the people who insist on quickly joining every time, but never actually click ready, which the relies on an admin racing them and the latency to get the session started
And Rockingham has 3 independent circuits - they even advertise that capability (though one is missing a pitlane)
IMO, that's up to the admin/programmer to choose whether they want people to spawn on the start grid before a race or not if there's a chance they're not ready. It's not something that'll happen by accident if the server admins don't want it to.
The only problem I see is if /join is called while someone is actively editing/naming/renaming a setup or colours. In those situations it would be unwise to disturb the player IMO. I haven't thought of any other situations that could cause problems.
In Firefox and Chrome, F11 goes into full-screen borderless window mode on the current monitor (not the one with the most pixels - I've never seen that behaviour; maybe a coincidence because the monitor with the most pixels is usually chosen by the user to be the 'main' monitor?).
IMO, it would make sense for Shift+F11 to mimic that behaviour (full-screen borderless window on the current monitor), Shift+F12 for full-screen borderless window across all monitors, and keep Shift+F4 for exclusive full-screen toggle on the main monitor.
FWIW, full-screen toggles are very inconsistent across windows applications - common ones are F10/F11 (and combinations with modifiers), Alt+Enter, <modifier>+Space and I'm pretty sure I've seen something other than LFS use something and F4 as well.
As an aside, I currently have a two monitor setup, but with different sizes/resolutions. I wonder what the "all monitors" mode would do on this kind of config.
IMO, it would make sense for Shift+F11 to mimic that behaviour (full-screen borderless window on the current monitor), Shift+F12 for full-screen borderless window across all monitors, and keep Shift+F4 for exclusive full-screen toggle on the main monitor.
FWIW, full-screen toggles are very inconsistent across windows applications - common ones are F10/F11 (and combinations with modifiers), Alt+Enter, <modifier>+Space and I'm pretty sure I've seen something other than LFS use something and F4 as well.
As an aside, I currently have a two monitor setup, but with different sizes/resolutions. I wonder what the "all monitors" mode would do on this kind of config.
FGED GREDG RDFGDR GSFDG