Quote from EQ Worry :

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.

OK, and I also thought that that grass / ground thing would be good to look at. So hosts can run a check nearly the same as HLVC if they want to.

About the car info in the OBject Hit and 'HLVC' packets (maybe the same packet) I am thinking it really does not need all the CarContact info that you get in the IS_CON packet. I think X, Y, Direction, Heading, Speed should be enough for the car. And for the object : X, Y, Index and another byte of flags, for info like if the object was in its original position when hit. I'll post a proposed packet this morning.

Quote from EQ Worry :

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.

Don't worry, I will look at this.

Quote from Squelch :

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?

Each object has its own X and Y. A multiple object packet contains 0 to 30 complete 8-byte ObjectInfo structures.

Quote from Squelch :

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

Yes, the system is specifically designed to allow simultaneous editing by InSim or any number of admins. That's why objects are referred to only by X, Y, Index and never their number in a list. Index means one of the AXO_X object type numbers from the end of LYT.txt

Quote from Squelch :

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

I don't think it is easy to change the code to allow NULL objects.

Quote from GeForz :

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

Yes.

Quote from GeForz :

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.

Yes, as I probably can't support NULL objects easily, this is a good way to signal a position to an InSim program.

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.

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?

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.

The approximate altitude has always been called Zchar, so I never forget that it has a different accuracy level compared with X and Y. This is the actual structure that has always been used in LFS and layout files, layout file loading packets and so on, so it is not possible to rearrange it.

You have missed the meaning of Index though. It is not an identifier of an individual object. It is one of the AXO_X numbers from the end of the LYT.txt file. Objects are not identified by a unique id or an index in a list (which could keep changing). An object can be indentified uniquely by (X, Y, Index) which is what PMO_DEL_OBJECTS looks at to find objects you want to delete.

Scawen did you read my initial response about the PMO_LOADING_FILE?

Quote from Squelch :

I was originally thinking the same, but realised that creating and deleting an object would fragment the static vertex list.

No, there is never any fragmentation, because the static vertex buffers for all added objects are created at the same time - that's why it can take a quarter of a second / maybe half a second depending on computer speed to generate the buffers if there are 800 objects on the track.

I can't emphasise enough, and this is why I took ages to write an essay about it in the ISPackets.txt : programmers will have to be careful with that bit in PMOFlags and you absolutely MUST NOT set it routinely in the PMO_ADD_OBJECTS packets. You set it once in the last packet of a long list of objects, at a time when you are happy for people to spin off if they are driving around a corner. Don't set it if you are adding / moving a small number of objects around - just leave the new ones unoptimised.

Quote from Squelch :

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?

That doesn't happen in the editor now, it does a thorough check before you move objects, and doesn't perform the operation if it would go wrong in any way. But there are no such checks in InSim. Intersecting objects would be deleted in that case.

Unfortunately, dedicated hosts cannot detect intersecting objects. If objects sent from a dedicated host have the exact same X, Y, Index they will not be added. But if they are slightly different and still intersecting, they will stay there. If the packet is sent from a client, the objects are instantly deleted if they intersect.

Quote from GeForz :

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?

PMO_LOADING_FILE packets are sent when you load a layout using LFS's load layout button or /axload, or just open a track and LFS loads a layout. Any time LFS loads a layout using its own system, those are sent.

I'm not sure about the send objects tiny. It's becoming very difficult for me now, trying to finish the patch with the things I am already committed to, thinking about yet more things to add and test makes me very uncomfortable. So I don't want to do that if it's at all possible. Perhaps people should connect their InSim programs before loading a layout? Alternatively you could do /axsave temp and then read the output layout file.

Okay that should work, too.

BTW: is it really possible to have 2 objects at the same x,y coordinates?
i.e. Do we really need to use x, y AND index to compare or is x and y enough?

Quote from Scawen :

No, there is never any fragmentation, because the static vertex buffers for all added objects are created at the same time - that's why it can take a quarter of a second / maybe half a second depending on computer speed to generate the buffers if there are 800 objects on the track.

I can't emphasise enough, and this is why I took ages to write an essay about it in the ISPackets.txt : programmers will have to be careful with that bit in PMOFlags and you absolutely MUST NOT set it routinely in the PMO_ADD_OBJECTS packets. You set it once in the last packet of a long list of objects, at a time when you are happy for people to spin off if they are driving around a corner. Don't set it if you are adding / moving a small number of objects around - just leave the new ones unoptimised.

Thanks for the clarification and emphasis. It was your ISPackets.txt warning that made me think of avoiding re-optimisation, but for the wrong reasons, and it's now clear.

Quote :

That doesn't happen in the editor now, it does a thorough check before you move objects, and doesn't perform the operation if it would go wrong in any way. But there are no such checks in InSim. Intersecting objects would be deleted in that case.

I was going to suggest flashing the selection/object while in editor mode.

Quote :

Unfortunately, dedicated hosts cannot detect intersecting objects. If objects sent from a dedicated host have the exact same X, Y, Index they will not be added. But if they are slightly different and still intersecting, they will stay there. If the packet is sent from a client, the objects are instantly deleted if they intersect.

Does this mean an InSim packet on the dedicated host will allow intersecting objects then? If abused, it could lead to some very interesting... erm... sculptures?

Quote from Squelch :

Does this mean an InSim packet on the dedicated host will allow intersecting objects then? If abused, it could lead to some very interesting... erm... sculptures?

Couldn't you do intersecting objects for long time using third party editors already?

e.g. this one: http://www.lfsforum.net/showthread.php?t=16873

Quote from Scawen :

The approximate altitude has always been called Zchar, so I never forget that it has a different accuracy level compared with X and Y.

Quote from Scawen :

You have missed the meaning of Index though. It is not an identifier of an individual object. It is one of the AXO_X numbers from the end of the LYT.txt file. Objects are not identified by a unique id or an index in a list (which could keep changing).

Thank you for clearing both items up for me.

Quote from GeForz :

Maybe there is need for an "send objects"-tiny-request i.e. when the insim tool connects to a already running server?

Agreed, an ISP_TINY packet for this is an important step.

Quote from EQ Worry :

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.

I have added a line, if logging is enabled and someone connects as an admin :

Jun 08 11:35:48 Admin : scawen

Quote from EQ Worry :

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.

I have added to the log, commands from remote connections, with a small difference if it is an admin or not. The admin version has a colon and the non-admin version has a minus.

Jun 08 11:43:13 scawen : /axlist

or if the user is not an admin...

Jun 08 11:43:58 scawen - /axlist

Quote from EQ Worry :

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).

I'm not sure yet if I'll do this, but I've made a note.

Quote from Dygear :

Agreed, an ISP_TINY packet for this is an important step.

Actually this is a bit hard, I can't just send a flood of packets for 800 objects. And doing it in pieces is not guaranteed to be correct if someone is editing, and has bug potential that I can do without right now.

So I don't plan to do that. Anyway, I don't see it as that important, because you can use the command /axsave temp and read the file temp.lyt that will be created.

Quote from Scawen :

I have added a line, if logging is enabled and someone connects as an admin ... I'm not sure yet if I'll do this, but I've made a note.

Great, thanks , having it in server log will allow for later diagnosis, but it is not really easy to respond to server log items in real time (though not impossible, under certain circumstances). Having the admin commands, or attempts at them, forwarded to InSim would make things of course much easier. But I'm very happy with this 1st step, thank you. Maybe instead of colon a plus could be used, representing accepted command, while minus represents refused command? Well, whatever, it is not really important, it just seems to be more, uhm, intuitive...

Quote from EQ Worry :

Great, thanks , having it in server log will allow for later diagnosis, but it is not really easy to respond to server log items in real time (though not impossible, under certain circumstances). Having the admin commands, or attempts at them, forwarded to InSim would make things of course much easier. But I'm very happy with this 1st step, thank you.

Isn't it possible to use tail and then forward messages to an InSim client? Combined with grep, even high priority messages can be filtered and dealt with, and in virtually real time too.

I'm not sure about tail and grep, but I think it obviously is a kind of makeshift solution, while an InSim message packet (maybe message of special type, we already have about 4) is nice and clean. Also I would guess any "server log change listeners" can work only locally. And even if I'm mistaken in this point, still...

@Scawen Just curious, why 30 objects per packet... the current limit is 800? 800/30 = 26.667 wouldn't it just be simpler to make it 32 or did you pick 30 for a specific reason? or if you rather not explain, that is fine also

Quote from T3charmy :

@Scawen Just curious, why 30 objects per packet... the current limit is 800? 800/30 = 26.667 wouldn't it just be simpler to make it 32 or did you pick 30 for a specific reason? or if you rather not explain, that is fine also

the packet size remains smaller than 256 bytes then. This is necessary because the packets' their sizebyte is only one byte. So packets may not be bigger than 255 bytes.

Quote from Victor :

the packet size remains smaller than 256 bytes then. This is necessary because the packets' their sizebyte is only one byte. So packets may not be bigger than 255 bytes.

ohh, Ok, didn't think about it that way while posting.

I would really like to know if a user has DEMO/S1/S2 on join

Quote from Krammeh :

I would really like to know if a user has DEMO/S1/S2 on join

+1

I guess though that this is more a LFSW matter, it would be great to have this as part of some existing info (personal data - where country, total distance, races, etc. are available).

Just a quickie Scawen.

indeces -> indices

In the docs.

Quote from EQ Worry :

+1

I guess though that this is more a LFSW matter

+2

I already suggested that to Victor last year but somehow he wasn't entirely convinced yet. While it's a bit detectable by car usage history. Though difficult

Quote from cargame.nl :

+2

I already suggested that to Victor last year but somehow he wasn't entirely convinced yet. While it's a bit detectable by car usage history. Though difficult

what if im a s2 user that only likes XFG :P... it can't be that hard to put in, and there is sp3 in NCN *sulks*

what would you use it for?
I'm just very hesitant when it comes to giving away people's license status. For example there's already enough demo bashing going on here on the forum from time to time. I don't want to see this expanded in online LFS. I just cannot think of something constructive that the information can be used for.
A racer uses a certain car online and that's really all you need to know. So what if someone is a demo racer on your host? Or you're running an S2 host and then the racers will be S2 licensed. I just don't see the point of knowing a racer's license.
Also you don't have to do license checks to see if a demo racer has joined a S2 host - I already do those checks and kick people who are on a host they don't belong.

I normally run both S2 and Demo, and their in-server stats are stored in the same server. and I would like to ensure that they are Demo/S2 (not a S2 joining a demo hosts for instance).

The career starting point would change depending on if they are demo/s2

First, thanks for response! Of course Demo/Licensed status is of no use on licensed hosts, where demo people cannot connect. However, S1 or S2 info could be useful, if only just to see that you can move to an S2 combo without anyone losing connection. However, I would like to use it basically the other way, on demo servers to see who's got a license and can be e.g. invited to an event. Most of the people on demo servers are demoers, nobody's been raising an issue of this for years on our servers, I do not remember a single case when someone was "spitting" on demo people while racing on a demo server. Maybe here in this forum there are some rants occasionally, but I never witnessed problems online. One additional thing: The license status is already actually available, though not 100% exact. You just take a look at the guy's online stats and if more than 5 rows are returned, you know he's got a kind of license. I personally see no big deal in making this info available more readily. It is actually usable only on demo servers where nobody is making fun of demo people. The S1/S2/S3+ state would be handy from server management point of view. Well, and then people may always hide all of their data... PS: Airio is showing the derived status for a really long time already, and I don't think there ever was a problem with it. That Demo/S1/S2 info from LFSW would just make the info more precise and 100% exact.

Quote from Squelch :

Just a quickie Scawen.

indeces -> indices

In the docs.

Thanks - I've corrected that in LYT.txt.

I couldn't see it anywhere else, except in my code. :spin: