Quote from eddy678 :

i downloaded a layout for fern bay rallycross green and i wanted to race with an Ai but it thinks that there is no layout there and drives into the barriors

Turn on ideal line (top row number 4) to see where the AI are trying to go

Quote from bunder9999 :

the AI probably shouldn't be allowed to drive on the open configs... they aren't on autocross for the same reason (no paths).

Quote from Flame CZE :

They are not allowed to drive on open configs.

This isn't an open config, it's Fern Bay Green with AutoX objects placed. You are right in that AI cannot drive open configs, but this is legitimate as far as the race start logic is concerned.

I think this is a bug. The race should not be able to be started with AI, and when any AutoX objects are placed, not just a start position.

Quote from E.Reiljans :

There are 2 different types of PTH files - ones that are used by LFS, and one that's used in .pth's in this archive. The difference between them is pretty huge, at least header, can't be sure about node data blocks.

Thanks, I updated my post just as you wrote that by the looks of it. A schoolboy error methinks.

Quote from PMD9409 :

Most of EQ Worry's posts about the .pth files are in this thread.

A picture. Another. Last one.

And maybe another useful post.

Very interesting. I was reading through that thread, and somehow missed EQ Worry's "useful post"

My experiment has finished, and the ideal line seems to be set in stone (read pth) I cannot detect any differences either between the visible ideal lines for AI with different setups, nor different cars. The only file updated is the .trs in the knw folder.

I surmise that the ideal line is probably a best fit curve for the shortest path between intersections of path nodes and road limits, plus some other factor that accounts for velocity perhaps, or even between the node centre and road limit on the shortest path.

How did you generate the ideal line in your images PMD9409? Are they a merge of the originals? It looks like they get a bit wobbly where the different configurations join.

Quote from cargame.nl :

I don't know how EQ Worry did it but custom PTH files are succesfully used. I already have some custom PTH files from 'merged tracks'. I have to ask how he did that. But it is a tremendous amount of work to create PTH files for tracks with new corners in it. (He said that somewhere here on the forum).

So I look for a way to ease that a bit because it greatly limits the power of open track layouts. Off path detection is needed to invalidate lap timing for example.

And I'm just interested myself in the logic behind it. Great discussion!

I've searched for possible merged pth files and found non. Did Eq Worry send them to you off forum? Would you care to share?

I've been looking at the .pth files and I'm having trouble already. Firstly there only appear to be 11 in the pth folder. AS1-7, KY1-3, and WE1.The pth.txt published for patch Y doesn't seem to describe what I'm seeing. Anyone know if its valid for the current format? According to the header, offsets 6 and 7 contain the version and revision respectively, but I see 00 and fa. That's ok, but pth.txt says "0 - do not read file if > 0" for both entries. Also the node count at offset 8 is zero. I'm thoroughly confused by it now. Any tips would be welcomed.

Dygear, I think this might be what Cargame refers to.

[Edit]
Doh!
I'm looking at the pth folder, and I guess they are compiled. Offset 0 should read "LFSPTH" not "SRPATH" Look at the .pth files in SMX_PTH_S2Y.zip instead. In other words ignore my previous comments.

A sample merged .pth file would be nice to work with though.
[/edit]

Last edited by Squelch, Mon, 16 May 2011 05:36. Reason : Doh!

Quote from jrs_4500 :

Hmm... so let me get this straight. The BL rally sections are no longer accessible in the open track configs? If so may I ask why this was done? I really don't see a reason to, it makes the open configs useless for BL, doesn't help anyone afaik, and just takes a fun option away. Not trying to offend, but I won't be downloading Z33 if this is the case. Still happy with Z28 and Z32 for now.

You have the wrong end of the stick. BL rally sections are still there for open configs. The only differences are that barriers along the sides of those sections are back. This means you cannot drive into the lake for example.

There is no obligation to download any of these test patches. They are exactly that - for testing and bug reports.

Quote from Dygear :

As it turns out, you can get this from the PTH->Nodes->Limit, it gives the left and right limit of the track given as a float.

You beat me to it

Quote :

NODE BLOCK :

1 int 0 centre X : fp
1 int 4 centre Y : fp
1 int 8 centre Z : fp
1 float 12 dir X : float
1 float 16 dir Y : float
1 float 20 dir Z : float
1 float 24 limit left : outer limit
1 float 28 limit right : outer limit
1 float 32 drive left : road limit
1 float 36 drive right : road limit

And the full quote giving an explanation just for reference

Quote from Scawen :

Path nodes are described in the PTH documentation found on this page :

http://www.liveforspeed.net/?page=coderfiles

And here's a description of them, I'll write on the spot :

They are a series of points with direction and width that describe the track that you drive along. LFS uses it to watch your progress along the track, decides if you are driving in reverse. They provide the data for the echoes and the lightmaps, hold information about which objects you can see from that point, define the left and right boundaries for the AI drivers and are also used in yellow and blue flag systems, the position list, timing and some other things.

Their length is not constant but there is approximately 0.2 seconds of time between passing one node and the next, when you are driving at a reasonable speed.

I'm guessing avetere generated his svg using that data, and using interpolation a new path could be written out. Another thing that strikes me, is will an open config layout even attempt to read a path file? The existing ones are all named per existing track configuration, and we only have the [x,y] suffix which does not indicate a particular route. It would also need to depend on the layout file for which there has never been a path association.

Last edited by Squelch, Mon, 16 May 2011 01:25. Reason : Added a caveat

Quote from Dygear :

We can get around the whole track with the pit limiter on. We could just use that, taking MCI snapshots of our X, Y, Z every 0.2 seconds (200ms) that should give very even results that can be use inter-portably between different layouts.

Very good idea. I was just thinking about layouts. There would need to be a valid/verified pth for each and every layout wouldn't there? I'm guessing that Scawen has never released, or intended to release a path editor because the paths for the official configurations were all that were needed. Any autocross layout - as I imagine was originally intended for only autox - would have been beyond the original scope. That has all changed now if open configs are here to stay.

Quote :

But we still need a way of knowing the width of the track, but again for that you might be able to use the current node data, I would expect that to be the same (I hope anyway.)

Yes the existing node data should still be relevant, it should only differ in its direction and where they fall in between existing nodes, they could be interpolated. As far as track width is concerned, can't this be extracted from the smx files?

[Edit]
I just had a horrible thought.

Cruise servers would like to be able to drive both ways on a section of track. If the existing nodes widths (not inter node distance) are used, there would be a conflict. This is also true for rally style layouts that may use the same bit of track, so some method of defining the width would be needed too. Not something that is too pressing right now, as the paths - any paths - need to be created first, but worth bearing in mind. [/edit]

Last edited by Squelch, Mon, 16 May 2011 01:12. Reason : Added more conjecture

Quote from Whiskey :

That could be the rubber on the most used area? So if you choose only your own car there are less layers of rubber.

I believe you are correct. I thought about it after I read back what I said before.

Quote :

I knew I have read that somewhere hehe

Good find! That sort of backs up the theory that a car was used to set the initial paths, but as you say, which one? The spreading out of the nodes in avetere's svg also suggests that they were placed/recorded at different speeds too, so the reasonable speed may have just been different for each configuration.

Quote from Scawen :

Path nodes are approximately as long as 0.2 seconds of time when driving a car.

That is because the original path nodes are created by driving a car smoothly around the track, then connecting the resulting path as a loop. A path node is created 5 times per second, with the position and direction of the car.

But that depends which car was used, so that's why the 0.2 seconds is just a rough guide. Anyway this means the path nodes are more spread out at higher speed sections of track.

That quote just about confirms it.

So, now to find the secret sauce that allows recording/updating paths. I'm still running my empirical test just to see if something crops up and some correlation can be made.

Quote from Dygear :

The question becomes, 0.2 seconds for what vehicle? 0.2 Seconds for a UF1 is different from that of a BF1. Do you use the lowest vehicle's time as it offers the greatest fidelity to all vehicles?

That is a good question. If for example the path is recorded using a UF1, then because of the lower speeds, the resolution would be higher. This by implication would mean all faster cars would be able to use this path.

Quote :

Might be able to do this pretty easily. You would have to load each PTH file to find out if the players point was in the poly, but other then that should be ok. This does assume that every part of the track as a node for it, and that it's node does in fact connect to every other node without overlapping each one.

I'm testing that theory right now. There is an entry under options/misc - Update path Off/User Car/All Cars that I don't quite understand. Does this mean the path is dynamic? Anyway I have an AI with a bad setup driving Aston right now. Assuming the AI tries to drive the ideal line whenever possible, I'm letting it do its thing, and do not see any obvious change in ideal line - yet. The bad setup means it cannot keep a good line, and my hope is once done, and a restart performed, There will be a different ideal line, and by implication, an updated path. I'll compare screen shots of a few corners at different points and between the sessions, as well as run a diff on the files to look for changes.

Quote :

I don't think it will help for when there is a transition between layouts. For example going from AS3 to AS5 might have a small gap between the nodes, or it might have two nodes over lapping. This would be a huge issue as a player can't be in two nodes at once. We would have to make our own node set from scratch!

I see what you mean now. However, I have this feeling, and from various comments Scawen has made over the years about his use of AI drivers, that the paths could generated dynamically from a reference AI car. If the track was driven once, or a standard set of path nodes generated automatically, then letting the AI learn and record a new path seems plausible don't you think?

Quote :

That's a very good point. I have no idea how this is generated. I have no idea if the line moves as per each car on the track, or if it's just correct for your car type, or if it's just the same for all cars.

I was wondering that, and perhaps my experiment will show something up along these lines. It may well be that the ideal line is a shortest path bounded by the track limits and a best fit between along the path nodes.

Last edited by Squelch, Mon, 16 May 2011 00:04.

I watched this the other day and thoroughly enjoyed it.
Bad Boy Bubby

It is typical Australian cinema. Disturbing, moving, funny, and totally captivating. One nice quirk is that virtually all of the sound was recorded from the main actors (Nicholas Hope) perspective using two microphones hidden behind his ears.

Some interesting ideas going on here.

Just to float some ideas; The paths that avetere shows in his SVG image seem to differ in position only, and may be from the relative velocities of the vehicle that possibly recorded them. Would a matching algorithm work for finding the nearest node in the direction of travel work? Dygear's 2nd suggestion could be combined with this to reuse the most appropriate path for any given configuration.

I'm not sure how the ideal line is generated, but it isn't just a spline fit. I'm guessing the velocity/mass of the vehicle is also fitted to this curve.

[Edit]
Whiskey makes a point that backs up my observation.

Quote from Whiskey :

Aren't the nodes separed by about 0.2 seconds? (I think this appear on some documentation)

The difference in positions - take the northernmost bend for example - seem to indicate they were "sampled" at regular intervals. At the apex the speed would be about the same for all 3 regular configurations that use that bend, and they all pretty much overlap. Where they stretch out may be down to the setup of the recording vehicle (different gear ratios?) if that is indeed how they were generated.
Like Whiskey, my observations need a disclaimer too.
[/edit]

Last edited by Squelch, Sun, 15 May 2011 22:40. Reason : Included Whiskey's reply

Quite some time back this was talked about (LFS spectate?). My suggestion back then was to encapsulate a replay file as a broadcast rtp stream.

I've experimented with VideoLan that can render directx to a transport stream from a client connected as spectator. This only takes one slot on the server, and can be done on another remote server to feed the live stream. I had mixed results however, and perhaps someone with better kit than me might have more luck.

Quote from =Wolf=[NO] :

My idea:
*Let demo players connect to S1/S2 servers.

Using a stream there would be no LFS connection other than the official spectator.

Quote :

*They can NOT join race.

Same as above.

Quote :

*They can NOT chat.

Can be provided for via IM server.

Quote :

*If server is full, and S1/S2 user connect, they will be autokicked, or autokick to always keep one spot free on server.

Not needed if using the official one spectator slot.

Quote :

*Server hosts can themselves deside if they want this feature( /demospec=yes/no)

Server admins can decide not to allow the streamed spectator.

Quote :

In this way Demo users can see what is avalible in multiplayer: clean racing, n00b free servers, dedicated servers for drifting/cruise(I know, RACE sim, but it accualy sells )

I totally agree with this last point. I have long wished for a method of watching the big races without having to take up a slot, or having to wait for edited highlights.

The streamed method would work on services like Ustream, which also has a chat client attached. Another benefit of this method would be that the spectating streaming server could also be human controlled.

Anyone fancy trying thier hand at race coverage directing?

[Edit]
The old thread is LFS TV and I seem to recall an even older one that was on RSC "Live to Spectate"

These threads should be read too:
Guide : Broadcasting LFS
OLFSL Streaming
LFS-TV, replay streaming.
[/edit]

Last edited by Squelch, Sun, 15 May 2011 21:46. Reason : Expanded some thoughts

Quote from Dygear :

Can we get an option in multiplier races to save an SPR. This would allow us to save the reply as our client sees it and not as the final outcome that the MPR has. I think it would help you with your debugging.

[Edit]: Apparently Broken has already suggested this here.

Wake up mate

I must have driven that corner a hundred times now to try and replicate the issue. Every time I'm on the throttle later than Spiderbait, It's just a difference in driving style I suppose.

Can anyone else replicate this?

Last edited by Squelch, Sun, 15 May 2011 19:59. Reason : name correction

Quote from spiderbait90 :

I tried to replicate this bug in other vehicles, but so far only the XRG has done it, on that specific corner (SO5R Hairpin), more than once [the other time it happened was before I was intentionally trying to do it, therefor the replay wasn't saved].

I am going to see if I can replicate the FXR, SO3 one too.

I've just bee analysing your SPR and there seems to be a texture join at the point the car gets launched. The previous reports also seem to happen around similar points, so my earlier theory might still hold water.

Image sequence

1. The front wheel force shows the start of a bump in road surface. Texture join highlighted.
   
2. Rear wheel forces for same bump (closer). Join just above highlight.
   
   
3. Rear wheel just after the join (highlighted) and at point where the car is "launched"
   

[edit]I just checked my replay, and I don't accelerate so soon which might explain why I can't replicate. In image 2 there are forward acceleration forces just before the "bump" which immediately disappear at the join. Later frames show a negative force on the rear wheels as the car is launched [/edit]

Last edited by Squelch, Sun, 15 May 2011 17:18. Reason : Added stuff

Quote from spiderbait90 :

Here is an SPR of the ghost collision, 1st lap, hairpin on SO5R.

Good catch!
I tried to replicate, but couldn't so far.

Broken started a thread in improvement suggestions relating to these incidents and SPR detail in MPR's.
http://www.lfsforum.net/showthread.php?t=74351

I think you are referring to the phantom collisions that have been reported during multiplayer sessions using the latest patch sets.

Scawen has said it concerns him, and I believe there are too many occurrences of this to ignore now. What you propose is an excellent idea, as all data on the local machine would be recorded, and not just the car position that simply shows the outcome in an MPR.

Looking at the MPR's for those reports does not reveal any significant forces acting on the car at the time of the incident. Perhaps a local SPR would show more of what is happening.

There could be another important benefit other than this bug hunt. That is a player could view live how a car behaves while slip streaming which is difficult to interpret from a RAF. This could greatly aid set up tweaks.

Quote from bavorak :

well speaking of hotlap analyzer it doesnt show any of new hotlaps...seems like lfsw just takes everything you give it without performing the necessary actions like checking if it isnt a cheat or generating a RAF file

A simple test would be to see if the delta is more than 5 seconds below the average time set. There might be a legitimate hotlap set, but at least a potentially bogus one would be flagged and investigated.

BTW, I don't see that hotlap on LFSW, so I guess it's been removed.

[Edit] message to self. refresh page before reply - thanks Scawen/Vic [/Edit]

Quote from Scawen :

Speed limit no longer enforced if autocross start position exists

Thank you for that one in particular as well as the rest of the fixes.

Quote from boothy :

Scawen - some of us had been making rally layouts, taking advantage of the lack of walls to create new routes - is there any way these could be reinstated with say, a config parameter or something? Perhaps in misc options - enable barriers in open configs - yes/no, defaulting to yes?

Quote from PMD9409 :

BL3X could be used to disable the barriers on BL2.
AS7X could be used to disable the barrier on AS2 final turn.

I'm not too bothered about the Kyoto walls blocked off, but we were going to have a WRC style event/league, but these fixes has hindered that possibility quite a bit.

Hehe, what a dilemma. It seems Scawen is damned if if he does, and damned if he doesn't. I like the fact we could use some off road sections between the barriers in exactly this manner. Some of the reports of missing barriers however, have been just for the sake of it I feel (lake?), but in many cases they have been legitimate places where a mistake could lead to passing through scenery into the netherworld.

I still like my tape idea for those areas that need marking off, but don't necessarily need a physical barrier.

I'm off to test this now.

Last edited by Squelch, Fri, 13 May 2011 20:31. Reason : speeling

Quote from CodieMorgan :

Someone post original VOB for FZR please - it seems like mine is corrupted ( and I dont want to redl LFS again )

D;

^ might be the reason im getting JOOSED in Z32??????

Quote from Flame CZE :

http://lfsdb.500servers.net/lfs/0.5Z28/data/veh/FZ.vob

Beat me.

Just in case, here are the checksums from z28 fz.vob

CRC32: 46692652
MD5: de08d300ecfa441b3aacaafc79268635
SHA-1: 015c423793f5ed1cf2243eb9dc1148ed20abbd3d

I use this tool for checking, but there are others out there.

A quick request: Can checksums be published please? I still don't know how or why I ended up with a broken installation, but being able to check against the checksums would have helped.

Quote from Squelch :

Thanks for confirming that. I'll try a fresh install and update from z28 instead. A broken update method is the only possibility I can think of.

It appears it was a broken update. I updated z31 to z32, and although it looked correct, I ran into problems while bug hunting. A fresh install of z28 and updating to z32 fixed the problem.

I'm posting this feedback so that it might be considered should any one else run into similar problems in future.

Please accept my apologies for wasting time.

Quote from Bokujishin :

I have to say I don't understand why the camera does this on your video. I did the exact same thing and the camera stays on the car, whether I click "lock" or not...

Thanks for confirming that. I'll try a fresh install and update from z28 instead. A broken update method is the only possibility I can think of.

Quote from Scawen :

I still can't reproduce the bug. I've tried in an SPR and an MPR, if I am paused and following a car I can go backwards using the < key or clicking earlier on the replay time bar and it just stays with the car every time.

Quote from Bokujishin :

I tried too, and I can't reproduce either. I'm not locking the camera, only following, but it stays with the car while stepping backwards
...

Thanks for checking. For some reason I didn't explain myself very well previously (distracted by RL issues)

Please see this video which shows the problem I see.

http://www.youtube.com/watch?v=oXq_tydw0ZM

The replay is paused and I enter Shift+U and set follow.
Stepping forwards is no problem, but stepping back [index 0:27] the view is reset.
I return to the car, and follow it again but this time locking the view [index 0:44].
Stepping forwards is again without problems, and stepping backwards now stays with the car [index 0:50]
I then turn off the lock and the camera is once again reset when backstepping [index 1.04]

The last part of the video shows what happens when I do not return to the car, but set follow mode from the reset camera position. Stepping forward works as expected, but when I backstep, the view is not only reset, but increases in distance from the car. Repeating this (using reset camera position and frame stepping) the camera gets further and further from the car. [indices 1:17 and 1:24] This later part is new to me (I didn't keep Z30/1 so cannot check back).

Is this the desired behaviour?

[Additional info]
The replay is a saved SPR made with Z32.
Method of updating was to copy and overwrite contents of Z31 from zip. Paths were maintained.

This last point is the only thing I can think of that might be different. Should I have updated from Z28?
[/Additional]

Last edited by Squelch, Sat, 7 May 2011 17:18. Reason : Additional info

Quote from Scawen :

By your description, you should not be following the car when you press the < key. You exited SHIFT+U and went back in, so at that point you are not in follow mode.

Sorry I missed a step.

Basically it this happens when the replay is in pause mode. My recipe should have read

6.5 Follow car again

The follow cam works while stepping forward, but the moment you step backwards the view is reset to a static view at the point the original follow car command was invoked. Locking toggle the view seems to "set" the point at which the view is reset to (and this includes a non static follow cam) I can confirm that the car is followed after a replay restarts (which it didn't do before) it just seems paused rewind is the problem now.

Quote from azasmith14 :

The fence issues start at that point. I can also do it past that point. If I drive past, then come back. I can do it all the way up to the point where you fall off the edge of the track.

EDIT: http://www.mediafire.com/?xbonydw76doe0zi

Most other places, you can still get caught. But the fence spits you back out again so you're not stuck.

I still can't see what your replays clearly show as a problem. I even tried the same car. See replay.

Perhaps someone else might be able to confirm.

Any mods by chance?

Quote from azasmith14 :

Replay added to previous post.

The only place I didn't drive.
I think the bridge is intersecting the fence at that point. The fence is solid all the way before and after that point up until the stands where you fall through the grass.

Quote from Inouva :

Same here, but it happens in certains camera angles, when you are in cockpit or any default LFS camera there is no flickering at all

Even watchings replays with the TV camera there is no flickering at all

I see the same. It is only at a long distance that the z-buffering fight seems to happen. This is also seen in other game titles btw.

Scawen, the follow car is still exhibiting lost focus on rewind. Locking the camera seems to have the same workaround.

Steps for replication.

1. Start replay
   
2. Enter Shift+U
   
3. Follow car
   
4. Exit Shift+U
   
5. Pause replay
   
6. Enter Shift+U
   
7. Step backwards (< key)
   

You find that the view is reset to the original follow car position. Locking the view still has the effect of setting the camera, but subsequent changes to view are lost without toggling the lock.

PS. We need another name for Shift+U - free camera perhaps?

Last edited by Squelch, Fri, 6 May 2011 18:07. Reason : grammar

Quote from azasmith14 :

It's solid for me. Up until the point where you get to the Petronas board with lfs.de on the opposite side. From that point on it's still possible to get caught.

Definitely running Z32.

Hmm, that seems odd. The fences are solid in the position you say. The only problem I had was falling through the grass in front of the stands while driving along the fence, but that hasn't been addressed in this patch, and I consider this area to be no drive anyhow.