Quote from just2fast :

I´ve seen you have posted the dll code in the Oculus forum and I can imagine there are only 1-3 lines of code which have to be modified.
So I could try to compile a personal hacked dll myself where x,y,z always is set to 0 and to comment out the capability of the headset being able to do positional tracking.
Am I right or is it necessary to modify code in lfs too?

I guess you can do it with the DLL. I don't know how hard or easy that is, but it seems possible as LFS has no other knowledge of the Rift other than what it receives through the DLL.

Among all of the object property adjustments, only heading doesn't update the selected object live, you have to press M or O to apply the new heading.

It looks kinda counter-intuitive to me. When I want to make small adjustments to it without moving the object, I still have to move it again or place it carefully at the same place.

Quote from Scawen :

Quote from just2fast :

I´ve seen you have posted the dll code in the Oculus forum and I can imagine there are only 1-3 lines of code which have to be modified.
So I could try to compile a personal hacked dll myself where x,y,z always is set to 0 and to comment out the capability of the headset being able to do positional tracking.
Am I right or is it necessary to modify code in lfs too?

I guess you can do it with the DLL. I don't know how hard or easy that is, but it seems possible as LFS has no other knowledge of the Rift other than what it receives through the DLL.

Ok thanks, i will give it a try when i am free..

Quote from PeterN :

IS_NCI: unsigned IPAddress;

IPv6 isn't exactly new. Even if the game doesn't support it yet, this packet could at least be forward thinking so this bit of the protocol doesn't need changing in future. A 40 character string is enough for IPv4 and IPv6.

I knew someone would beat me to it

BTW, IPv6 is only 128 bits (4x unsigned, same as 16 chars). There's no need to mess around with strings until you need to display to a human.

Leave the packet alones!

Nah, seriously.. Full IPv6 readyness will imply another incompatible patch anyway when the world is changing to that format, lets change it when it's actually needed.

Some cars are not available on the Kart layout, throwing "XXX can't be used on this configuration" errors. Why?

Quote from cargame.nl :

Leave the packet alones!

Nah, seriously.. Full IPv6 readyness will imply another incompatible patch anyway when the world is changing to that format, lets change it when it's actually needed.

Except some people do have the ability to use IPv6. My server for instance can listen on IPv6 IP for a connection.

Many people already can and do use IPv6. Having support (or future looking support where possible) "now" is an important idea as IPv4 is basically exhausted.

So many websites offer up AAAA records, even LFS, for connecting with IPv6.

Quote from sinanju :

I assume you must mean rounded / curved curbs, as you can now make your own straight kerbs.

Choose concrete / wall in SHIFT U mode
place wall
set height to 0.25 (default is 1.0)
set length and colour to suit

If you make kerbs at minimum length (2.0) and place one, then place others at angle, you can get them to radius quite well - helps now that concrete can overlap onto another piece of concrete without throwing up 'intersection object' errors.

Had futher thought on this, so been playing around making various types of curbs / kerbs.

Best way is to place a concrete ramp, and set it to small length (2m). Further ramps can be placed in straight lines and/or radiused.

Quote from cargame.nl :

Nah, seriously.. Full IPv6 readyness will imply another incompatible patch anyway when the world is changing to that format, lets change it when it's actually needed.

But an incompatible patch doesn't necessarily imply an incompatible InSim update.
As NCI is the only thing that would need changing, we may as well get it over with now so future InSim apps should Just Work™ when the time comes.

For the record, the only things that aren't ready for IPv6 yet are consumer ISPs, short sighted/moneygrabbing router manufacturers and some software. All supported operating systems have had it working and enabled by default for years.

Quote from dawesdust_12 :

My server for instance can listen on IPv6 IP for a connection.

Yeah all my servers too. I'm going to celebrate it with some beers in a moment. Awesomeness.

All who have comments now about NCI needed to be a bit quicker with input when it actually got proposed;
https://www.lfs.net/forum/thread/86589-%5BRFC%5D-IP-Address-Information-In-InSim
https://www.lfs.net/forum/thread/86574-%5BRFC%5D-InSim-Language-Information

I'm happy btw, good work

attachment: first recognizing settings, second step acting on it by offering InSim translations.

Neither of those threads mention the format that it would arrive as, so it's a bit irrelevant. But yeah, 128 bits would be fine, just means LFS would need to output IPv4 as ::ffff:a.b.c.d format addresses correctly.

No it isn't mentioned because it wasn't mentioned. If you do not mention what you would like (+ arguments) then it's pretty difficult to get what you want. If IPv6 was mentioned at that stage then it maybe got implemented differently ... Or... An explanation why it's not desired. Nobody cared about IPv6 back then, it seems. Or cared about the packet in general. Quite low amount of comments.

The whole front end of the skin looks even worse than in older versions, it was fine in 0.6e, though
PS: Not only I am whining about this, and all of the graphics settings are fine

Quote from cargame.nl :

No it isn't mentioned because it wasn't mentioned. If you do not mention what you would like (+ arguments) then it's pretty difficult to get what you want. If IPv6 was mentioned at that stage then it maybe got implemented differently ... Or... An explanation why it's not desired. Nobody cared about IPv6 back then, it seems. Or cared about the packet in general. Quite low amount of comments.

IPv4 wasn't mentioned either, nor was a 32bit IP representation. If they had, I'm sure someone would have pointed out IPv6. It only occurred to me because I saw the 32bit representation in the actual packet.

Either way, as this is an ongoing test patch cycle, things are not final and can (more) easily be changed before it's too late and 'official'.

It's just a suggestion and Scawen is or course free to make the change now or sometime in the future when IPv6 support is actually implemented into the core code.
The only real benefit of making the change now would be one less thing to break InSim applications/libraries in future (when they may not be so regularly maintained).

Quote from Keling :

Some cars are not available on the Kart layout, throwing "XXX can't be used on this configuration" errors. Why?

It has mentioned before by Scawen: Some cars would not fit in the pitlane/grid, that's why. ( Please confirm this though )

Though you can use them with open configuration

Quote from UnknownMaster21 :

Quote from Keling :

Some cars are not available on the Kart layout, throwing "XXX can't be used on this configuration" errors. Why?

It has mentioned before by Scawen: Some cars would not fit in the pitlane/grid, that's why. ( Please confirm this though )

Though you can use them with open configuration

This is correct, there would be cars spawning on top of each other on these configurations default pitlane. You may defeat the restriction with open configurations + custom grids

Quote from sinanju :

Haven't tried it online yet (my servers haven't been updated to latest patch) but in single player mode in 0.6G18, if you place restricted area or a marshall of any type above your head (e.g bridge), then when you drive underneath, you get 'restricted area' message, along with 45 second penalty - in multiplayer mode, that may result in spec penalty rather than time.

Thanks, I found a bug there as well! They were treated as restricted areas if they were floating, and as route checkers if not... completely wrong!

About raised route checkers and restricted areas, I have been trying something here. LFS must allow your car to go slightly below the route checker, because the ground may be uneven. I as thinking this should be OK if I allow the route checker to be ignored if it is more than 1.5m above your car's centre.

I am thinking about checkpoints too. Maybe LFS could ignore checkpoints that are more than 1.5m above your car's centre. Would this cause any problems?

Quote from Flame CZE :

Among all of the object property adjustments, only heading doesn't update the selected object live, you have to press M or O to apply the new heading.

It looks kinda counter-intuitive to me. When I want to make small adjustments to it without moving the object, I still have to move it again or place it carefully at the same place.

Yes, I know what you mean. There is a problem with multiple object selecting and small heading adjustments. Because of the granularity problem, the selected objects would sort of move away along their groove. So in that case it's better to rotate them to where you want them and do the move just once. This is not the case with X/Y/Z adjustments which do not lose accuracy in that way.

I could make a single selected object be adjustable by clicking the heading button. But now it's too late and it will have to be in a later version.

I have fixed the problem of tree trunk / sign / bollard collisions extending into the sky.

Quote from Scawen :

... About raised route checkers and restricted areas, I have been trying something here. LFS must allow your car to go slightly below the route checker, because the ground may be uneven. I as thinking this should be OK if I allow the route checker to be ignored if it is more than 1.5m above your car's centre.

I am thinking about checkpoints too. Maybe LFS could ignore checkpoints that are more than 1.5m above your car's centre. Would this cause any problems?

Not unless any future vehicles are taller than are currently available - and hopefully people who don't read this don't treat it as a bug if they build something overhead that is closer to the ground.

I'm already building my bridges with more head room.

Here are some more program fixes and improvements.
Please have a go and let me know if it works well.
There are also more updated translations. Thank you translators!


Changes from 0.6G17 to 0.6G19 :

Tree / sign / bollard collisions restricted to object size
Circles more than 1.5m above car centre are now ignored
Checkpoints / finish line more than 1.5m above ignored

FIX : Restricted areas and route checkers were not working
FIX : Error with the new Wedge objects at 90 degrees


INSTALLATION INSTRUCTIONS :

To install the PATCH using the AUTO UPDATER :

A FULL version of LFS 0.6G14 or later must already be installed!

1) Start LFS
2) Click Multiplayer... List of Hosts
3) Choose a mirror near you

Alternatively install the PATCH using the SELF EXTRACTING ARCHIVE :

A FULL version of LFS 0.6G17 or 0.6G18 must already be installed!

1) Move or save the patch into your main LFS folder
2) Double click the patch to extract it to that folder
3) When you see "Confirm File Replace" select "Yes to All"
4) Now you can start LFS in the normal way

NOTE : You can see if the patch is correctly installed when you run
the program (LFS.exe). At the bottom of the entry screen : 0.6G19


DOWNLOADS :

PATCH 0.6G17 TO 0.6G19 (SELF EXTRACTING ARCHIVE) (if you already have 0.6G17) :
www.lfs.net/file_lfs.php?name=LFS_PATCH_6G17_TO_6G19.exe (1.1 MB)

PATCH 0.6G17 TO 0.6G19 (ALTERNATIVE ZIP) (if you already have 0.6G17) :
www.lfs.net/file_lfs.php?name=LFS_PATCH_6G17_TO_6G19.zip (1.3 MB)

I've updated my pc and one of my online servers to 0.6G19, but when I go online, all I can see are 0.6G17/0.6G18 servers - I suppose I could be very first, but my server doesn't show in list of hosts - am I going wrong somewhere?

Quote from sinanju :

I've updated my pc and one of my online servers to 0.6G19, but when I go online, all I can see are 0.6G17/0.6G18 servers - I suppose I could be very first, but my server doesn't show in list of hosts - am I going wrong somewhere?

I see one G19 server called "Drift yeah!", so those servers are appearing on the list. Don't know if anyone is missing though.

Quote from Scawen :

Quote from just2fast :

I´ve seen you have posted the dll code in the Oculus forum and I can imagine there are only 1-3 lines of code which have to be modified.
So I could try to compile a personal hacked dll myself where x,y,z always is set to 0 and to comment out the capability of the headset being able to do positional tracking.
Am I right or is it necessary to modify code in lfs too?

I guess you can do it with the DLL. I don't know how hard or easy that is, but it seems possible as LFS has no other knowledge of the Rift other than what it receives through the DLL.

fixed it!

Quote from T3charmy :

Ah alright, well, if possible, could I get the updated one when you get around to it, as well as if you add any new objects beyond that?

I have attached the updated specification to this post. Please let me know if there are any mistakes or it's not clear.

Quote from sinanju :

I've updated my pc and one of my online servers to 0.6G19, but when I go online, all I can see are 0.6G17/0.6G18 servers - I suppose I could be very first, but my server doesn't show in list of hosts - am I going wrong somewhere?

That's no problem. It's compatible with G17 / G18 and I haven't put up a G19 dedicated host, so that's what you should see!

Quote from just2fast :

fixed it!

Good, pleased you can use it again!

Scawen, i have one idea. New objcets is very good, pit stop, start point but why you not make pit speed line limiter? I mean 80km/h zone in pit. Sorry for may bad English.

It is a good idea but we have just run out of time for that in this version. It can be done using InSim though...