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.
Outline changed to line drawing which helps with object alignment
Original objects are now shown with grey lines after copy pressed
Drag select now has a minimum size to avoid accidental deselection
FIX : Heading bug after un-copying selection that had been rotated
FIX : CTRL+C un-copy cleared selection if originals were not found
FIX : Chalk objects were sometimes invisible in copied selection
It sets the one nearest to the centre of the rectangle as the last selected object.
Thanks - fixed.
Replying to you and Degats here.
How about if the originals were shown with a grey outline?
This is because LFS thinks you are doing a box select with a zero sized box. Maybe this could be fixed by only doing a box select if the box is a few pixels in size, or at least the size of a selection button.
Alternatively a box select could be ignored if it doesn't include any buttons.
Thanks everyone for the positive comments. Those of you who do follow the forum know why it was worth spending a few of hours getting this little update together. Please you've had some fun with it. That's what LFS is all about, in my opinion. Having fun.
There's so much content that you have never tried. We offer so much more than just Blackwood and 3 cars. But you have never tried it or contributed to our development. I guess you think it's a free game and we can live on nothing.
We're also working on loads of new things and don't need any comments from scroungers who can't be bothered to have a look around to find out what we are working on.
Would it be helpful if the M key was allowed to work after you have pressed CTRL+C?
I haven't tried it yet but it seems possible. As you know, the CTRL+C is reversible because the editor knows which objects were copied. So it seems that in those cases where you have a tricky move as you described, you would then be able to see the originals and the new position at the same time before pressing M.
I am aware there is still a copy of the old 0.5F version of LFS, that was never released but was leaked in 2005, available on the internet and it's not too hard to find.
The only problem: there was no easy way to unlock it.
In fact there are other problems too... the LX8 GTR is way overpowered, underdeveloped and barely driveable! But I know there are people around who want to drive it so why not let them have a go?
So I had a look in some old backups on floppy discs and DVDs, started up an old computer that has a floppy disc drive and managed to get it compiling and made a few changes to make it work with new new master server and recent versions of Windows.