Apologies for the lateness of the testing, today was the first time I could and I had a bit of an updating-an-old-fork nightmare... it wasn't even setting an insim version Zvalues are working perfectly, thank you. The outlines and drag-select in the editor are real game changers too, it's an order of magnitude easier to be both neat and quick.
Unrelated to 0.6R18 but could be considered a small bug. When an object(s) flags (changing colour or angle of a Wedge object for example) are modified the pair of PMO_MOVE_MODIFY is sent. But the Flags byte in the ObjectInfo of both the PMO_DEL_OBJECTS and PMO_ADD_OBJECTS is identical. The PMO_DEL_OBJECTS should show the old Flags while PMO_ADD_OBJECTS should show the new Flags.
It's a futility really and I think the InSim app could assume the Flags byte was changed when the ObjectInfo pair is identical but it took me a while to realize this and with a bit of luck this is an easy fix.
Introduced with 0.6R16. When you copy, the grey outline remains even when you change the object flags and heading. When you press PGUP/PGDOWN on the other hand the outline disappears. I suppose this is intentional?
it seems to me when skins download i dont get these massive laghits.
however in some cases i still get them when people enter/exit garages/pitlane/track.
but not as much as before. now it seems like people who have a high ping is only issue. but im not totally sure yet. how ever thats my experience so far.
however. im a bit confused now about skie files.
do they stay dds now or will they go back to .RAW again ? it seems to me they change here and there over time so i kinda got a complete warehouse now with both .raws and .dds files. it would be great to finally be able to clean that up
also small dds question ? which dds color the windmills and the windmills wings?
been searching for that file for a year now. so thought i finally give up and simply ask.
(kinda the only files i cant find) (is it the grunge file ?
would be cool if Eric had a little thread where he could explain non obvious files and what they cover ? i think that could be a cozy little thread and also make users feel a bit closer to devs even maybe (ooops wrong place)
I am not sure what is the hold up to make this test patch an official release, but, let me take the opportunity to make a small but I think important request for racing (also cruising I guess).
There is this new command for putting the camera position onto the clipboard ( /cp ) ... Which is nice but what I came to think of it earlier today... In my opinion it is highly desirable to have some sort of same command but then to put the location of currently selected layout objects onto the clipboard.
Maybe you are aware of the webtool denis-takumi made (this one; http://turbosnail.github.io/lfspolygon/ from this LFS thread; https://www.lfs.net/forum/post/1579556#post1579556 ) ... This is/was a good idea to create LFS polygons but it has some drawbacks. One, its depended on something external, two its not that precise as I would like it to see and three its not easily maintainable for the end-user/polygon developer. LFS layouts can be saved and reused for easy future edits.
Now what I would like to see is some comma separated list of currently selected objects which include at least the AXO number (object identifier), the X and Y location. Maybe in JSON format like denis-takumi mentioned in his intro.. Or.. Oldskool Excel CSV format would also be workable.
This change would bring custom layout racing much easier back to reality because this sim needs a new form of race tracking, the old method of relying on modified .pth data doesn't work anymore. There are too many variations possible on new Westhill and Blackwood (luckily )
One other thing... Has an undo move object function ever been considered? Like it remembers the previous location of the objects prior to move and this can be restored after an object or objects move with the help of a press on some undo button (or shortcut, like ctrl-Z in a lot of programs). It's just a minor "annoyance" but could be nice to address in the process of optimizing the layout editor
I would normally do that but this test patch is partly about the internal layout editor (it seems). This undo function is just a minor thing which I sneaked into my previous post. The most important suggestion is the polygon export function. At the moment I do not see any opportunities concerning racing but maybe with some future updates it gets interesting again. If so, some pre-work needs to be done in these quiet times (which are actually pretty enjoyable).
I've fixed this in R19 which I hope to release today.
Yes, after you adjust the height of the objects in hand they are no longer identifiable as copies of the original objects.
It's just a short text that is sent in a single packet, which is limited by the current LFS packet system. The user doesn't usually have long to read it so it's supposed to be something really short they can read in a few seconds (I know it's sometimes longer if they are waiting for a track load and a lot of skin downloaded).
We are finished with raw files now. I think the skies will be supplied as dds files like the other textures. It's probably best to keep the raws for now but when the official patch comes you can delete all the raw files in the pic folder.
The wind turbines at BL and SO use a texture called "windgen"
I think this could be quite easy to do. A command that pastes a load of text onto the clipboard representing the current selection.
I think it's mainly a matter of choosing the right format.
Maybe there would be a number on the first line then subsequent lines have one object per line.
(possibly with spaces instead of commas, even easier to write a text parser that way)
Or would it be better to be really binary, like this:
I've done this in R19 which I hope to release this evening.
In some ways, I like your suggestions. It's the sort of thing I like to do but really you are talking about a track editor.
The concrete objects in the layout editor were really designed to allow people to build a bridge or make slight modifications so people could make tracks out of open configs.
Of course, people have taken it much further than it was ever intended and that is great. There's a line to be drawn between taking the layout editor further, and moving to a full track editor. Where that line is, I am not certain. But this is a compatible patch so new objects and different adjustments will not be added. The fine control you would like over pitch, width, etc, would require more bytes per object. The current objects are 8 bytes each - they are super compressed. It's a big change to do the things you are talking about, but this test patch is coming to an end so I can get back to the things I was working on before I was interrupted by the attacks. So it's really off topic and I'll move it to a separate thread. https://www.lfs.net/forum/thread/92202
One thing, as cargame mentioned, there is already CTRL+left mouse button rectangle select.
Hhmm.. What is this 3 suppose to imply? An indication that 3 lines of objects are on the clipboard? A good parser can figure that out by itself but if for some reason someone sees the use of this, then why not.
For sake of readability I like the non-binary version. I think people even want to import it directly into Excel or some SQL and its much faster that way (because Excel can process clipboard data on the fly if I remember correctly). The separator does not matter, comma or space, all is fine.
To be sure.. I assume this example has the same [X Y Zbyte Flags Index heading] structure?
Great that this request gets implemented so fast. Motivating!
Another useful addition. Selection changes (real and in hand) are not taken into account?
I'm being the devil's advocate here but is there a pertinent reason for the inability to set the UCID of the IS_AXM packet?
The UCID is reported in case of PMO_TTC_SEL, PMO_SELECTION, PMO_POSITION but is always 0 in case of PMO_ADD_OBJECTS and PMO_DEL_OBJECTS. Is this intentional? It would be helpful to be able to set the UCID to know who requested the packet in question.
By deleting or adding an object in the layout editor does that mean adding/deleting objects by pressing 'O'/'delete' keys?
I'm confused. I think I explained myself very badly. We might not be on the same page.
To recapitulate, if I send an IS_AXM with PMOAction PMO_ADD_OBJECTS and UCID 200 for example it will add the object accordingly. The ObjectInfo will be reported correctly but the UCID reported will always be 0. Key presses ('o', 'delete', 'ctrl+v', 'ctrl+x') do report the UCID correctly on the other hand.
It would be very helpful to be able to setup the IS_AXM UCID byte and have it reported back instead of it being 0. Sorry for the confusion...
(THE WIZARD DK)
by THE WIZARD DK : NVM. it installed it now.tho pretty weird..
i get an error 0 can not delete outputfile : LFS.exe when i try to install R19. not happened to me before in any LFS installs. it didnt install. ingame still say R18 :/
by kristofferandersen : irrelevant to test patch
Thanks a bunch for this! IS_AXM is now much easier to manipulate reliably in comparison to 0.6R.
I have just one comment to make. When you press 'o' out of bounds you get "Can't add : invalid position" (when the object has ground level check). The invalid position check is also enabled when you send an IS_AXM by InSim with a valid UCID. It is disabled when UCID is "invalid" or 0. Would it make sense to treat all IS_AXM's sent by InSim the same way, meaning no invalid position check?
The same applies to "Can't add : intersecting object" (when the object is movable). It is more usable and less tricky to manipulate IS_AXM by InSim when the intersecting check is disabled.
I don't know if this issue is since my graphic configuration has changed from a 2 screen to a 3 screen setup.
If I switch off post processing while I'm on a track the frame rate drops down over 10 times lower value then before. I mean that I switch OFF the post precessing. Before it was enabled. If I switch back ON, everything works fine.
If I'm not on track, I can switch between on and off without this frame rate drop.
BTW: I can reproduce that only in fullscreen! In window mode or in borderless mode I can't reproduce it. Very strange behavior.
Used graphic card: GTX980 / current NVIDIA drivers (397.64).