Hello Hosters,

Tuttu The Dog reported a few issues related to the race restart and lobby screen when running a popular event. In some cases I think I can make a small change and would like your feedback if you notice any issues.


1) People were able to remove others from the grid or move people around on the grid. Obviously that is the behaviour of a trouble maker, not the normal thing. Unfortunately I can't do much about this right now because of the way it is written, that would require an incompatible version.


2) People can join at inconvenient times after being asked not to join. Not necessarily trouble makers but anyone could miss a message like "DO NOT JOIN GRID" and simply be trying to join the race. Join requests go through the host so I think I can provide a simple option to lock the grid.

How about:
/grid lock - players cannot join in the lobby
/grid open - back to normal


3) Object mods sometimes need to stay in the same grid slot. In this event the track mods needed to occupy the first 3 grid slots. This was a problem on race restarts due to the automatic reordering.

Proposed solution:
Grid rearrangement is worked out on the host so does not require an incompatible version. What if the host counts the number of "object" mods in the first few player slots, and then makes sure that those objects do not change in position due to their qualifying result [NONE] or race finish result [DNF]. Instead, any object mods that are in the list before any vehicles, would retain their front grid slots.

If there are administrators on that specific server/lobby, that admin could also have "lock" feature next to it's name on grid. Therefore no one can remove or switch places to it.

So, if someone or something is wanted to set on Starting Position 20, it stays on that specific position no matter what is the rest of grid order.

Furthermore, that would be generally good feature have regardless of any. For example, if wanting to have special condition races and racing and someone is exactly wanted to start in specific position everytime when restarting race.

Furthermore, there could be an insim support for grid ordering for multiclass, where faster class automatically is set on better position ( in case that was not already implemented, I don't know ).

I know I went a bit off topic, but this thread did cause me to see things like mentioned above.

In anycase, thumbs up!

EDIT: Just for clarification, I was not going to oppose the op in any case, it just indeed rise more things to think about it personally.

The option to block non-admins from messing with the grid/joining would be very useful.

Joining accidentally is much easier to do since a change to the garage buttons a while back. Not a complaint, just pointing out it's quite easy to do without intending to if you're not paying enough attention to what you're clicking.


Being able to lock arbitrary positions, not just objects, would also be useful for things like safety/course cars. That was a minor issue over the weekend too.


Theoretically all of the above is already doable using InSim*, but it can be quite complex to handle, especially REO behaviour it seems.



*apart from it being impossible to skip grid slots as far as I know, though I've not actually tested it

That second issue you mentioned is the one that catched my eye the most:

By the way, for now: you can actually already do that: admins can use command /carsguest=[0-32] which sets the maximum amount of cars (real + AI) each guest PC can add to the server. So /grid lock would essentially be same as /carsguest=0, right? That command doesn't remove the already added drivers from the grid

However, two things got into my mind about that issue you mentioned:

1) Is it intentional that you suggest that /grid lock would only apply in the lobby and not when session is ongoing (whether it's practice, qualifying or race)?

2) It also does have another reason why it would be good to get fixed: AI drivers and human players. Your idea to have a command to lock/open the grid is good, but I was wondering Scawen, could it be possible to expand that command by adding two more parameters for that:

Quote :

/grid lock ai - AI drivers cannot join in the lobby (or even on track, if it applies there as well)
/grid lock real (or human) - real/human players cannot join in the lobby (or even on track, if it applies there as well)

The reason is that there may always be troublemakers, who add an AI driver in the lobby, when only humans are allowed. And it also applies vice versa: there may be a situation where only AI drivers should be allowed to join (for example, there is a session for those InSim controlled AI drivers), and some troublemaker adds themselves there, which interrupts the fun/experiment with AI for the others.

This concern just got into my mind that having just lock/open parameters for that /grid command does leave this other issue kinda open. You can only allow everybody, or nobody joining. Even if you open the grid, someone may still mess others by having an AI driver joining (or a human player, if others are using AI drivers)

Quote from Degats :

Theoretically all of the above is already doable using InSim*, but it can be quite complex to handle, especially REO behaviour it seems.

*apart from it being impossible to skip grid slots as far as I know, though I've not actually tested it

I was going to say that I've not had any luck getting REO to work, but you mentioning that reminds me that I've seen it strip any blank spots that I send... so I guess I must've got it to work at some point

I think maybe REO is restricted to working only in the lobby screen? I've tried spamming it before, during and after an in-race restart (ie no lobby) without it changing the race order. I ended up using JRR packets to move people around on the grid instead... but you need to buffer them somewhere else to avoid collisions.

--

/grid command looks good. I was wondering if it would be a good idea (or even possible) for the admin grid functions to be immune to the lock? I don't do it myself, but I've been at races where the grid is set manually by admins and people will still join during that process

Quote from Racon :

I think maybe REO is restricted to working only in the lobby screen? I've tried spamming it before, during and after an in-race restart (ie no lobby) without it changing the race order. I ended up using JRR packets to move people around on the grid instead... but you need to buffer them somewhere else to avoid collisions.

You need to listen for race start vote action packet and do it in there, as the InSim docs say.

Quote from Racon :

I was wondering if it would be a good idea (or even possible) for the admin grid functions to be immune to the lock?

I thought this was implied, however if there's doubt then I ought to also say that this should definitely be the case where an admin has the power to arrange the grid with grid lock on.

There's been some discussion about this at the Discord server. Here are couple points mentioned there:

- "it would also help a lot to see who moves who in the lobby screen to avoid grief during organising the start grid"
- "AI should be utilised for the track scenery mod"
- Someone made an early mock-up where they had a lock icon next to the clear grid button at the lobby. It could be good place for that. They used that lock icon from the Upcoming events are for that.

- Also, one thing could help users at the lobby: at the moment, if you are not admin, you can't know who is admin (other than host) at the server when looking the connection list. If you are admin, then you can see that other admins have that different background under their names on the connection list

However, if you watch the replay, then you can see who is admin and who is not. Obviously this doesn't apply to the situation where you are at lobby. It does indeed feel strange that the connection list is different when comparing it between the replay view and the non-admin user view when they've connected to the server.

What is the reason behind this? Why non-admin users have the same background for all the users when looking the connection list? The only thing they can do is ask who the admin is, and even then, it's not 100% guarantee that information is accurate.

Quote from Flame CZE :

You need to listen for race start vote action packet and do it in there, as the InSim docs say.

The spamming was a result of reacting to a VTA not working, IIRC. "Can't miss the right time if I just never stop" kinda thing. I dunno, it's been a while

Quote from tankslacno :

There's been some discussion about this at the Discord server. Here are couple...

Prevents from people harassing the admins i guess

Quote from Scawen :

How about:
/grid lock - players cannot join in the lobby
/grid open - back to normal

Hello, I was thinking if that grid lock would also have the possibility to lock the positions (= drivers can't swap their positions) but that drivers also can't leave the grid (can happen by accident when you got into the pits to change the fuel, seen that many times when making Ligue FR's grid)

Otherwise this sound a good idea

OK, some slight changes after feedback and testing.

I have been able to do more than expected without an incompatible version.


About a suggested option to allow AI / real / any players:

That is a good suggestion but is actually a different topic that doesn't require shared logic. I have to keep this simple to make it reliable. So let's leave that out for now.


About keeping object mods in the first grid slots and not moving them in an automatic reorder, vs a suggested idea to be able to individually lock any players (e.g. safety cars etc):

As noted, there are no gaps in the grid, so it's not really possible at the moment to lock arbitrary racers in position. I think the easiest option (for a quick and safe implementation) is to allow the admin to specify a number of static grid positions. Those static positions could include object mods and safety cars, if they are all at the start of the grid.

e.g. /static 3 ... keep the first 3 slots in place when auto-arranging grid on race restart.


About preventing people adding / removing / moving players around the grid:

I propose 3 options for a /grid command: open / self / lock

A separate question:

When testing the new /grid command, I felt a bit uneasy that I didn't get a reply from the host confirming the update. I changed it to report back what I typed as a confirmation.

I'm not sure if this is needed or desirable. If so then I guess the same behaviour should be implemented for:

maxguests / adminslots / carsmax / carshost / carsguest / pps / rstmin / rstend / specdnf / autokick / start / autosave

It's just about 1 minute each to do this, but I don't want to add messages that would annoy more than help.

Well we can sort of already figure if a command is wrong with the 'error' sound playing, and if it's not an error, then it doesn't respond with any audio. So I think it's fine without in my opinion.

(but I don't mind the suggestion being implemented aswell, it can't be that annoying just to have a confirmation message ) and also Racon's point is good

The commands sound good to me.

I have no particular opinion on feedback messages, other than I suppose it might be useful for *other* admins/InSim to know when settings are changed.

These are rare enough (comparatively) for feedback to be more useful, I think. I generally check I didn't typo with a parameter-less call after a change, so it'd halve my typing

[posted before I saw Racon's post]

OK I see what Tuttu means, if no error then it worked. I think I won't change that for now.

By the way, you can check the current values of the listed commands by typing the command with no parameter.

Quote from Scawen :

e.g. /static 3 ... keep the first 3 slots in place when auto-arranging grid on race restart.

Just to clarify: would the /static command work only in lobby, or also during on-track sessions (for example, there is a need for correct wind speed and race must be restarted again)?

In any case, it would probably be essential to highlight the static grid positions (and maybe starting positions as well on the position list), for example with different background color?

Quote :

About preventing people adding / removing / moving players around the grid:

I propose 3 options for a /grid command: open / self / lock


/grid open self lock
JOIN RACE Y Y N
REMOVE SELF Y Y N
REMOVE OTHERS Y N N
MOVE PLAYERS Y N N

I like this idea However, I think it would probably be good that even if the /grid command has self/lock option selected, admins could still e.g. remove and move players. Another thing I had in mind is that have you thought about adding separate buttons for admins to the UI so they can select the option they want, or should these options only be available by using commands? I'm not sure is there enough space in the UI

Also, I suppose the self option would apply to local AIs as well? Like option "REMOVE SELF" with "Y" would also allow removing local AI drivers, not just yourself?

I think both commands can be set at any time but the /grid command only affects the lobby. The /static command really only applies in game because it is when restarting after qualifying or a race that the automatic grid rearrangement takes place.

Yes, the idea is the /grid command does not lock out admins at all, so they can still add / remove / rearrange the grid at will.

Yes, the self option applies to you and your own AI drivers.

I don't want to change any in-game display at this time. Although some in-game indication would be nice, what I am talking about in this thread is purely a quick server-side update to help race organisers and I need to get back to the development version in about one day from now, not start working on the UI and releasing new test patches.

OK, the /grid command is ready for testing, if you have an EU (Netherlands) host and you restart it, or start an in-game host in the Netherlands.

/grid open/self/lock (set if non-admins can join / leave the grid or move others around)

/grid static X (X is a number)

The first X grid slots are protected from auto rearranging when the race restarts.
The first X grid slots are unaffected by the result of qualifying or race finish, on restart.

/grid real no/yes (set if real players are allowed to join)

/grid ai no/yes (set if AI players are allowed to join)

You can also get the current settings:

/grid - show the current grid lock setting
/grid static - show the current static setting
/grid ai - show the current ai setting
/grid real - show the current real setting

Thank you very much for this

I tested every single command both as an Admin and as a normal user, and all of them work with no issues at all! I also tested /ujoin and /uai commands with grid being locked and they both work!

Also I think it looks like the /grid command does work also on-track, it doesn't affect just the lobby: I tested the /grid real and /grid ai commands during on-track session, and I can prevent AI drivers / real players joining, even if I'm not in the lobby

And just one minor typo:

Quote :

/grid ai no/yes (set if real players are allowed to join)

Surely you meant "set if AI drivers...", not real players

EDIT: Actually Scawen, one question about this:

Quote :

The first X grid slots are unaffected by the result of qualifying or race finish, on restart.

I just tested this with reversed starting order with /grid static 3, and I noticed something interesting. Those 3 drivers were sent back to the grid with reversed starting order. Is this on purpose, or should these 3 drivers start at the front and the drivers behind them in a reversed finish order?

EDIT 2: Not sure if the three drivers themselves were in a reversed finish order, but nonetheless, they were behind those other drivers

Thanks. Fixed the typo.

About affecting in-game or lobby:

/grid open/self/lock <-- affects lobby only
/grid real/ai <-- affects lobby and in game
/grid static X <-- affects race restarts only

Quote from tankslacno :

I just tested this with reversed starting order with /grid static 3, and I noticed something interesting. Those 3 drivers were sent back to the grid with reversed starting order. Is this on purpose, or should these 3 drivers start at the front and the drivers behind them in a reversed finish order?

That does look like a bug... will check it out, thanks.

OK, the bug with /start=reversed in conjunction with /grid static X is now fixed.

You can have the fix if you restart your EU / Netherlands host.

If anyone wants the updates on another country host, I can update it. Just didn't want to update all 7 locations until a bit of testing.

EDIT: Also updated in USA and Brazil locations.

I forgot to mention the new /h command that runs the following local command on the host. For ordinary dedicated hosts this doesn't allow many new possibilities but does at least give access to /player (change player name) and /o (output message) on the host.

EDIT: Also /say can be used, e.g. /h say hello (write a message from the host)

I also updated /player to work without an existing player file, so now you can change the host player name with:

/h player Host Name