The online racing simulator
Test Patch 0.6R8 (now R22)
(407 posts, closed, started )
Quote from Scawen :I don't know why, but some people find that option really hard to find.

Options... View... Full width external views

make the default setting to be on if people are complaining about it?
Quote from Scawen :New value PMO_GET_Z for IS_AXM packet to report Z values

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 Wink 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.
Quote from Scawen :I don't know why, but some people find that option really hard to find.

Options... View... Full width external views

Been using my Ultrawide for over 9 months... Only just found out LFS has the ability to remove the black bars Rofl

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. Rofl
Sounds like being CNC-Machinist for 30 years with exact same machine, but only now have found out the real potential.
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.


Quote :Original objects are now shown with grey lines after copy pressed

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..

-
(THE WIZARD DK) DELETED by THE WIZARD DK : misread something...
The latin character set is not the only character set in the world which can be used in that box

(and this has nothing to do with what this test patch is about)
Quote from FreeScirocco :The latin character set is not the only character set in the world which can be used in that box

(and this has nothing to do with what this test patch is about)

have been testing R18 for some time now.

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 Smile

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 Smile )

---
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 Taped Shut
Quote from cargame.nl :---
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 Taped Shut

i had a simular thought some years back. good idea. but perhaps make it in suggestions ? if not there already!


EDIT: and... another thing. how about getting a multiclass server up and running Dave? you did have the best race servers for that in LFS. we could use some of that kind of racing again in LFS Smile
Quote from THE WIZARD DK :but perhaps make it in suggestions ? if not there already!

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).
for sure the ctrl-z function would be a nice feature, but it is not necessary easy to implement (without doing dirty things)
Quote from sicotange :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.

I've fixed this in R19 which I hope to release today.

Quote from sicotange :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?

Yes, after you adjust the height of the objects in hand they are no longer identifiable as copies of the original objects.

Quote from iceman121 :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)

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).

Quote from THE WIZARD DK :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 Smile

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 ?

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"

Quote from cargame.nl :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.

...

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.

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.

Such as: (this is completely made up)

3
56634, 24234, 56, 23, 129, 30
9934, 63543, 23, 122, 23, 90
5356, -33432, 80, 85, 23, 23

(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

Quote from cargame.nl :One other thing... Has an undo move object function ever been considered?

I've done this in R19 which I hope to release this evening.

Quote from Aleksandr_124rus :a lot of suggestions

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.
R19 :

Layout editor :
Undo (CTRL+Z) and redo (CTRL+Y) functions now included

Interface :
Improved readability of the text for the /cp command

InSim :
Fixed an inaccuracy in the reporting of objects being deleted

https://www.lfs.net/forum/thread/92067
Quote from Scawen :

Such as: (this is completely made up)

3
56634, 24234, 56, 23, 129, 30
9934, 63543, 23, 122, 23, 90
5356, -33432, 80, 85, 23, 23

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!
Quote :InSim :
Fixed an inaccuracy in the reporting of objects being deleted

Thanks!

Quote :Layout editor :
Undo (CTRL+Z) and redo (CTRL+Y) functions now included

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.
Quote from sicotange :Selection changes (real and in hand) are not taken into account?

It doesn't remember the type of selection, it just does a default selection type.

I think the resulting selection after an undo is 'clipboard' if the original operation was adding objects, 'real' otherwise.

Do let me know if anything is confusing or seems wrong.

Quote from sicotange :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.

I'm not sure how to reproduce that.

If I join a local host and I send add or delete packets (by deleting or adding an object in the layout editor) my UCID is reported.
Quote :I think the resulting selection after an undo is 'clipboard' if the original operation was adding objects, 'real' otherwise.

This seems to be the correct approach.

Quote :I'm not sure how to reproduce that.

If I join a local host and I send add or delete packets (by deleting or adding an object in the layout editor) my UCID is reported.

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) DELETED by THE WIZARD DK : NVM. it installed it now.tho pretty weird..
-
(Ezzegydrift) DELETED by kristofferandersen : irrelevant to test patch
Offtopic posts moved to offtopic thread.

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.
Test Patch R20
R20 - LFS.exe and DCon :

InSim :

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!

https://www.lfs.net/forum/thread/92067
Quote :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)

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.
Quote from Scawen :Offtopic posts moved to offtopic thread.

This is not a magic patch in which everyone's incompatible requests will be implemented.

i knew this would happen.. we wizards really need a union Tongue

Magically enough i actually stayed on topic here !

Smile
just got an update for the following...

.NET Framework 3.5, 4.5.2, 4.6, 4.6.1, 4.6.2, 4.7, 4.7.1

which im thinking is my problem...


EDIT:
Defo was my problem.
i only get a little bit static now whenever people goe in/out pits.
skin downloads seem to not affect me at all now. so defo my problem.
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).
Sorry - This issue is not test patch related. I can reproduce this issue in the current public version too.
This thread is closed

Test Patch 0.6R8 (now R22)
(407 posts, closed, started )
FGED GREDG RDFGDR GSFDG