While you're in that general area, would it be possible for the objectInfos of the reporting AXM packet to have the Z byte set as where the object ended up after the dropping algo, rather than where it's set in the layout file or setting packet?
I made a converter for moving old BL carpark layouts to new locations, and for each target location I had to manually make a height map to set the new Z on sloped ground. If the AXM reported the final height, I could use insim to place a test object and read the height from anywhere on the map. Less effort and infinite resolution
The new PMO_POSITION packet does have the Zbyte set, but I don't that is what you are asking.
I can't set the Zbyte in the reporting AXM in the case of a dedicated host receiving the packet, as it doesn't know where the ground level is.
I'm getting a bit confused trying to think of when that Zbyte adjustment could be done and when it would need to be done. Maybe I need a more specific case to try and understand where it would be helpful and to think if it can be done without causing problems.
One thing to note though, it is acceptable and usually OK to simply use the value 240. From the notes:
Sorry, I wasn't very clear. I was trying to use placing a ground-seeking object (tyres) to detect the ground level by placing it too high and seeing where it drops to, in order to then remove it and place a non-ground-seeking object (concrete wall) on ground level.
Placing a non-seeking object relative to ground level is the object, placing the seeking object was just a means to that end.
I didn't appreciate that DCON can't give me that info as it doesn't know where the ground is, but now you say so it does seem obvious. DCON is passing the Zbyte as it is in the layout file, the client is doing the dropping into place. Bugger! That also puts the kibosh on getting a ground level from InSim at all I guess
I am just wondering if something special could be done for this.
Possibly a sort of query to find the highest ground position at X, Y.
Or perhaps an object placement packet marked as "set height"
I'm wondering if this can be done at the local level or does it need to work in multiplayer.
Sorry for the fuzzy thinking, I'm busy in the layout editor at the moment so I'm just trying to figure out what would solve it for you, be simple to implement and ideally useful for other situations too.
Good things come from fuzziness.... but you've started me off now
For my case it would be enough if the LFS client running as a host (as this setup has both insim and ground level) could have a special mode that did it, as my use case doesn't need to be done live or multiplayer.
I've just deleted a couple of paragraphs of ideas of diddling AXMs, faking responses back and forth etc, 'cause I missed the next obvious point after the previous - sometimes we're going to have an insim connected to a host with no client LFS attached. No ground data for anyone in that case, however many packets we throw at the problem. Grrr!
Perhaps the solution is just to have a new packet that is triggered by the dropping algorithm itself, from inside the LFS client and passed through the host to the insim client. Just a simple X, Y, original Z, Heading and Index to cross reference with our AXM data, and the new Z value in the flags. On the insim client end, we just patch our stored AXM data if we get the corresponding 'AXH', and we'd know not to trust the Z of a droppable in the AXM until then. I guess the host would need track these to avoid sending them every time a new LFS client joins and loads the layout, but that would be spam-reduction rather than essential.
Or, maybe a new method of placing the non-droppable objects as a hlaf-way measure? We could optionally flag the object so that the Z value is relative to the ground level, rather than absolute. We'd still not know where they ended up in insim, but we'd bypass the need to know for some use cases.
OK, I am mentally tired from trying to get a layout editor improvement finished. You can now select marshalls / circles at the same time as other types of object but that was more complicated than it sounds.
So bear with me being a bit slow!
Can we get back to the basics, exactly what do you want to do? I understand you are trying to make layouts from a old track work on a new one. And this could be applied to moving a layout from one track to another I guess (e.g. BL car park to WE car park).
Are you trying to run through existing layouts and get all the objects of a certain type set to ground level? In particular concrete objects so you can't use the Zbyte 240?
And are you doing this by your code reading a layout file and passing it into LFS as AXM packets?
If the above is true I'm wondering if the simplest thing could be an InSim packet for local use only, that simply asks for the height for a given ObjectInfo (X,Y, Zbyte) and LFS replies with the Zbyte that would result from that. So you could run through a list of objects one by one and do what you want with the answer?
Yes, that's it exactly. The banger league had many ovals (~100, including variants!) built in old BL3 when the Blackwood update came, so I did my best at transplanting them to the new BL4, and other locations. It works for the most part, but there's a few hitches.
Yes: translated, rotated and then moved to a Z relative to the new ground level. Dropables are no problem, but for concrete I had to make myself a heightmap of the destination to use as my ground level.
That packet would be perfect, that would give me at least two ways to solve the problem.
I was doing it as a layout file conversion in commandline PHP, just in raw data wihtout an insim connection, mostly so I could do it as a batch job. The height was taken relative to the ground in the source (old BL3 was flat), and placed either relative to my heightmap in the destination, or relative to 0 in the case of AU1 (also flat).
I can add a local connection to the converter and use that packet to replace the heightmap, or I could use it in a separate program to automate heightmaps in much higher res.
There're some example images of a convertion for reference in this thread I made at the time. Not a popular service, apparently
PMO_GET_Z, // 8 - request Z values / reply with Z values
And the documentation for how it works.
// PMO_GET_Z can be used to request the resulting Zbyte values for given X, Y, Zbyte
// positions listed in the IS_AXM. A similar reply (information only) will be sent
// with adjusted Zbyte values. Index and Heading are ignored and set to zero in the
// reply. Flags is set to 0x80 if Zbyte was successfully adjusted, zero if not.
// Suggested input values for Zbyte are either 240 to get the highest point at X, Y
// or you may use the approximate altitude (see layout file format).
I'm not sure it will be released today, probably not as I've got something else I'd like to have a go at. But then hopefully tomorrow.
I ended up making a significant change to the layout editor. It's now based on "cut / copy / paste" instead of "move / duplicate" so it is quite a change and there are a few loose ends to fix.
I wonder why highest ZByte is valued 240 and not 255. Any technical explanation of it? I am thinking some reasons of it, but not sure. Just being curious.
I think I didn't like the way 255 would mean a maximum height of 63.75 and it seemed that 60m would be a better maximum height. And that allows 15 'reserved' values that could have a special meaning in future.
Isn't this taking to much time? I believe it's quite important to have an fully working official version again .
Also tought u planned new test patch for a week ago
The PMO_GET_Z packet and other InSim changes are now available for testing in R13 along with a significant update in the layout editor. https://www.lfs.net/forum/thread/92067
