Quote from JPol :

I'm running 0.6K6 and wanted to upload a hotlap from UF1/WE4, but LFSWorld says: "Westhill hotlaps must be driven with version 0.6H or up."

I thought 0.6K is higher than 0.6H. Am I missing something?

You should be able to upload a replay recorded in K6.

But not K7 or K8 because they have the Rockingham update.

I will ask Victor about this and usually he can have a look in the evening.

Test Patch K9 - Another Rockingham update with fixes for the reported bugs.
https://www.lfs.net/forum/thread/88821

I left it compatible for now. That means the new sunset lighting is still excluded.

Quote from JPol :

I'm running 0.6K6 and wanted to upload a hotlap from UF1/WE4, but LFSWorld says: "Westhill hotlaps must be driven with version 0.6H or up."

I thought 0.6K is higher than 0.6H. Am I missing something?

This is now fixed.

Quote from sicotange :

OFF-TOPIC
Scawen, any plans to implement an InSim start point packet to spawn a car by UCID (x,y,z) anywhere on track?

I am trying to get something done in time for the incompatible version. It's not finished yet but I'm working on a Join Request system. This is what I have so far:

CODE:

OFF_TOP
what about to set handicaps and intake restriction per user?

i have many gamers who dont know how to set it.

btw IS_RQJ IS_RQR - good idea

That is a brilliant thing to add, join request! I will certainly make use of it on the TestingGrounds server.

Whats the use of this? People who are not allowed to join get spectated by InSim software already?

Only benefit is that there are no join/spec/join/spec messages anymore for specific situations (not based on car stuff because that info is missing). Am I wrong?

He is unstoppable ... Do not fear the dark side of the tire physics coding, embrace it, it is calling you

Rockingham/AI related remark (very minor), I have made some AIs to race, and saw that the parking in the pits when the race is ended is a bit difficult for them. FZR ones are keen to destroy the rear tires by engaging frankly the reverse gear (and it does not make them parking better after )

When i shift F11 full screen full hd then shift F4 2 windowed mode all okay but when i shift f4 back too full screen it's 1024x768 think thats not the meaning

Quote :

// JOIN REQUEST - allows external program to decide if a player can join
// ============

Thanks a bunch for working on this! I'm not sure I understand how it works though. Suppose you want to spawn someone driving. Do you send an IS_RQJ followed by an IS_RQR reply with Allow set to 1 and the corresponding ObjectInfo? I see IS_RQJ as a packet to notify LFS that a player is about to be spawned. Or is IS_RQJ triggered only when a player clicks Join (or does /join) and IS_RQR specifies where the player has to be spawned? I'm confused.

Quote from cargame.nl :

Whats the use of this? People who are not allowed to join get spectated by InSim software already?

Only benefit is that there are no join/spec/join/spec messages anymore for specific situations (not based on car stuff because that info is missing). Am I wrong?

1) If they want to join with a specific car, they can be rejected with a message, instead of joining then spectated.
2) A specific player can spawn in a particular place. E.g. a designated safety car player could be made to spawn somewhere.
3) An existing player can be teleported to somewhere else.

Quote from Flotch :

Rockingham/AI related remark (very minor), I have made some AIs to race, and saw that the parking in the pits when the race is ended is a bit difficult for them. FZR ones are keen to destroy the rear tires by engaging frankly the reverse gear (and it does not make them parking better after )

Yes, I have AI parking on my list. Actually they are a bit better on the new tyre physics but they still need work on their parking. I think I am running out of time for that on this patch.

Quote from RC-Maus :

When i shift F11 full screen full hd then shift F4 2 windowed mode all okay but when i shift f4 back too full screen it's 1024x768 think thats not the meaning

Sounds like the previous time you were in full screen mode, you were in 1024x768. First try pressing SHIFT+F10 to go full screen at desktop mode, then you will not see 1024x768 when you use the SHIFT+F4 toggle.

If you want to toggle between SHIFT+F11 and a window, don't press SHIFT+F4. Just press SHIFT+F11.

Quote from sicotange :

Thanks a bunch for working on this! I'm not sure I understand how it works though. Suppose you want to spawn someone driving. Do you send an IS_RQJ followed by an IS_RQR reply with Allow set to 1 and the corresponding ObjectInfo? I see IS_RQJ as a packet to notify LFS that a player is about to be spawned. Or is IS_RQJ triggered only when a player clicks Join (or does /join) and IS_RQR specifies where the player has to be spawned? I'm confused.

Yes, the last part.

IS_RQJ is sent by LFS when the player tries to join (if your InSim program set that option).
The InSim program must reply with a IS_RQR : disallow / allow / allow+position

That leaves the question of where the car will appear if the existing player enters the pits and comes back. I think that should use the same position specified in the previous IS_RQR sent for that player.

We also need one more packet (say IS_OSP - Override Spawn Position) that simply specifies or zeroes the spawn position for a given player. Zero it to return that player to default spawning behaviour.

The IS_OSP also allows the ability to teleport an existing player.
- Send IS_OSP with PLID and spawn position
- /pitlane username
- Send IS_OSP with PLID and zero position (if required)

And the final thought is maybe these positions, instead of being just one override position per player, maybe there should be two override positions per player. One to override the grid start position (on a restart) and the other to override the pit start point (for mid race join and /pitlane).

I like what I read (can't comment on packet structure since I didn't develop an InSim app for too long now). The teleporting was long time requested by many people, I was a bit worried that you didn't mentioned in your earlier post, but it was clarified in the latest.

On that subject, I believe that sometime in the past you said that keeping car status (damage, tire temps, etc) was not possible without recoding a good chunk of the code? I'd love to be able to just help people trapped in the sand, flipped over or out of track boundaries by just putting them in the closest safe place, but keeping their car status.


Joke of the day: have a "bit keepMomentum" to teleport in realtime and make a car version of Portal

(insert celebrations image here)
Really like the new packet. Wouldn't be easier to just have the OSP packet and use this when a player joins or just spectate him? Now RQJ seems to be the same as NPL.

A small suggestion on that, can you add a bit on OSP to choose where you want to reset PLID's car, or just move him to the /pitlane?

Ooo, lots of nice possibilities opening up with these tweaks. (And even the basic stuff like not having newbie players autospecced a bunch of times without explanation has real value.)

Quote from Scawen :

Yes, I have AI parking on my list.

Umm, please forgive me for hoping it's very very very far down the list

Quote from Whiskey :

Joke of the day: have a "bit keepMomentum" to teleport in realtime and make a car version of Portal

OMG yes!

Quote from Scawen :

1) If they want to join with a specific car, they can be rejected with a message, instead of joining then spectated

But this is already being handled by IS_PLC. Wrong car selection shouldn't be possible already.

In the current IS_RQJ handicap, tyres (non rally tires on rally track), passenger info is missing so in most cases there still is an additional join=>spec sequence...

Quote from Scawen :

2) A specific player can spawn in a particular place. E.g. a designated safety car player could be made to spawn somewhere.
3) An existing player can be teleported to somewhere else.

Eeehhhh OK. Always been against this kind of futurism/being unreal but hey maybe I am old fashioned.

cargame is right, this would be far more useful if it contained the handicaps (well, pretty much everything) as in the IS_NPL packet. (Which might suggest that maybe IS_NPL should be repurposed.)

Also, restricting shift-p/shift-s might be nice somehow. Server-side would allow insim to do something custom, but even if just client side (require double-press?) that would solve accidental pitting/speccing (it's been known to happen when responding to chat...)

Quote :

We also need one more packet (say IS_OSP - Override Spawn Position) that simply specifies or zeroes the spawn position for a given player. Zero it to return that player to default spawning behaviour.

The IS_OSP also allows the ability to teleport an existing player.
- Send IS_OSP with PLID and spawn position
- /pitlane username
- Send IS_OSP with PLID and zero position (if required)

Big thumbs up for IS_OSP but will there be a possibility to "forcejoin" a spectating player? I can see several scenarios where it would be rather useful. I suspect this has already been thought through but what about developing the /join command?
/join = typed by player, player joins track
/join username = typed by admin (or sent by InSim program) to forcejoin someone (would respect the packets)

Deleted two posts trying to 'remind' me about tyre physics. We are releasing an incompatible patch this weekend (new Rockingham). Obviously, an incompatible patch s a good time to add a long awaited multiplayer packet that allows many possibilities. Please don't start telling me that two days on a new packet is delaying the tyre physics.

Think about it. Would I really be developing the tyre physics, right now, two days before we release a new update?

Some people here are only here because they don't get enough attention from mum, it will not change.. But eehh ye... So this packet gets redesigned yes? OK

Well, it can't be redesigned, because it hasn't yet finished being designed. We are discussing the design right now, the first time round. I posted the unfinished packets here in order to discuss them and that seems to be working.

P.S. Thank you for all the comments, good points made here!

Quote from cargame.nl :

Some people here are only here because they don't get enough attention from mum, it will not change.. ...

it is not the case (I have a wife and two daughters, I do not request "attention" from mum ). It was simply a small joke on the engineering process done by Scawen when he sees something : he never stops. And this is in my opinion a quality, and this can be seen in LFS ; developpers are willing to do the job correctly, not releasing quickly something to proove they can do it on time as requested by the marketing !
Not at all a request to have you doing tyre physics "right now", Scawen

To not continue off topic comments, in HL mode there is now the "out of bounds" for hlvc. I tested briefly in Single player mode (supposing the same will happen in multiplayer), and of course hlvc is not to be checked there, but can't a time penalty like entering too fast in the pits be applied ? or a pit stop required ... I do not know if it is complex to implement, a too high constraint for players in multi, etc ... but taking properly a chicane and having the guy 3s behind earning 1s by cutting frenzy without warning is something frustating I guess.

Quote from Flotch :

To not continue off topic comments, in HL mode there is now the "out of bounds" for hlvc. I tested briefly in Single player mode (supposing the same will happen in multiplayer), and of course hlvc is not to be checked there, but can't a time penalty like entering too fast in the pits be applied ? or a pit stop required ... I do not know if it is complex to implement, a too high constraint for players in multi, etc ... but taking properly a chicane and having the guy 3s behind earning 1s by cutting frenzy without warning is something frustating I guess.

It is something I wanted to think about but it is hard to make a fair system, to judge what the driver should do. E.g. the driver who cut the corner should give up his place, if a pass occurred, or have some kind of time penalty added if no pass occurred. Normally decided by a panel of judges!

I'm not saying it's impossible do do something that works reasonably well but it could take many days. Anyway, the Out Of Bounds check is done in multiplayer and is sent in an InSim packet, so maybe something can be done in multiplayer mode by an external program even without full path checking.

Quote from Scawen :

Deleted two posts trying to 'remind' me about tyre physics. We are releasing an incompatible patch this weekend (new Rockingham). Obviously, an incompatible patch s a good time to add a long awaited multiplayer packet that allows many possibilities. Please don't start telling me that two days on a new packet is delaying the tyre physics.

Think about it. Would I really be developing the tyre physics, right now, two days before we release a new update?

Is it possible for an incompatible patch to update the start/finish lines for Rockingham? I have posted about it here.

Yeah, a corner cutting penalty could be nice.
Some games force the player to slow down to 50 km/h for some time, but I think it's too dangerous in a race.
The more acceptable thing to do it a marshal commission system that applies a time or stop-go penalty if the corner made you earn time or pass someone.

Hhmm only during my karting career (*cough*) I experienced a remotely switched temporarily speed limiter. It's rarely used in real life racing but it could be very handy for 'us' during short or intermediate lengths of races. Because a pitlane penalty, -even when it's a drive through-, is too heavy.

Hmm yeah, I would fancy a speed limiter packet for a PLID where XX limit for X sec can be defined. The InSim programmer can define by itself a reasonable penalty for a certain situation and car/handicap. Can even be an admin command, not an InSim packet? Or eehh, both of course.