As Racon said, please make sure you are on the R21 version. I'll try to answer your individual points below.
The preview is still available.
If you placed the objects with the O key, as in the old editor, then the preview (for the next objects to be placed or where to move the current selected objects) is available just as it was in the old editor.
On the other hand if you placed the objects with CTRL+V then the preview isn't immediately visible but you can make it visible by pressing CTRL+C.
You can hide or show the preview for the selected objects at any time with CTRL+C.
You can hold SHIFT to keep objects selected when exiting edit mode.
So for the case you are talking about that is now SHIFT+SPACE.
R21 contains fixes, updates and rewritten instructions docs\Autocross.txt
New layout editor instructions: docs\Autocross.txt
Improved UNDO and REDO - the selection is now correctly restored
Start position / checkpoints / finish line now in control section
FIX: Heading slider bar was not restored after a failed rotation
FIX: Zero diameter marshalls could be placed in the same position
FIX: Diameter stuck after adding a circle when diameter was zero
New value PMO_AVOID_CHECK for PMO_ADD_OBJECTS avoids validity check
"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.
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.
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.
Maybe the TCP packets are getting through but the UDP ones are not (they are used for the List of Hosts - and we don't know if you are having a problem with sending or receiving them - could be either).
OK, I've found out the internal use of suppress_warnings isn't needed if there is a move_modify flag (because warnings about timing errors should be suppressed whenever objects are simply being moved/modified).
So what I've done is replaced the slightly unpredictable PMO_SUPPRESS_WARNINGS and instead there is a new flag PMO_MOVE_MODIFY with the same value.
It is now sent in both of the packets (add/delete) of a move/modify pair and in all cases when an object is conceptually moved or modified, including marshall object changes and when typing a start position index our a route checked index.
It looks simple to add a new flag in these cases, one that is ignored by LFS but should be output to InSim. It's easy for me to locate those cases where a modification or move is taking place (where it sends a delete immediately followed by add).
What exactly is it you would like? Something like PMO_MOVE_MODIFY (value 8) and that same flag would be placed in the delete packet and the add packet when they are being sent as a pair?
Is there any need to distinguish between (1) moving objects and (2) generally changing attributes like colour, size, etc? Or can they be treated all the same? There aren't all that many flags available in that byte so I only want to use up the minimum, but of course it should be as useful as possible.
We are getting very near to the end of this series of test patches now as I must get back to the real stuff I have been working until interrupted by the attacks.
I'll have a look at this, which is almost a bug, and see if I can implement those sub-mode states mentioned in your other post.
In the new graphics system that Eric is using to update the tracks, we have textures that use the alpha channel to control the shine level. So that would seem like a nice thing to consider on skins of the future but definitely not in this version.
You can press CTRL+C if you want to copy the objects.