Both are very nice!

Although I see they require XRdials_ALP.dds to be modified too. My first XFG dash used empty dds file to maximize dash area just like those, but pretty soon I realised of all the flaws that come with it. Well I didn't supply dds files with it to be honest, but there will always be someone who will simply forget to do that and dash will not look like it is supposed to.
Also including such a dashes into autoinstaller will require some changes and complexity. I don't think I should just like that overwrite dds textures, users consent is definitely needed in that case IMO.

Had no choices but using a custom XRdials_ALP.

As you know, it's not that easy to use default masks and get a good result, this means I'll certainly have to use custom dds for the most of the sets.If not, I'll bang my head on walls.

Personnally, I like the XRdials_ALP and I don't want to remove it (and I also want that all cars have one).

Quote from nacim :

I like the XRdials_ALP [...](and I also want that all cars have one).

Me too...
Unfortunately it is not possible for me to do otherwise when making some different gauges layout (..yet).

Z31 for XRG & XRT updated: new turbo gauge (XRT) and small improvements.

Is it possible to have a Miles Per Gallon gadget, for those of us who don't use the l/100km figure normally?

Instantaneous is OK, but I'd also like the average over the length of a trip
Ty

Oh, and how does LFSLazy start with LFS? I'd like to start a strobe program as well when I fire up LFS.

I just cam e hjome, maybe its beter to replay tomorowo. happppppy new yera

Heppi ju tuu drunk daniel

MRT GT-Cluster

Download(MediaFire)

Quote from McGherkin :

Is it possible to have a Miles Per Gallon gadget, for those of us who don't use the l/100km figure normally?

I thought to do that, but mpg seem rather complicated because there are several Gallon definitions. I can detect if mph is selected in LFS and automatically change to L/100Km to mpg, however question is which one?
Probably I could add another option to select which gallon you want to use, but I guess most people will leave it on default so they will see "wrong" fuel consumption.

Quote from McGherkin :

Oh, and how does LFSLazy start with LFS? I'd like to start a strobe program as well when I fire up LFS.

Go to data\scripts\autoexec.lfs, open it with notepad. That is script that executes each time LFS starts. You will see the line that starts LFSLazy as example.

Quote from cuprum :

Heppi ju tuu drunk daniel

Heppi ju tuu sober edgar

Quote from 1303s_vortech :

MRT GT-Cluster

Download(MediaFire)

Very nice!
However some of that stuff used (what can I see from pic) is still unavailable in public version, so it will not work as it should.

I would take the value as 4.54609L as that's what most cars use.

Oh, that's how you do it I thought it was through scripts but couldn't see anything on the wiki. Cheers!

Oh and happy new year

Quote from DANIEL-CRO :

that stuff used (what can I see from pic) is still unavailable in public version, so it will not work as it should.

Doh !
It need to be updated anyway (yes, already ) as I've added some features on it.
The others sets will be also updated, (UF1 will be replaced btw...).

About imperial units, I can also make speedo in miles/h ( & boost in psi as well).

You could just do 454.609/1.609344*N=MPG

Where N is L/100km, if I've got that right.

Quote from McGherkin :

You could just do 454.609/1.609344*N=MPG

Where N is L/100km, if I've got that right.

Math isn't the problem
Problem is gallon and its bad definition. I see that LFS displays in garage Litres whatever settings you choose, so I guess Scawen kinda agree on that

As above really, the value most cars use is the one I've given

Cars in the UK, maybe. US gallons are 3.78L, not 4.54L (and that's why US MPG figures look worse than they really are)

Unless US cars really measure in UK gallons... which would strike me as rather odd.

Daniel, there is a small request: please make tabs switch in lfsw window like in the top-level small window. Thanks

Daniel, can you make favorite servers on main screen expandable onclick (rules and players connected)?

Quote from DANIEL-CRO :

Quote from z0rnd1k3 :

There's no followed message...

New version will have an option to turn off verification. Nacim has confirmed that this solves problem in his case, however I do not recommend using it, tho 95% of other programs don't have such verification (FPS, recording programs, ...)

dashboard is ok now (with "no adr verification" option). Thnx !

Is there any chance to make it working on openconfigs? Realtime gap is not required, just the gap on splits. Also would be nice to have positions list working there. I guess it is loads of work and I ask too much eh...

Quote from Draggo :

Daniel, can you make favorite servers on main screen expandable onclick (rules and players connected)?

That sounds like doable. Will put that on TO-DO, tho haven't done any work on LFSLazy recently so not sure when will it be. There are some other things on my mind these days like the existance of mankind.

Quote from vitaly_m :

Is there any chance to make it working on openconfigs? Realtime gap is not required, just the gap on splits. Also would be nice to have positions list working there. I guess it is loads of work and I ask too much eh...

Main problem is correctly detecting open config tracks. That would most likely require reading loaded layout and comparing checkpoints position and heading. Of course in that case there should be hardcoded data about checkpoints of all open config tracks. And still even if I do that only thing I really gain is realtime gap and gap on splits.
Position list work based on nodes for MCI, as there is no nodes on open configs not sure that there is much I can do.
First thing is most likely to be done, but as there are so much open config tracks and it would require modifying quite some code I'm not sure I will do that anytime soon.

Quote from DANIEL-CRO :

Main problem is correctly detecting open config tracks. That would most likely require reading loaded layout and comparing checkpoints position and heading. Of course in that case there should be hardcoded data about checkpoints of all open config tracks. And still even if I do that only thing I really gain is realtime gap and gap on splits.
Position list work based on nodes for MCI, as there is no nodes on open configs not sure that there is much I can do.
First thing is most likely to be done, but as there are so much open config tracks and it would require modifying quite some code I'm not sure I will do that anytime soon.

But what if you just rely on IS_SPX and IS_LAP packets? You can refresh info only when u cross split or finish line. This goes both for gaps in the position list and for the PB comparison. The same way Airio does and it is good enough for me

IS_SPX and IS_LAP is exactly the way current comparison work. However I do not have info about exact track in use. For example AS1X doesn't really mean much, because split times does not depend on track but position of checkpoints. I would need track name like A11, A12, ..., however that isn't available localy. Of course Airio has this information because it is the one loading layout.

Quote from DANIEL-CRO :

IS_SPX and IS_LAP is exactly the way current comparison work. However I do not have info about exact track in use. For example AS1X doesn't really mean much, because split times does not depend on track but position of checkpoints. I would need track name like A11, A12, ..., however that isn't available localy. Of course Airio has this information because it is the one loading layout.

Then could we ask Scawen to implement some package like layout name? By then we could test this with entering layout name manually in LFSLazy when enter some open config track.

Seems like there is one:


But this doesn't actually fix the whole problem, because by a fault some might name layout differently, or add some chikane or whatever making track different.

In the end, the best way to distinguish the layouts is to have the tracks named like this in LFSLazy database:
"AS1X split(x, y, z), split(x, y, z), finish (x, y, z)" where x, y, z are actual values. You don't have to create the database of the A11, A21 and other semi-official LFS Open Config stuff...

Hope I'm not too much annyoing

Quote from vitaly_m :

Then could we ask Scawen to implement some package like layout name?

That would be the simpliest solution, but surely not so reliable in some aspects.

Quote from vitaly_m :

By then we could test this with entering layout name manually in LFSLazy when enter some open config track.

Honestly how much people would really do this? I have feeling that people would often forget to change layout name, etc. Very lame

Quote from vitaly_m :

Seems like there is one:

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

if loaded locally ...

Quote from vitaly_m :

But this doesn't actually fix the whole problem, because by a fault some might name layout differently, or add some chikane or whatever making track different.

As previously stated name is only available if layout is loaded localy, in case of server that is remotely.

Quote from vitaly_m :

In the end, the best way to distinguish the layouts is to have the tracks named like this in LFSLazy database:
"AS1X split(x, y, z), split(x, y, z), finish (x, y, z)" where x, y, z are actual values. You don't have to create the database of the A11, A21 and other semi-official LFS Open Config stuff...

Realtime comparison has separate file for each combo, that means that I would have to encode all this info into filename. Because I don't seek through all files, but search for exact one based on its name.

More of a problem would be with split comparison, because in there data for all combos is stored in single file. Each entry is xx bytes, it contains car, track, restrictions, splits, sectors, speeds and there is simply not enough spare space to store necessary data without making it incompatible.