Quote from Neilser :

Umm, I just assumed we were talking about an insim doing this, not a human...

Yes, but it sounds like a good idea to implement the 'add to grid' buttons for admins natively.

True, that would be very cool.

I've fully implemented the NPL with zero NumP as a join request, and the InSim program can reply with Allow or Disallow. That's done and tested. The spawn position option still needs to be implemented. This seems simple in the case where a spectator is joining the race in game.

It is more complicated to deal with the case where a pitted player, who is already in the race, wants to leave the pits. It seems to me that ideally the join request should be sent in this case too. Otherwise there will still be a case for car reappearing and instant spectate, that there is no more reason for in the case where someone joins the race. Unfortunately there simply is no join request in this case, so I'm looking right now to see if I can change the internal packet sequence to allow this. This would also allow the external program to (optionally) determine and specify the spawn position for that player returning from the pits.

If that turns out to be possible, then there is no need to actually STORE starting positions in players. The InSim program would just send the start position any time, if it wants to, on fresh join or return from pits. Also the 'teleport' case is still to be coded but that seems simple too. I hope to allow teleport without car fixing as an option, that could allow stuck cars to be brought back into the race.

So far, so good, but there is still one more case. Where people will start when they enter from the lobby screen. Without the ability to STORE start positions in players (i.e. specify a start point for all subsequent joins) there is no mechanism to specify the start point for players on the grid, entering from the lobby. But maybe that does not matter. You can do something with autocross start positions if you want to control where they appear when they've all clicked "ready". Or you could quickly teleport them to new positions after entry (though this is maybe a bit messy).

Does that make sense? The idea of actually storing start positions in players could be useful but may cause its own problems, so that's why I'm trying to avoid it.

I did manage to get the join request working for Garage exit too (for already joined players who may have changed their car or settings). Not finished yet, partially working but it should be OK.

As all this stuff looks good, and with the programmers and other people here showing a lot of interest and coming up with good suggestions, I've decided not to rush this, and just work to the full release next weekend. We can do some tests between now and then, but I don't have to finish all these things by tomorrow afternoon!

Eric's fine with that as he is working on other things anyway. Victor is around next weekend too so it looks fine.

Tomorrow morning I'll round up where we are with these things and what I plan to do, and start a new thread for us to discuss that in the programmer section.

concept teleport:

while (player exists) {
join request
set start position to track (layout)
answer request
//-------------------------
//player standing at position that we set by layout
offset start position for nex player
}

Week extra time for these kind of changes is a good idea.

Won't there be performance issues when you spawn many players at once? Do you leave it up to the programmer to make his own safe system? I'm thinking of IS_AXM where you wait for the arrival of the packet before you send the next one.

At now for buttons (BTN) sends lots packets. Who see performance issues? In this method don't need periodically send packets

Talking about buttons ... I think a packet to delete range of buttons would save lots of LFS<->InSim bandwidth. Eg delete range from 200 to 220. Also sometimes when closing menus, you can see couple of buttons left for the next few frames.

Not range, but array

Quote from repeat83 :

Not range, but array

A range only needs 2 bytes, an array is variable. InSim packet size has its own limitations and Daniel has weighted them before making the suggestion

I don't use fixed ranges, my buttons are all dynamically allocated. Wouldn't need to be a dynamic array, could be bitmap of 30 bytes with a bit set indicating which buttons to remove.

Hi

Looks like a good time to implement a "spectate request" system also. Would be usefull at leagues where Race Control ask to people to not go spectator during the race.

Maybe an admin command "/canspectate false" to disallow the spectate function to the entire field. But you also need a way to allow to a broken or upside-down car go to spectator. So "/canspectate dr3dd" maybe works fine.

A warning message to admins when some driver hit SHIFT+S should help to RC.

what you think?

Quote from Dr3dD :

Maybe an admin command "/canspectate false" to disallow the spectate function to the entire field. But you also need a way to allow to a broken or upside-down car go to spectator. So "/canspectate dr3dd" maybe works fine.

There is already a command for that - /spec username

Quote from Flame CZE :

There is already a command for that - /spec username

He is talking about making Deco able to enforce "NO SHIFT+S"

I meant that admins would be able to override the /canspectate command with the /spec username command.

Quote from Flame CZE :

I meant that admins would be able to override the /canspectate command with the /spec username command.

Ah, I see, you just quoted too much maybe? :]

Quote from PeterN :

I don't use fixed ranges, my buttons are all dynamically allocated. Wouldn't need to be a dynamic array, could be bitmap of 30 bytes with a bit set indicating which buttons to remove.

Bitmap sounds flexible, although it will take atleast 32 bytes packet to suffice the whole possible range. With range based packet, you're enough with just 2 bytes. And, I guess, most of the time you still create and destroy buttons by some bunch amounts, which typically occupy consecutive ranges, so you could try to book keep them and use the range destroy packet.



Also, yet another request:
Can we have a packet enumerating allowed cars on the server? This will be really nice, because that way my app could automatically detect what car to show with !top command.

It was already annoying with Airio, when you came to some server and typed !top, seeing XFG top, while server has only BF1 enabled. There is workaround in Airio, but it requires server admin to take some actions (which they are lazy, or too busy to do), which ends up with lots of regular players experiencing this problem.

Programmers and other people with a related interest, please head over to the programmer forum where there is a special test available.

NOT COMPATIBLE! Only for specific testing! https://www.lfs.net/forum/thread/88999

New join request system if ISF_REQ_JOIN is set - see InSim.txt
New system to reset a car at a location with or without repair
New admin commands /ujoin username and /uai username

It needs some good testing before we go public. More features should be added but let's discuss it on the other thread.

Quote from vitaly_m :

Can we have a packet enumerating allowed cars on the server? This will be really nice, because that way my app could automatically detect what car to show with !top command.

+1

Another possible InSim improvement:
https://www.lfs.net/forum/post/1874463

Quote from vitaly_m :

(which they are lazy, or too busy to do), which ends up

Apparently you like to do unfounded ranting, probably you was on too much Russian vodka when you wrote this or it's a general lack of diplomacy but I never heard anyone making an issue of the problem you described neither a possible solution or request to change. On the other hand "one car" public servers are quite rare to begin with for the last six years so your proposed InSim change is probably quite useless.

Quote from cargame.nl :

Apparently you like to do unfounded ranting, probably you was on too much Russian vodka when you wrote this or it's a general lack of diplomacy but I never heard anyone making an issue of the problem you described neither a possible solution or request to change. On the other hand "one car" public servers are quite rare to begin with for the last six years so your proposed InSim change is probably quite useless.

I can bring here 2 other people who encountered this problem in some way. 1 car servers are used quite often in leagues. Wouldn't it be much more convenient to just configure server /cars and /track and start everything up neither than having to keep in mind how to deal with your tracker of choice?

Please can we discuss InSim improvements on the new InSim thread?
https://www.lfs.net/forum/thread/88999

It'll be easier if I can follow only one thread, and leave this one for the ongoing compatible patch testing.

Quote from vitaly_m :

I can .. of choice?

What I was trying to do here is reflecting back what you are doing yourself by using other people to make your point and even making weird assumptions like; "lazy", "busy" .. I can do that too (I just did), but it's pretty offensive. We are all here with our own intentions which is a hobby, if you have a suggestion thats fine but why you need to drag other people into it, I don't know. What I now understand from you is when somebody does not do what you want that person is either lazy or busy. Strange rating.

But I think what you try to suggest is that the InSim does not know what the /cars flag is set to and that you would like to see this different.. Nothing wrong with such a suggestion but why you need to decorate this with all kinds of negative energy I don't understand.

All right let's stop the arguing.

When he said "lazy or busy" he was just suggesting why the hosters didn't already set the allowed cars, when it was possible to do so.

By the way, "lazy" may be insulting but "busy" isn't and he was just suggesting why someone might not get round to it, even if they aren't lazy, because they have other priorities which they are busy with.


For the third time, can we stop InSim discussion here as I've made a special thread for it.
https://www.lfs.net/forum/thread/88999

Quote from Scawen :

New system to reset a car at a location with or without repair

Scawen, would this improvement allow to do a pit stop changing tire compounds without being forced to repair the car? Or is it totally unrelated to that part of the code?