The plan is to turn the editor they've got into something that is releasable to the public, *after* they're happy with LFS. They're currently doing lighting/tracks and tyre physics - the lighting is coming first, the physics will come with it if it's ready in time.

It's not set in stone though, just a general idea of what they would like to be able to do and when.

I am! I'll recompile the first version soon (I think that's the one you've got) so it runs better, then I've got an idea to solve the problem of the second

Last edited by Racon, Wed 10 Nov 2021, 16:45. Reason : holy disappearing-question-post-making-you-look-like-you're-talking-to-yourself batman!

I've recompiled this now with my new compiler - v2.0 is no longer a resource-hog.

You like figure 8? Great fun, but with a little practice it's easy enough to avoid collisions as they all come from one place that you have enough time to watch... this track solves that 'problem' by increasing the number of crossings and making them much, much harder to track

Figure-8 tracks have 2 crossings per lap (diagram 1), the Celtic Crossover has 8 when driving conservatively (diagram 2), or 16 if you're brave enough to drive the faster wide line (diagram 3), all from both directions.



The start grid faces a huge track map to give a hint to newcomers, each corner has a large number sign, and there's a speedbump diamond in the centre to aid navigation, but, it's still pretty easy to get lost... especially if you've been spun






Alas, you do need quite a few drivers to get the full chaos effect (a smaller version suitable for fewer drivers is planned - no timescale as of yet).

Layout free to use, modify, steal bits from, etc, as always.

Layout is available to drive on PiranMOTODestructionDerby (!vote to select if not currently loaded), track stats available at https://piranmoto.co.uk/tracks/274

Last edited by Racon, Sat 27 Jun 2020, 15:44.

My latest Grass adventure - Multiple configurations of a test-style grass track, with a common start/finish and pitlane.

Layouts and track maps attached - free to use/modify/share/steal-bits-of/etc.

All configurations are available on PiranMOTOGrass (changeable by vote); Track stats available on PiranMOTO.co.uk.

Every track starts with a blind crest immediately after the finish line, and all (bar one) end with an uphill, adverse-cambered, tightening turn into the straight. Lumps, bumps and gradients are an integral part of each course, with plenty of high furniture and sighting posts around for orientation.

Start-line crest:


Final turn: uphill, adverse camber:


In action:


Furniture:


Open config:


**EDIT** Added Sprint 4 and 5

Last edited by Racon, Tue 23 Jun 2020, 23:23.

It's always going to be a balance - but we shouldn't be addressing these things with hardcoding because people's setups and circumstances vary wildy, let alone requirements for different types of racing.

If there are to be bans on specific setup things in races, they should be enforced by server rules and/or insim so that you can set your server to your own preference, like the FCV option. When we hard-code this kind of thing, we get side-effects.

For example, I'd like to run MRT and FBM on hillclimbs/autocross. Those are perfectly valid cars for a hillclimb (I've seen similar on telly), and a hillclimb is a perfectly valid use of a handbrake in a single seater (they had handbrakes, and they used them for hairpins). But I can't do that if there's a hairpin, because other servers don't want handbrake abuse in their races. We could have had both if single-seat handbrake-ban was an option like FCV, or if we checked ourselves in insim with a handbrake flag added to the MCI packet or something along those lines.

TL,DR: Your right to swing a handbrake-ban should end at my server. Hardcoding means it doesn't, so let's not do that if we can avoid it

PS: I know you said that point was controversial, but the auto-clutch discussion ends before it even starts when real-life paddle-shifters are auto-clutch, doesn't it?

Quote from Bose321 :

Interesting, thanks! So I can use this to export the values, and hardcode the difference right? Would the setup really matter? I don't think the position forwards or backwards does change right?

Yeah, the MCI position is the reference, the contact patch values are offset from that. Camber would move the patch left and right, but I'm not sure if castor would move it backwards and forwards. If the point that castor adjustments rotate around is the centre of the wheel we're good, but I don't know if that's the case or not. It might even be the case in some cars but not others.

We should be able to tell from a few test setups and repeated exporting of carinfo files, otherwise it's a question for Scawen, I think

Quote from Bose321 :

Yes correct! I'm working on a little drag InSim right now. I plan to make it as realistic as possible with pre/full staging. I'll have a look at that carinfo when I find some time.

Are you also working on an InSim, or just brainstorming?

Currently just brainstorming, but the urge to stop thinking and start building is growing

This is one of two problems that has been keeping me on other things so far. I've got a polygon area system in my insim framework with functions for enter/leave, I thought using overlapping areas for pre-stage and staged would be easier to code around than lots of insim checkpoints, and make it easy to include deep-staging too.

The other problem is a lag between sending the light control packet and the lights actually changing. It's about 0.7 secs (IIRC) on my setup, but I don't know enough about why it happens to be sure that it's a consistent lag for everyone or if it's dependent on the client's processing power (I suspect LFS is swapping the model, or recalculating something to do with lighting).

I'm currently planning to use insim buttons for the lights instead, but it'd be nicer to be able to use an object on track.

There's "centre of contact patch" in the carinfo file, along with a heap of other interesting things. They're given relative to the reference point returned in CompCar.

It would seem to be setup dependant though - you'll need to set a consistent camber/castor at least.

(Are we planning a drag-staging system? This 'we' is planning on tinkering with a staging system too, but not ready to start yet )

LFS USERNAME: racon

LFS RACE NAME: Jam

LFS RACE NUMBER: 616

When loading a layout from the autocross editor, the AXI packet doesn't report the layout name as it would when loading with the /axload command. 'BL4X_ringwood', for example, is reported as such with axload, but as 'BL4X' when loaded in the editor.

I assume it's done this way for tech reasons (insim.txt says "if loaded locally" - axloaded layouts are local to DCON, editor-loaded are local to the client doing the loading), but this means that editor-loaded tracks are not being picked up properly and stats are being missed/overwritten/etc.

Anyone got a workaround that works now? I'm thinking I could make a hash from the objects and check it against a database whenever the layout name doesn't contain an underscore, but it'd be easier for me to just drive to my mate's house and beat him with a stick in person every time he does an editor-load.

Or does anyone know the tech reasons so that we might think about ways around it for an improvement suggestion?

Quote :

struct IS_AXI // AutoX Info
{
byte Size; // 40
byte Type; // ISP_AXI
byte ReqI; // 0 unless this is a reply to an TINY_AXI request
byte Zero;

byte AXStart; // autocross start position
byte NumCP; // number of checkpoints
word NumO; // number of objects

char LName[32]; // the name of the layout last loaded (if loaded locally)
};

You've got "Thread.Sleep(1000);" on line 54, which is the one second pause between yellow and green - I don't know about the lang/framework you're using (edit: or best practices for it as Bose says), but that 1000 just needs to be a random integer between 1000 and say 5000 for a random 1 - 5 second delay.

Quote from Kashopi :

...authorized legal representative

Does this necessarily mean a qualified lawyer? Could it be something easier liked a named volunteer acting as part of 'party in question'? You'd probably need a lawyer to know for sure, but worth a thought maybe.

Quote from Sponge :

But I think LFS would definitely benefit from having a few of the big sim racing YouTubers playing and promoting it.

I've always wanted to see praise from someone with a reputation of being able to jump into any car and go fast, like one of the top gear ex-Stigs. Something along the lines of "I've tried them all, LFS feels closest". Too busy throwing darts at pictures of Clarkson I guess, but you can't blame them for that

I realise the messages themselves don't do it, but if that message accompanies the unwanted restart... find one, find the other, no? I think I'd probably have to give up coding altogether if I didn't have wingrep to get me where I want to be

Do a text search of the entire lapper directory/subdirectories for a short part of the message you're getting, like "friendly"... that should get you to the right place in the code.

It's in the flag packet already, there's a 'CarBehind' byte which id for the other car. (I don't know if Lapper does anything with it)

Even then though, there's a times when I've gotten the blue flag over and over again for a car that is behind me physically, ahead in the race, but can't catch up. Same car each time, but I'm not doing anything wrong by not parking up and waiting for it to pass

I gave up on penalties because I couldn't discount those situations without more checks than I was willing to invest time into.

It's --- UF 1000 Race, but I haven't seen it running yet.

edit: not sure if the lfs://join= link thing works with those funky circles in the server name... but I can't see it doing a server list to join manually either.

edit: Found it, updated link

Last edited by Racon, Sun 3 May 2020, 10:58.

Quote from milek7 :

Yes, I meant 40ms interval of MCI packets set in IS_ISI. I have /pps=6, so this is also confusing why these straight line segments are longer than ~4 dots.

Yeah, I make it 4 too, give-or-take the odd threshold/race condition. There's got to be some skipping going on somewhere, but I just can't think of anything other than lag that would cause it.

Can I just double-check? The DCON is on your local machine, the insim is on your local machine and connected to the DCON locally, and you drove the car yourself with a local client?

Quote from milek7 :

I guess if DCon doesn't calculate physics it isn't possible to fix it, except faking it by filtering out excess points and drawing beziers passing through real positions. Slightly annoying that CompCar doesn't have some field like 'time since last real update'.

That would be nice, and there's a spare byte in CompCar. It could be an interval count with a low cap to squish just enough information into a few bits. (0 is no lag, a 16-dot tangent from the above settings would be 4, something like that)

You're right, DCON doesn't do physics, it just coordinates sharing the end results between all the clients.

How're you getting 40ms updates? That's 25/sec, MCI is 4/sec default and 6/sec max, IIRC. One of your tangents is around 16 dots long from where it deviates to where it corrects, that's 2/3 second at 40ms, you should have at least 2 MCI packets in that time even at default rate. I'm totally lost now, sorry :/

I made a tracer a while back and haven't run across this problem myself, but it doesn't run at anywhere near as high a resolution as yours, so it might be present but hidden within tolerance (2nd image on https://piranmoto.co.uk/tracks/203). There's a couple of places where it looks like it could have happened, but they were in fact crashes

--

Edit: Ahhhh, maybe your insim is set to 40ms in the ISI, but your DCON is set to something else? (/pps = x in the .cfg)

That would mean the DCON, lacking physics, would have nothing to go on but previous heading and velocity for 6ish of your insim reads, before the next time it had up-to-date info (4 writes per 25 reads). The tangents are longer than 6 dots though, so I'm still not dismissing some hidden lag somewhere

Last edited by Racon, Fri 1 May 2020, 11:28.

That looks like a laggy car - LFS will keep it going with the same control input if it doesn't get an update, then correct when it does. Usually you don't notice the very small corrections, but a lot of lag around a corner would look about like that.

Weird that it seemed OK to you in game, that would seem to rule lag out. Is the insim on the same computer as you? If so, maybe the insim got laggy data while you didn't?

Edit: I've just thought - there's a flag for lagging in the CompCar in the MCI you could use to check. You could plot the point in green if the flag's not set and red if it is. If it is lag, your tangents should go red and the bits where it is behaving as you expect should be mostly green.

Last edited by Racon, Fri 1 May 2020, 09:01.

LFSW name: racon
In-game name: Jam 616
Full team name: PiranMOTO
Nation: United Kingdom

Cheers racer... I've been missing supercars something wicked since it left UK TV, and I hadn't noticed they're doing this.

Quote from Arctic_Knight09 :

There is an excellent set out on the web for the RAC (named 'mahtava setti') try it if you think the RAC isn't a good handling car; it will change your perception of it .

https://www.lfs.net/files/setups/942/RAC-mahtava-setti Sounds worth a try

I don't know that framework, but it looks like you're sending everyone to pitlane whenever anyone hits node 56 - you find the right player but then loop through all the connections.

Yep, that's got it, thanks