The online racing simulator
Incompatible test with many InSim updates
(207 posts, started )
Quote :A stopwatch per player? Do you mean so they could see their own custom clock on their screen, so as if each player can have a different race start time? I'm not sure what you mean by TimeSpan data.

Yes, exactly!

Quote :Allow the host to know if a certain connection is in the garage, even if he does not currently have a player in the race...

+1

OFF-TOPIC suggestions:

• One small annoyance concerning IS_ACR. It is useful to use IS_ACR to log all sort of things such as kicks and bans.
The problem is that when an admin uses the kick & ban buttons in the connections list (N) no IS_ACR is triggered.
Is there no improvement possible there? For example, when clicking these kick & ban buttons, sending a /kick & /ban command instead so that it is caught in IS_ACR or is that a rather ugly fix?

• Ability to fill the array of ObjectInfo the SHIFT + U editor uses to move a group of selected objects. At the moment when you have a group of objects you want to move with InSim, you have to use IS_AXM each time you want to move that group of objects till you reach the position you want. It is annoying and frustrating knowing usage of the mouse cursor in SHIFT + U mode to move your group of objects would make things so easy! It might not even require a new packet:
1) Fill your IS_AXM ObjectInfo Info[30] with your objects data.
2) Send the IS_AXM with a special PMOAction byte, for example: PMO_FILL_OBJECTS,
3) Attach objects to mouse cursor in SHIFT + U (just like you would select objects from a layout)

This would improve the versatility of IS_AXM and the autocross editor greatly in my opinion.
Quote from Degats :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.

Maybe I messed up a bit, but I remember following thing with my setup enforcing system with k10:

(in lobby)
enter to pit
select proper setup
type /join => success
make set with restricted setting
press "OK" => denied
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

As Degats says, this one is pointless.

There are 3 kinds now.

1) Player tries to join race, sends join request <- we need this
2) Player in race goes to pits, and exits pits, sends join request <- we need this
3) Spectating player in garage joins race by /join or /ujoin, sends join request <- we need this, it's the same as (1)
4) Player after (3) exits garage, sends join request <- we don't need this, it does not refer to his actual car, it is false info
Quote from vitaly_m :(in lobby)

Thanks, I see that the behaviour in lobby is different from in game.

In game if you exit pits when you have a car on track, that car does not change. But in the lobby it does change.

Tomorrow I'll check those cases separately and make sure they always do a join request at the right times but not at the wrong time. Smile
Quote from Degats :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.

Someday it will fail too much anyway, it's already having symptoms (no REO, no Rockingham WR support). If there are more track releases it will further degrade. I think it's good to move on at some point. If this is the right time I don't know. Creativity seems to be now so lets not be on the brakes.

If it's really an issue to be compatible with older style InSims, why not make a switch to be in an older InSim protocol mode if desired. Later always can be decided to remove the old style completely, also better for server admins that they not totally freak out (like me) with an unexpected change on a terrible time where there is limited time to make adjustments.

Some software has this; a warning, this mode is deprecated and will be removed in next version.
Yeah.. I already was a bit afraid this behavior was possible (see replay)... How is this fixable? And isn't it better to only allow reset/teleport while stopped?

Still don't understand why its necessary to have teleport functionality while on the track (?). Maybe it's funny in open world mode but on official track combo's? People going to abuse this, I am sure.

* read some comment about marshall moving a car simulation. Alright, but isn't it an idea to set limits to the amount of X/Y movement possible from current MCI location? Like 5 meters or something. If desired sending more then one JRR but not that much you can spam-respawn yourself around the track... Getting a bit complicated altogether.
Attached images
Image1.png
Attached files
bla.mpr - 73.9 KB - 188 views
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.
use tweak to fake PB? Tweaked servers are not included as official servers. If you mean speedhacks then well yes it does exist but then you still need to drive yourself. If you abuse this function you only need to put a rock on your key and let the car drive the straight bits and the area's where split sectors are, over and over again. Granted, you need to have some disorder to do this. This function does give me a Delorean feeling though.

Suggestion: Is it OK to add an extra flag/bit so at least the current car reset can be mimicked better? (Car has to be stopped to use reset / car doesn't need to be stopped).

Quote from sicotange :It is annoying and frustrating knowing usage of the mouse cursor in SHIFT + U mode to move your group of objects would make things so easy! It might not even require a new packet:

Hold the CTRL button while clicking the objects you want to move and press M afterwards on the new mouse location?

Or even copy from a different layout.
I'm well aware of that. That's a useful LFS feature but my suggestion is InSim related.

Say you made a big curve (consisting of 30 wall objects) you use for race layouts. You want to use that curve again and again on several tracks. You will have to select all the 30 objects again when you "unselected" them (by adding another object to your layout for example) which is a waste of time.

If you could load objects (with InSim) and attach them directly to the mouse cursor in SHIFT + U (the behaviour you described above basically) it would make things easier. You would save your objects with your InSim application. Display a list of these groups of objects. Choose the one you need then instruct LFS you want to attach them to the mouse cursor so you can put them where you want too. It makes it a breeze to reuse a group of objects you need frequently.
+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.
Quote :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.

Can you elaborate? What do you mean with the extremities?
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.
So it's known that JRR spawning doesn't work from lobby screen? JRR can block/allow joining the grid but actual spawning of the person is on the normal grid after the go.
Yeah Dave, Scawen already mentioned that (post 4)
Ah yeah.. Thanks. Because of possible custom grid slots, I see.. Okay.

--
Still not that happy about teleporting.. It also doesn't generate an HLV; http://stats.airio.eu/BLS.aspx?T=RO3&C=XRT .

..
Hmm, not sure what happened or how to repeat it. I changed track from BL1Y to AS4Y, and when I joined I spawned at the point that camera points when there are no cars on track instead of at a pit start point. There was no insim connected at the time, though it had been running (with the new ISF_REQ_JOIN flag) before the track change.
When there are no cars on track, the camera points at the pole position grid slot. So from your description it just sounds like you entered the race with some laps set (not qualifying or practice) and spawned on the grid as expected. Uhmm
I guess you are right. Didn't expect it as it had the cruise flag set. Sorry to bother you!
No problem! Thanks for looking out for bugs.

I expect to release another incompatible update here today with some more things done.
New update K11 in first post:
https://www.lfs.net/forum/thread/88999

Changes from 0.6K10 to 0.6K11 :

InSim :

IS_MSO / IS_III / IS_ACR message out packets now have variable size
IS_BFN can now be used to delete a range of buttons with one packet
In game spectate then SHIFT+P and type /join - message is now shown

Start grid controls :

Start grid clear button is now available in multiplayer for admins
Add to grid buttons for admins beside names in list of connections
New arrows to move grid positions - removed "swap position" button

Fixes :

Player with car in game leaving pits no longer sends a join request
In 0.6K10 the IS_MTC Msg To Connection with UCID 255 did not work
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.
Thanks. I'll add it.

The IS_III and IS_ACR text size can be 4, 8, 12... 64 and so the packet size can be 12, 16, 20... 72

They can be smaller than before but not bigger, so it should be very small changes to support them.
-
(DarkTimes) DELETED by DarkTimes
Quote from Scawen :
IS_MSO / IS_III / IS_ACR message out packets now have variable size

Well.. This is the end of Airio. It kills it (directly).


16.02.02 23:15:37 #7 AEGIO ERROR : System.ArgumentException^M
length^M
at System.Array.Copy (System.Array sourceArray, Int32 sourceIndex, System.Array destinationArray, Int32 destinationIndex, Int32 length) [0x00000] in <filename unknown>:0
at LiveForSpeed.InSim.Aegio.Decoder.GetBytes (System.Byte[] pak, Int32 fir, Int32 len) [0x00000] in <filename unknown>:0
at LiveForSpeed.InSim.Aegio.Decoder+IS_MSO..ctor (System.Byte[] packet) [0x00000] in <filename unknown>:0
at LiveForSpeed.InSim.Aegio.Event+Message..ctor (System.Byte[] packet) [0x00000] in <filename unknown>:0
at LiveForSpeed.InSim.Aegio.Connection.ListenTCP () [0x00000] in <filename unknown>:0
16.02.02 23:15:37 #7 Stopping thread : Aegio - xxx.xxx.xxx.xxx:xxxxx - TCP Listener

PRISM Also having issues with this but I wait a little bit with changes until I get confirmation that this is the desired route to go. Whats the goal of these var packets. Only bandwidth saving? Not enough reason to break old InSIm programs in my opinion.
But how hard can it be to change one line of code?

Instead of checking that size==72 you just check that size >= 12 && size <= 72

The unmaintained programs, is their source code not available?

EDIT: I realise that due to the way things are implemented, it may not be one line of code in all cases, but still it should be very easy changes.

EDIT2: We can't really be bound to the past, trying to keep LFS working with software that has lost its source code. Such software is basically doomed anyway.
Yep, it's doomed. Agreed. But no, it's closed source. I haven't tried TV Director yet and other programs but I expect similar problems.

Incompatible test with many InSim updates
(207 posts, started )
FGED GREDG RDFGDR GSFDG