Quote from Scawen :

Actually your example is not confusing. It looks good... it's the thought of how to implement InSim key binds that is confusing, when the keys are all used up and multiple InSim programs can be attached, when my head is filled with so many other things.

Good point! This is the same problem I'm having with the InSim Buttons myself right now. I don't know how to display a group of buttons that are meant to work as one, but when they display on top of another group. I though that I would use a push / pop kind of method, so that the last bunch of items to be put onto the screen are the first interfaced by the user. This way, the most 'current' information is placed up front for the user to deal with. Once they have handled that, they are then represented with the older button group so they can interact with that.

In essence the button bound key, would work just like a ClickID, but with a physical key to click. In the same way that if you use a ClickID twice, then the data is overwritten, the same could be true of this. It would be up to the InSim programmer to handle themselves. Of course this would become a problem with multiple InSim instances running at once, should they request the same key, but then I would think that the first in last out, push pop method could work there too.

Quote from Dygear :

I would like to be able to bind InSim buttons to keys on the keyboard. For example, should I show a menu on the screen, and allow the player to use a button on their keyboard to activate (click) that button.

A possible solution - not quite as quick to use, but should work with InSim as it is now:

The player would need to bind 3 commands to function keys (!up !down !select for example. "/o " instead of "!" for a local InSim program)

The 'active' button would have a different colour to the others. The player changes the active button using the up and down binds, and the select bind to effectively click the active button. The player would be able to navigate a menu system while still maintaining control.

same keys that at F11 menu

Two, I hope reasonable, InSim suggestions:

1) Could there please be somewhere a bit (or bits) saying that tweaks on the server are allowed? Maybe a bit about the host being private would be useful as well. I'm not sure, maybe these two could go to the existing race flags...

2) Could the race flags be also sent as part of IS_STA, ideally including the private/tweak bits and updated on every change (of car reset, midrace join, must pit, etc.)? There seem to be two spare bytes...

Thanks for reading/considering.

Quote from Scawen :

I'm not sure if I understood this correctly but please be warned - you will have to be very careful with the /cars command now, it can no longer be used as a "prevent join" command. Because any cars that are disallowed by the /cars command will be instantly spectated. I realised that /cars could be used in that way before but is now very "strong" and that's why I've done the IS_PLC.

Yes, it's relying on /cars right now.

But I misunderstood you the first time. I know understand how it's going to work and in the end I think it's great. It only need some InSim coding now but this solution is better. Some racers cannot handle cars like FZ5 for example, its very nice that it's possible to exclude those cars from person to person on the LFS car selection screen.

I was thinking...

I wonder how the ingame filter and webfilter is going to react on this change.

What if a lot of race hosters decide to do a car ALL and let the InSim do permanent limiting? This change is making those filters pretty unreliable?

Quote from cargame.nl :

This change is making those filters pretty unreliable?

Pretty much, yeah. But that's because it's only going to be able to filter whats in the /cars setup. It can't filter based on what it might not be able to give you as it just does not know that. That means it's up to us not to abuse it.

Correct me if I'm wrong, but if cars is set ALL and then limited via InSim /cars, the ingame host list will also become misleading. This will mean drivers wishing to join an apparently open marque server, will find themselves frustrated by having no reliable information about the server type.

It is up to the server admin not to abuse the system, but history has shown that cannot always be relied on. I welcome the new addition, but it could cause further issues.

With great power comes great responsibility. I think this is a step in the right direction, I think we should have much more power over the engine, I think we should have access to the the engine via a DLL interface that we can use to setup callbacks within our own programs. I want to be able to edit and change the game on the fly, I want tweak on the server side that will propagate to the client side automagicly. I want full control over the client's speed, I want to be able to setup hotkey functions onto their client that will allow for like a server slide KERS system, or DRS. I want images and sprites to be able to be displayed on screen. I want to be able to control the font I use to display information within the buttons. I want control over the engine and all of it's parts. But we are a long way away from that, and that's ok, because if we got all of this tomorrow none of us would know what to do with ourselves.

I believe the individual car blocking is much better than forcing people to spec, as it is done now, so this feature is in every respect (for me) a major improvement. If properly used, it will substantially limit confusion and bad race joining spam happening now.

I hope, Scawen, that you still follow this thread, because I'd like to suggest a security improvement, also related to InSim. Just yesterday and today our servers were hacked in some way. I believe someone connected gained admin rights while being already online, or at least he/she was able to use all server admin commands. (I'm not sure, is that possible?)

The bad thing is that neither server nor any InSim tool (if I'm not mistaken) is able to log/see admin commands entered anywhere else than on host (and Remote, which is the host itself). All the / commands coming from a normal connection are "eaten", never reported. They are either refused or processed, but never logged.

Here I dare to suggest the following:

1) Whenever someone connects with server admin rights (or gets them somehow later, uhm?), record the event into server log, just one line with time, name, status.

2) Store all admin commands into server log, even when they come from normal connections and not just the host. This would be, I think, a major safety improvement allowing to backtrack currently hidden actions of rightful (and fake) admins. Of course I do not know how easy this is to implement, but I hope it can be done. Again, one line in server log, time, name, command, like it was a normal message.

3) If somehow possible, forward all such commands of all the connections also as standard messages to InSim clients, maybe using a new special type of message if necessary (I am not sure). IMO best would be to log/report all such commands, even if they're refused for insufficient rights. The idea is InSims can then spot all attempts at admin commands, and if they have a list of rightful admins, they can quickly recognize someone unauthorized is trying to subvert the server, with a protective action following (kick/ban).

I hope this makes sense, and thanks for considering.

Yeah, that's another thing. We should really have access to what is going on with the server at any given moment. If there is a command going on, then the InSim application should be informed of it so it can update it's state to keep everything in sync.

Well, sorry, one more suggestion, extending the server state info data and reporting as already mentioned here: One more bit saying whether or not the server is in demo-compatible mode would be helpful.

I believe it is possible to use /demo=s2 in server config and still make it available to demo people, but that depends on track+cars+connections+layout and it is hard to gather all these data separately. So that one more bit as part of server state (ideally sent on every state change as suggested in the linked post) would be nice.

Thanks!

Hello programmers,

I've now added this packet that can add or remove up to 30 autocross objects per packet. It can also be used to clear a layout and report any objects that are added by the host or admins, either when loading an entire layout or in the editor. Please can you read the documentation and see if it makes sense / if there are any problems you can see. The updated layout file format is attached, so you can understand the ObjectInfo structure.

New layout format looks good (Was already wondering why the spare byte was not 0 in z34 )

At which point will the PMO_LOADING_FILE be sent? Maybe there is need for an "send objects"-tiny-request i.e. when the insim tool connects to a already running server?

Quote from EQ Worry :

Well, that is really a lot of info already. Personally, I would be happy even with something much simpler considering collisions with objects (including walls, that is important for me), just PLID and maybe type of the object.

Quote from codehound :

The perpendicular closing speed of the car with the object would be useful for a program idea that I have. We want to assign ballast penalties for out of control driving and this would help especially on the city tracks.

I'm working on the IS_OBH (object hit) packet now. It's easy enough with the movable objects and autocross objects. X, Y and object index is enough to identify the actual object if you need to. It will include the perpendicular closing speed just as it does with the cars. For those objects LFS uses the same collision system as collisions with other cars.

But for the segments, there are more questions to be asked. Really, we cannot output all segment collisions, every time there is a brush with a wall or one tiny part of the car touches the ground. But this turns out to be a similar problem to the HLVC detection for hotlaps. To invalidate HLVC, the impact must be significant enough for 3 points of the car to touch the wall and the closing speed must be at least 1.5 m/s.

I guess my question to you is... for the wall collision detection, would you be happy with the same check as HLVC? This is designed to detect bad driving so I'm guessing it is quite suitable for your purposes. It's easier for me to code as well, because the detection is already in place so it's just a matter of putting that info into a packet and sending it.

"Colour - only used for chalk (0-3) and tyres (0-5)"
Can you add which number is which color so we don't have to try it out. (assuming you have the list ready to c&p )

Nice one ... I have one question, though:

Can you easily(!) tell us the dimensions of the ocjects (height, width, length)?
Might be helpful ...

Quote from GeForz :

"Colour - only used for chalk (0-3) and tyres (0-5)"
Can you add which number is which color so we don't have to try it out. (assuming you have the list ready to c&p )

Quote from avetere :

Nice one ... I have one question, though:

Can you easily(!) tell us the dimensions of the ocjects (height, width, length)?
Might be helpful ...

Not easily, but maybe I could do some kind of export of that info.

Scawen, what about add object_id (from 0 to 800)?
in "PMO_ADD_OBJECTS," action lfs search for this object_id. if it already exist then "move this object to the new point" else "add this object"
and add its id in shift+u mode (object info)

An object is identified by (X, Y, Index).

To move an object, you send a PMO_DEL_OBJECTS followed by a PMO_ADD_OBJECTS.

[EDIT : I removed some other posts that were either spam or turned out to be off topic]

Quote from Scawen :

I guess my question to you is... for the wall collision detection, would you be happy with the same check as HLVC? This is designed to detect bad driving so I'm guessing it is quite suitable for your purposes.

I guess using the same code HLVC uses is absolutely sufficient, as long as it reports substantial touches of walls, cones, etc., maybe also grass/ground if that is possible. Whatever seems simple enough. Thanks.

I do not want to delay official patch, but I hope you noticed some other proposals here concerning InSim and server log, specifically 1) logging/reporting all attempts at using admin commands from all connections, which I consider very important and actually a security hole now, and maybe 2) adding demo/tweak/private bits to server/race state info, sending it all also in the IS_STA packet on every change.

Sorry, I know I mentioned these 2 things twice before, but especially the silent admin commands are really not good and potentially dangerous. For example I know someone got admin rights on our servers without using the pass, very probably somehow after connecting, not during connect (here I have no idea if admin rights are checked by server or clients, if for example server processes all admin commands coming from "approved", possibly hacked clients), but I have no way to track the guy and the commands. Just logging them and reporting them to InSim apps makes major difference with swift action possible.

So again, sorry for repeating this, but...

PS: Oops, I almost forgot: Thanks for the object updates! It all looks very nice, but it would require time to incorporate all the changes and see if everything works smoothly.

In regards to multiple objects in shift+U (editor mode), where will the origin of the multiple objects be, first selected object, or the geometric centre?

Will it be possible to inject sets of objects via InSim while in editor mode? ie add further objects with relative offsets/rotations/indices from the last editor added object detected via ISF_AXM_EDIT

Example: Bale garage
Place first bale in editor, then use an InSim app to build a garage based on the last placed object position and rotation.

Is it possible to have a new generic "InSim object" available from the editor control objects list?

This would simply be a token that can be detected and trigger an InSim app to send a pre prepared payload. In the example above, the "InSim object" is used instead of the first bale, and the first object in the payload is placed at the vertices. I suggest a control object so it is invisible under normal circumstances, but would enable bulk object addition via InSim.

I hope this isn't considered to be more noise.

I assume:
Multiple objects will just be reported as seperate objects in the packet, each with own x,y coordinates.

And for the control object: The insim app could also remove the "control object", i.e. you configure the insim app like "!build garage" and then add a predefined object like a cone. The insim app then removes the cone and builds a garage relative to the coords of the cone.

You could do the command `autox build garage` and it will wait for you to place an object. After you do place an AutoX object, InSim sends the IS_AXM with the details of the 1 object that was placed by you, the InSim application then goes on to use the AutoX object you just placed as the Geomertic center and adds the other AutoX objects around it, finally removing the object you placed at the end. I can see this working quite well, except for one thing.


First is, why is Z called Zchar? Was that an error? Should it not just be Z.
Second is how did you manage to Index 800 objects with a value of 0 - 255?

Sorry to be pedantic but could you make the Index the structs first value, as it's the most significant bit of data we will have.

I edited several times to try and be concise.

Quote from GeForz :

I assume:
Multiple objects will just be reported as seperate objects in the packet, each with own x,y coordinates.

That's my assumption too from reading Scawens post and the new LYT.txt.

Quote :

And for the control object: The insim app could also remove the "control object", i.e. you configure the insim app like "!build garage" and then add a predefined object like a cone. The insim app then removes the cone and builds a garage relative to the coords of the cone.

Quote from Dygear :

You could do the command `autox build garage` and it will wait for you to place an object. After you do place an AutoX object, InSim sends the IS_AXM with the details of the 1 object that was placed by you, the InSim application then goes on to use the AutoX object you just placed as the Geomertic center and adds the other AutoX objects around it, finally removing the object you placed at the end. I can see this working quite well, except for one thing.

I was originally thinking the same, but realised that creating and deleting an object would fragment the static vertex list. Where there are many objects, my understanding of Scawens posts, is that the list is best optimised for better frame rate. If my interpretation is correct, an analogy can be made to file fragmentation on disk/memory, and the optimisation simply makes objects contiguous. I may be wrong and often am though.

Quote :

struct ObjectInfo // Info about a single object - explained in the layout file format
{
short X;
short Y;
[B] char Zchar;[/B]
byte Flags;
[B] byte Index;[/B]
byte Heading;
};

First is, why is Z called Zchar? Was that an error? Should it not just be Z.
Second is how did you manage to Index 800 objects with a value of 0 - 255?

Not sure about the Zchar, but you might be getting muddled between the index of the array of all available objects (see note 5 of new lyt.txt) and the total number of objects.

Quote :

Sorry to be pedantic but could you make the Index the structs first value, as it's the most significant bit of data we will have.

struct ObjectInfo // Info about a single object - explained in the layout file format
{
[B] byte Id;[/B]
[B] byte Flags;[/B]
short X;
short Y;
[B] char Z;[/B]
byte Heading;
};

No two objects can occupy the same space, so each unique object can be identified easily, thus

Quote from Scawen :

An object is identified by (X, Y, Index).

On that note, currently if an object intersects another while moving, it is dropped from selection and is effectively lost. What happens when objects in a multiple selection intersect with an existing object? I'm assuming we would need to avoid this via InSim too, but how to detect intersection? Would these objects be silently dropped too?