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.
Been using my Ultrawide for over 9 months... Only just found out LFS has the ability to remove the black bars
It's hard to find because you have to be in the external view, then go into the options > view to find it. A whole new hidden options place I personally never knew even existed!
I sat there for a good few seconds on the main menu options > views looking for the option above.
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?
I'm really questioning myself why Scawen or any part of his developers added such a low character limit to the dcon's welcome.txt file.. (I know it's not from those patches)
This is what I usually put on my welcome text files (I usually put more, but there's no space for them)
Yet the size of the box can hold way more than what the LFS dev team limited it to..
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:
2
fe65a1b6634e78ff
654de66c542fa344
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...
-
(Ezzegydrift)
DELETED
by kristofferandersen : irrelevant to test patch
This is a minor update patch to help with the attacks we had recently. I've added a few compatible updates that make the patch a bit more interesting for some people.
I've got a lot of work I am involved in and want to get back to.
This is not a magic patch in which everyone's incompatible requests will be implemented.
UCID can be set in some IS_AXM packets by an external InSim program
to make the resulting packets appear as if sent by an editing admin
(PMO_ADD_OBJECTS / PMO_DEL_OBJECTS / PMO_CLEAR_ALL)
Interface :
Command /axsel to copy layout editor selection text to clipboard
Updated translations with new URL for skin uploads lfs.net/skins
More updated translations - Thank you translators!
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?
EDIT:
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).
What is your setting for Full-scene antialiasing? (Options - Graphics)
I am asking because when you enable the post-processing is uses 4x. I thought maybe if you had a higher setting there could be an issue with memory usage or similar. Could possibly be connected with AF as well?
So maybe try turning down AF and limit your AA to 4x.
Talking about that, do you have plans to unlink MSAA and post processing? It would be nice to be able to control MSAA level independently from post effects.
With 4x AF switching between off and on works without frame rate drop.
@Scawen:
By the way I DISABLED post processing and then I had the bad frame rate.
I can not imagine that it is related to the vram. The graphics card has dedicated 4 GB of RAM. According to LFS, the textures memory usage is around 324 MB. There should be enough space/ram, right? I don't know if that so easy to compare. I don't understand enough about vram and usage.
"What is your setting for Full-scene antialiasing? (Options - Graphics)"
Thanks for the test.
I'm not sure if you did a typo there. Did you mean AA in the final sentence above? As in antialiasing, not anisotropic filtering?
Yes, I noticed that. That's the reason for my question about AA. It's the only thing I can think of that should be better when you do switch ON postprocessing. Because in that case it uses 4xAA regardless of your setting.
The reason for that is, I believe 4xAA is the best result for the least minimal extra GPU usage. That's why mirrors and VR render target use 4xAA and that's why the postprocessing one does as well (as it was a quick add-on using some existing code). My understanding is the render target uses 4x the size of Z buffer when you use 4xAA. Higher AA settings use bigger and bigger Z buffer and it starts to become a memory access and processing issue. And regarding anisotropic filtering, higher AF settings cause the card to produce its own special anisotropic versions of textures in memory and the amount used is unpredictable (at least to me it is).
I am sure you have enough memory. But accessing so much of that memory and processing it every frame is always a problem, which is why half texture resolution can often give better frame rates. I'm not sure if AF (anisotropic filtering) setting should affect things differently in post processing or standard modes. But I must wait for your answer to that first question in this post.
The fps is low if I select "Full-scene antialiasing" with 8x. If I switch off "post-processing shader" with this value fps fall down to around 5 fps. If "Full-scene antialiasing" is at 4x the framerate is stabil. It doesn't matter if "post-processing shader" is enabled or not.
Perhaps you can only gray-out instead of hidding "Full-scene antialiasing" if "post-processing shader" is enabled? Or do you plan to change this dependency between "post-processing shader" and "full-scene antialiasing"? After Talking about this issue I realize, that "Full-scene antialiasing" is hidden while "post-processing shader" is active. :-)
I'm sorry for the following off-topic question (you can ignore it): Why "Field of view" is limited to 90° in multi-monitor usage? For single monitor configuration I can already use "unrealistic" values of max. 160°. Will be nice if viewing area for multi-monitor usage with more degrees (max. 110°?) are possible in the future.
BTW: Thanks for your fast support with my "little" (known) issue.
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.
)