The new open configurations seem to have created a confusing hybrid.
On the one hand we have Autocross layouts, which, like rally stages, have a pre determined start window for the individual racers. The count down for this is fixed and does not have a random element.
On the other hand we have multiplayer races, which have a random pause before lights go green. This prevents drivers anticipating the start, and is a way to show the drivers reaction skills, and therefore spreading the start.
The former is correct for autocross layouts in my view, but because of the new hybrid, a full race on open configs is missing the random pause therefore allowing anticipated starts. Maybe there should be two race types allowed for. Autocross/Rally starts with full countdown, and Full Race starts with the random pause. The open configs have really opened a can of worms in some respects.
Thank you
I mis-edited my last post, and i meant SPR of course.
Looking at the force view of the MPR, there doesn't seem to be any suspension travel at the point of going airborne. Only when the car hits the track afterwards do we see anything.
There is a slight dip in the track at that point, and I'm wondering if it is coincidental with a dropped packet or lag, that then sets the car at that angle. Prior to the incident, the car does twitch around a bit. Pure conjecture, but feasible seeing as no-one else can reproduce this.
[EDIT]
Is the complete MPR available? I think I've spotted something while viewing Jenk who was following in another LX. they take almost the same line as Tango where the left front goes over the manhole cover. I see some incomplete skid marks at the join in the track, and would like to see how Jenk's car behaves when going over this section. Unfortunately the supplied MPR stops just before.
Tango's car not only gets the front end flipped up, but the orientation flicks to the left too (out of order packet?) almost like a car reset.
[/EDIT]
Last edited by Squelch, .
I've checked all of the other tracks, and couldn't find any other instances of this problem, so it's unique to Fern Bay.
To me, it seems like there is oversized collision geometry around the upright section of the gantry that encroaches through the barrier. Is collision geometry even required here? The barriers would normally prevent hitting the ironwork from either side, and the only foreseeable way of actually hitting it would be if the car was already airborne and jumping the barrier. I note that when driving behind the spectator wall, none of the other track furniture has collision geo, so these particular ones are unique.
I tried to repro this one too, and couldn't either. The replay would be useful to have.
The keys are already mapped on the keyboard.
Top row number keys
7 = left indicator
8 = right indicator
9 = Hazard blinkers
0 = cancel
It is possible to use mapping/profile software to allow these to work on your controller.
benjie.13 shows the solution except for the ALT + F4 combo, and this part of the controller setup allows for the less used keys to be remapped.
Last edited by Squelch, .
Reason : Added stuff
You just keep away can you? I thought you said this was your day off
I think the accidental ones will turn up through well, just accidents. Being an expert in this field, I'm keeping an eye out.
Enjoy the rest of your weekend.
PS. Will swapping the exe to make comparisons be a good idea? I noticed there was some other content in the patch too. Will Z28 have problems here, or is separate install recommended?
Last edited by Squelch, .
Reason : Added post note
That problem is common to all instances of those gantries on Fern Bay, even standard configs. Hit at the right angle, and the car gets fired backwards violently, or shot forward at incredible speed.
Robert Kubica might disagree with you there.
The improved barrier collisions are so much better despite that anomaly when hit end on or at a strongly oblique angle. I think the later has much to do with the current tyre contact patch model, that tends to climb objects rather than bounce off.
First up, what a brilliant set of updates - Congratulations.
A mate and I like to set up gymkhana/special rally stages for each other, and the open configs plus the ability to add (more) objects to all tracks is a boon for us.
A couple of observations further to the ones already mentioned:
A mate and I like to set up gymkhana/special rally stages for each other, and the open configs plus the ability to add (more) objects to all tracks is a boon for us.
A couple of observations further to the ones already mentioned:
- Flags. You stated that flags would not work with the new open configs, and that is to be expected, but pit lane infractions are still working, and from my pov, are a hindrance - BL pit lane makes some nice tight complexes - Any chance these could be removed for open configs too?
- Run off areas. Some of the run off areas that are now accessible do not have a surface as already noted. Apart from the most obviously wrong ones close to the track, I believe some can be left where they are so obviously out of bounds. Places like the BL lake (why drive there?) and further into the tress beside the lake for example. I hope this will save you some work, and prevent a premature track update (although track updates are always welcome)
- South City roundabout: It would be smashing if you do the same trick with the barriers under the bridge that you did with Blackwood chicane. This section has already been proved to be drivable, and just needs your magic to remove the barriers in open configs - Pretty please?
- Suggestion - Tape: The missing barriers and some of the aforementioned surface less areas could be masked off with dayglo tape a la rally stages. It would simply indicate "here be dragons - don't go here" without any further major work. The tape could be a simple editor object with no collision attributes, and a simple visual surface texture section of the same length as barriers, that editors can use to mask off areas.
Last edited by Squelch, .
Reason : edited for typo's
Thanks for the update Scawen, and it's good to hear Victor and Eric are still hard at it.
You have my utmost respect for sticking by your conviction, and by not being too disheartened by those ingrates and their constant demands. My frequent visits here have become increasingly tiresome having to wade through all of the diatribe directed towards the Devs just to pick up the odd crumb of interesting news.
Perfection does not come easily, and the previous work just shows how good it really has been through the test of time. Other racing titles are still nowhere near as good on the simulation front, and are still biased towards eye candy over physics. I'm so glad you've not been tempted to be reactionary and throw out some buggy underdeveloped content just to rake some money in like some of the great software houses seem to these days.
I am really looking forward to testing the new physics and other content when it comes, and will patiently wait until then. I strongly believe I'm not alone.
I can only offer words of encouragement for now, and my continued support in the future. I'll now slink off into the silence again.
I wish you all a happy Christmas and a prosperous New Year!
You have my utmost respect for sticking by your conviction, and by not being too disheartened by those ingrates and their constant demands. My frequent visits here have become increasingly tiresome having to wade through all of the diatribe directed towards the Devs just to pick up the odd crumb of interesting news.
Perfection does not come easily, and the previous work just shows how good it really has been through the test of time. Other racing titles are still nowhere near as good on the simulation front, and are still biased towards eye candy over physics. I'm so glad you've not been tempted to be reactionary and throw out some buggy underdeveloped content just to rake some money in like some of the great software houses seem to these days.
I am really looking forward to testing the new physics and other content when it comes, and will patiently wait until then. I strongly believe I'm not alone.
I can only offer words of encouragement for now, and my continued support in the future. I'll now slink off into the silence again.
I wish you all a happy Christmas and a prosperous New Year!
Please insert new user
I know I've been away for a while, but I don't think I'm that rusty. It was definitely halfway down page 2 on this end. I wouldn't have posted otherwise. Temporary glitch perhaps
Ta anyway
[edit]
:dunce:
How stupid do I feel?
I was looking at a search page where I had been looking at the subforum before. Please accept my apologies and delete these posts as they serve no purpose other than clutter.[/edit]
Last edited by Squelch, .
Reason : Previous stupidity
Hi TAA,
Just to point out the title says Sticky, but I found this on page 2, not on the top of page 1 as would be expected.
So here's a bump so it gets noticed
Just to point out the title says Sticky, but I found this on page 2, not on the top of page 1 as would be expected.
So here's a bump so it gets noticed
I have tried this some time ago, and as Juls says, the other views do lag. I've been hoping for some development in this area.
It might be possible to write an app that takes existing connection data, and fake serving to the secondary machines via a pipe or com model to the local clients. Using LAN has a higher update rates it appears, so the lag is not as bad but still present. The local clients only see aggregated position data ie incoming/outgoing and connected in spectator mode only can be used for the other viewpoints. The clients do not send data to the main connection. My programming skills aren't up to the task, and besides, messing with LFS net code might not be legitimate use of the licence.
Having just replied to Juls' topic and another on multiplayer bandwidth throttling, it dawned on me that we might need a new API
-OutScreen-
A UDP connection, in the same vein as outsim/outgauge that would enable other LFS running PC's to connect locally as dumb clients. A higher rate of position updates could be used to solve the problem of position lag. This would also reduce internet connection bandwidth (all the data is present locally anyway), and save server slots.
It might be possible to write an app that takes existing connection data, and fake serving to the secondary machines via a pipe or com model to the local clients. Using LAN has a higher update rates it appears, so the lag is not as bad but still present. The local clients only see aggregated position data ie incoming/outgoing and connected in spectator mode only can be used for the other viewpoints. The clients do not send data to the main connection. My programming skills aren't up to the task, and besides, messing with LFS net code might not be legitimate use of the licence.
Having just replied to Juls' topic and another on multiplayer bandwidth throttling, it dawned on me that we might need a new API
-OutScreen-
A UDP connection, in the same vein as outsim/outgauge that would enable other LFS running PC's to connect locally as dumb clients. A higher rate of position updates could be used to solve the problem of position lag. This would also reduce internet connection bandwidth (all the data is present locally anyway), and save server slots.
This is a really interesting discussion. Having been away from the forums for a long time I'd missed all this, and it relates directly to some of what I've been working on independently. I think I understand exactly the point you are making Juls.
It might help if our understanding of how humans judge speed is explained. It's not as simple as stereoscopic distance measurements made over and over, although this is used when an object is focussed on, but something referred to as optic flow. There have been studies made, and it was found that one eyed people can judge speed just as effectively as two eyed people. The best way of explaining it is: As you are travelling down the road. A roadside object in the distance (say a lamp post) moves across your field of vision from the centre at an increasing rate until it's passed at the edge of the field of view. The brain uses this apparent acceleration to determine the velocity we're travelling at. It is thought that this is our (humans) main speed assessment method.
Increasing the FOV does indeed increase the perceived sense of speed by increasing optic flow on a flat screen, but it does come at the cost of reduced resolution at the centre of view (exactly where it matters most) and the distortion that some people find disturbing. The default 90 FOV causes the driver to over speed because of the spatial compression it imposes while maintaining correct comfortable perspective. I find 110 to be a good compromise.
What Juls originally proposed I believe, is to apply a spherical or elliptical distortion across the field of view to accentuate the optic flow without the resolution loss at the centre. It might become a problem however when the driver looks away to another part of the screen, as the prime spot wouldn't follow their gaze. TrackIR would fix that to a point if you only moved your head to look, but that is another story.
The Microsoft article is experimenting in what is largely a static conference scene and probably doesn't apply here. Though it does highlight the inherent problems with 3D worlds on 2D media.
Using a wrap around projected screen is probably the best compromise. but without multiple independent viewport support in LFS, using more machines to render the other views still might be possible while maintaining synchronisation. I've been working on that for some time. The mirror problem is elegantly cured with this setup by using real mirrors.
It's worth repeating that we do not judge speed by sight alone. There are many other mechanisms that play on our senses which are just as important. If they can be emulated, or the whole body fooled into believing it's moving, the battle is almost won.
It would be be nice if LFS could support multiple viewports to enable any of the discussed options to work, or better still, (to take the load off one machine) have a render only client that could connect to the local client without taking up a server slot. I alluded to this before in discussions about spectator TV broadcasts. The possibilities could be endless.
It might help if our understanding of how humans judge speed is explained. It's not as simple as stereoscopic distance measurements made over and over, although this is used when an object is focussed on, but something referred to as optic flow. There have been studies made, and it was found that one eyed people can judge speed just as effectively as two eyed people. The best way of explaining it is: As you are travelling down the road. A roadside object in the distance (say a lamp post) moves across your field of vision from the centre at an increasing rate until it's passed at the edge of the field of view. The brain uses this apparent acceleration to determine the velocity we're travelling at. It is thought that this is our (humans) main speed assessment method.
Increasing the FOV does indeed increase the perceived sense of speed by increasing optic flow on a flat screen, but it does come at the cost of reduced resolution at the centre of view (exactly where it matters most) and the distortion that some people find disturbing. The default 90 FOV causes the driver to over speed because of the spatial compression it imposes while maintaining correct comfortable perspective. I find 110 to be a good compromise.
What Juls originally proposed I believe, is to apply a spherical or elliptical distortion across the field of view to accentuate the optic flow without the resolution loss at the centre. It might become a problem however when the driver looks away to another part of the screen, as the prime spot wouldn't follow their gaze. TrackIR would fix that to a point if you only moved your head to look, but that is another story.
The Microsoft article is experimenting in what is largely a static conference scene and probably doesn't apply here. Though it does highlight the inherent problems with 3D worlds on 2D media.
Using a wrap around projected screen is probably the best compromise. but without multiple independent viewport support in LFS, using more machines to render the other views still might be possible while maintaining synchronisation. I've been working on that for some time. The mirror problem is elegantly cured with this setup by using real mirrors.
It's worth repeating that we do not judge speed by sight alone. There are many other mechanisms that play on our senses which are just as important. If they can be emulated, or the whole body fooled into believing it's moving, the battle is almost won.
It would be be nice if LFS could support multiple viewports to enable any of the discussed options to work, or better still, (to take the load off one machine) have a render only client that could connect to the local client without taking up a server slot. I alluded to this before in discussions about spectator TV broadcasts. The possibilities could be endless.
I concur on the higher LAN update point. The bandwidth is probably needed to be restricted going via the master.
Something I've observed is that replay files, and presumably net data, are action based not time based. To prove my point. Monitor the file size of the temp.mpr file while a car is standing idle on track for a while. Then watch it grow as distance is covered. It might not be whether the update period should be increased, but the distance travelled (or whatever method is used) could be finer grained. In the days of dial up, every b/s counted. On higher bandwidth connections there is a little more headroom to include more position info.
A throttling of the position granularity based on available bandwidth would be nice. It doesn't necessarily need to be dynamic, but obviously the more cars on track the more is required...... Just my two penneth.
Something I've observed is that replay files, and presumably net data, are action based not time based. To prove my point. Monitor the file size of the temp.mpr file while a car is standing idle on track for a while. Then watch it grow as distance is covered. It might not be whether the update period should be increased, but the distance travelled (or whatever method is used) could be finer grained. In the days of dial up, every b/s counted. On higher bandwidth connections there is a little more headroom to include more position info.
A throttling of the position granularity based on available bandwidth would be nice. It doesn't necessarily need to be dynamic, but obviously the more cars on track the more is required...... Just my two penneth.
Last edited by Squelch, .
Reason : Eeek! lost all the white space
Yes it is the case.
I was thinking along the lines of the car viewer which allows all cars to be viewed regardless of reg status. If the rest of the track can be viewed in a similar way via a replay only setup, it would be nice. As there wouldn't be any connection to the master, nor would there be any requirement for the client to send data, registration shouldn't be needed. If it's possible, the full program could allow replay view.
Much further down the line that one.
It will:-
- Enable team events to be viewed without server load
- Enable multiview cockpits to work without bandwidth issues
- Allow more spectators than available slots
- Events based around LFS can be broadcast/viewed by real spectators
- Enable non regged users to view "Full" races (would require a light client)
From my clumsy investigations the same data that is transmitted over the server <-> client channel is the same data within a replay. I have tried to pipe a current temp replay into another client. The replay showed up but cannot be played because the final finish posiitions are required. I've tried a little hacking to fool it into submission but no go so far.
If the temp replay data can be broadcast, and a replay file can be made to look complete to the client, this might achieve the end goal. The user just needs to start the top file in the list. The data is asynchronous, and only the positional information is sent on top of the username, setup etc. Hacking the complete data stream may be complicated or even not even required.
Last edited by Squelch, .
It's all a question of bandwidth. Yes it's possible to take the output from a race, digitise it, then broadcast this info. This would use so much bandwidth that the gameplay would suffer. LFS has a tight netcode that would be completely swamped by what you propose f1r3b4ll.
All of the information required to render a race is already there and being transmited to the connected clients. If this same information can be tapped and multicast (a one way communication) then we would have a TV like situation for people wishing to only watch a race. Presently the only way is to connect as a full client, which has the downside of taking up server slots, and two way comms. A passive replay like client that is connected to a multicast server could be the ideal. My programming skills don't allow me to explore this further, but imho it is very possible.
All of the information required to render a race is already there and being transmited to the connected clients. If this same information can be tapped and multicast (a one way communication) then we would have a TV like situation for people wishing to only watch a race. Presently the only way is to connect as a full client, which has the downside of taking up server slots, and two way comms. A passive replay like client that is connected to a multicast server could be the ideal. My programming skills don't allow me to explore this further, but imho it is very possible.
Thanks for that.
Those multiple sounds can be a little annoying after a while. Being able to suppress them helps alot.
Those multiple sounds can be a little annoying after a while. Being able to suppress them helps alot.
That's great. Thank you very much sir.
This is great work sdether. I'm learning so much from your code.
May I request a downloadable Doc package for us on dialup? Excellent documentation btw
May I request a downloadable Doc package for us on dialup? Excellent documentation btw
LFS Spectator is what I think you suggesting there doso. The F1 style overlay is being worked on too, now that outguage is available.
Hi guys,
It was me over on RSC that I think you refer to. My idea was to somehow use the replay file encapsulated and broadcast to clients. The current method of spectating does take up a slot on the server. Using a one way lfs data stream would allow connected clients to set camera postions localy.
If it's possible, a seperate spectator client would be ideal, similar to the current viewer. All cars and tracks could be rendered regardless of license. The client would be passive in that synchronisation packets would not be required and the only control be for view. A cut down LFS if you will.
All of this could be run from a broadcast server that is connected to the original game server as a spectator. The "in race" packets retransmitted to spectator clients so as not to impact gameplay. I dubbed it "Live to Spectate", although life, and other projects have called a halt to it.
I talked about using the replay file, but this has it's problems. There is no timing information present, the positions of cars are generated asynchronously. This makes for smaller file sizes but isn't any good for live viewing. The header (footer) isn't generated until the file is closed either.
It would be really useful to have something like this. I want to have a full 360 degree display. Someone else has posted on these forums a method of connecting more than one machine, and setting the camera view to suit. This is a little wasteful of both bandwidth and server slots. As the data is already available for the connected playing client. A way of tapping into, and re using this data locally for different viewpoints would be excellent.
I'm sure there is a way of reverse engineering LFS to do this, but I have no desire to tread on sacred ground.
It was me over on RSC that I think you refer to. My idea was to somehow use the replay file encapsulated and broadcast to clients. The current method of spectating does take up a slot on the server. Using a one way lfs data stream would allow connected clients to set camera postions localy.
If it's possible, a seperate spectator client would be ideal, similar to the current viewer. All cars and tracks could be rendered regardless of license. The client would be passive in that synchronisation packets would not be required and the only control be for view. A cut down LFS if you will.
All of this could be run from a broadcast server that is connected to the original game server as a spectator. The "in race" packets retransmitted to spectator clients so as not to impact gameplay. I dubbed it "Live to Spectate", although life, and other projects have called a halt to it.
I talked about using the replay file, but this has it's problems. There is no timing information present, the positions of cars are generated asynchronously. This makes for smaller file sizes but isn't any good for live viewing. The header (footer) isn't generated until the file is closed either.
It would be really useful to have something like this. I want to have a full 360 degree display. Someone else has posted on these forums a method of connecting more than one machine, and setting the camera view to suit. This is a little wasteful of both bandwidth and server slots. As the data is already available for the connected playing client. A way of tapping into, and re using this data locally for different viewpoints would be excellent.
I'm sure there is a way of reverse engineering LFS to do this, but I have no desire to tread on sacred ground.
Oop's wrong thread :duh:
Last edited by Squelch, .
FGED GREDG RDFGDR GSFDG