-Allow default setups for up to 8, helpful showcasing all available configurations since now we can have 8.

I don't know if anyone has already suggested this, but there could be an option for a crossplane crankshaft on the 4-cylinder in-line engine and some options for the 2-cylinder, such as 180°, 270°, 360°

Would it also be possible to get the "add page" feature on the rim and wheel section? I know it's been used in the past to get good looking Chrome using a transparent texture. I know the rim part might be more complicated, but it would need to support chrome. Otherwise, we would make the chrome barrel on the wheel side and do no rim. If that was done, and enough points / tris allowed (I find I'm hitting the 1600 max quite easily while using the editor for some more complex wheels), there would be a lot more uptake using the wheel and rim editor. Of course, that would be a very "nice to have," not necessary like the tire stretch feature.

Quote from OpenClutch :

Would it also be possible to get the "add page" feature on the rim and wheel section? I know it's been used in the past to get good looking Chrome using a transparent texture. I know the rim part might be more complicated, but it would need to support chrome.

I've had a quick look at how this works. I think it needs some improvement.

If I understand correctly, currently the wheel rim creates a mapping, which is a copy of the first mapping in the spoke object, but it ignores the material properties assigned to that mapping, instead uses its own material properties based on "shiny paint".

Maybe the problem can be solved fairly simply if the material properties for that rim mapping, come from the material properties specified for that mapping's cutout in the spoke object. Would that work?

It seems to me this is what the rim creation code does:
- takes the first texture in the spoke object (which is the only texture)
- creates a "shiny paint" material based on that texture
- uses the first mapping in spoke object's list of mappings (for position and scale)

I suppose it should be simpler and more logical.
I think it is still easiest to use a mapping from the spoke object.

For example:
- take the first mapping from the spoke object
- use that mapping's cutout material properties

Questions:

1) Would that work and does it add the needed flexibility?
2) Are there issues with existing rims going wrong if the code is changed as above?
3) Is there a need for more texture pages in the spoke editor?
4) Rim using mapping from spoke object seems a bit obscure - should it be made clearer in the editors?

As far as I can see, currently as there is only one texture, the first mapping can only be using that texture anyway, so the only change with existing models is that their rims would suddenly take their material properties from the cutout pointed to by the first mapping in the spoke object.

Quote from akubosaan :

I'm trying to make new config with different headlights shapes by utilizing one l_full & l_head for each configs.
And figured out that it's not possible to use flash/passing light with only one l_# map on one config, so something came through:

Would it possible & make sense to have an option to combine functionality of l_head and l_full (like when two l_#s were "l_head")?

I am a bit confused at the moment, but I remember someone else talking about this too. But maybe I'm not fully confused... is the problem that if there are (for example) two l_head mappings, but one is used on one configuration, and another is used on another configuration, then this doesn't work as hoped or expected?

Someone seemed to say that if there are two l_head mappings then none of them works at all, but I haven't looked into that.

I don't know if it's possible (or easy enough) to do, but would all the problems be solved if somehow LFS could identify and use the l_head that is used in the current configuration, while ignoring another l_head that is not used in the current configuration?

Quote from Scawen :

I think it needs some improvement.

This would really help me as well

1) Would that work and does it add the needed flexibility?

I think it would work except currently you cannot add an alpha texture to the spoke.**

2) Are there issues with existing rims going wrong if the code is changed as above?

Maybe but as you can't currently use alpha it will just affect shininess.

3) Is there a need for more texture pages in the spoke editor?

I think that would be very useful but not sure if worth loads of time now.

EDIT: YES. For what I want I need at least two - alpha for the rim and another (paint) for the centre.

4) Rim using mapping from spoke object seems a bit obscure - should it be made clearer in the editors?

Adding a box in the rim editor saying "Mapping Name (from Spoke Editor)" would make it clearer.


(** - Actually you can get an alpha into spoke editor and multiple pages if you model it seperately in the modeller and use "Import SRE")

Would it be possible to add a digital time clock to the s clock formula?

Also adjustable "red line" to the digital dashes where the hash marks turn red (or whatever color on a slider preferably) at a certain rpm to redline. I've tried to hack it by putting red glass over the area but it doesn't look good to me.

Thank you for all the hard work.

Quote from Scawen :

is the problem that if there are (for example) two l_head mappings, but one is used on one configuration, and another is used on another configuration, then this doesn't work as hoped or expected?

Yeah, abit like that. Tho I better try to explain more clearly. Basically...

I want to use l_full and l_head, each for 2 different headlight shapes for my Chorus Attendanze mod.

Config #1, #2, and #3 (the one with normal 90's lights as how they look now) use l_full.
So l_full and l_side are visible on these configs, but *not* l_head.

(Yeah I think I need to fix l_side after reading things.)

And config #4 (the one with rounded retro lights) is going to use l_head *only*.


The problem I have (as shown in previous attachment):

-On config #1, #2, and #3, I can use flashing hi-beam. Sidelights do work, but low-beam doesn't (as l_head is hidden).

-On config #4 (with temporary headlights because w.i.p), low beam and high beam kind of work, but I can't use flashing hi-beam (as l_full is hidden).
There's supposedly no sidelights on config #4 and headlights don't lit on "sidelight" state (they do work after l_side is completely removed from the model and set "sidelights use [l_head]", but "sidelight" won't work on the other configs).


It's l_full + l_head on main object in my case. But using 2 light mappings of the same name on different configs sounds like something more convenient, if possible.

Quote from Scawen :

would all the problems be solved if somehow LFS could identify and use the l_head that is used in the current configuration, while ignoring another l_head that is not used in the current configuration?

Tho, I probably should look for mapping workaround in case otherwise especially.




Thanks.

In my version, I have now made it that you can have more than one l_head (or whatever special named colour) in your model.

So you can now use a different l_head in one configuration if you have different headlights there.

I think this avoids problems. The only confusion now is in the editor you have two colours with the same name. I think I should make it accept the names, followed by a space then some other text.

So then you could have (for example):
l_head
l_head 2
l_head sport
l_head retro

And these would all act as l_head. You must make sure you only use one in each configuration, or there will be a warning message. Let me know if this could cause any problem.

Quote from Scawen :

In my version, I have now made it that you can have more than one l_head (or whatever special named colour) in your model.

So you can now use a different l_head in one configuration if you have different headlights there.

I think this avoids problems. The only confusion now is in the editor you have two colours with the same name. I think I should make it accept the names, followed by a space then some other text.

So then you could have (for example):
l_head
l_head 2
l_head sport
l_head retro

And these would all act as l_head. You must make sure you only use one in each configuration, or there will be a warning message. Let me know if this could cause any problem.

Sounds good, they share the same color slider in lights color tab right? I feel it's the most convenient way without the need to have a color option for every mapping.
Modders can make differences using textures as long as the mappings function properly.

This way allows us to have whole set of lights mappings on each subobject individually

Quote from Evolution_R :

I've noticed that when wheel visibility is set to inside covered, the spoke object is also not visible when looked from inside.

In my version the visibility in game is now as in the editor, so:
- "inside covered" or "open wheel" only affect logo and lighting
- visibility of brake disc and spoke object is no longer affected

Quote from OpenClutch :

Would it also be possible to get the "add page" feature on the rim and wheel section?

Quote from teeembo :

This would really help me as well

1) Would that work and does it add the needed flexibility?
I think it would work except currently you cannot add an alpha texture to the spoke.**

2) Are there issues with existing rims going wrong if the code is changed as above?
Maybe but as you can't currently use alpha it will just affect shininess.

3) Is there a need for more texture pages in the spoke editor?
YES. For what I want I need at least two - alpha for the rim and another (paint) for the centre.

I've now enabled loading alpha texture into the spoke editor, and multiple textures.

The material properties for the rim object now come from the first mapping in the spoke object.

So now in my version you can create chrome rims.

Quote from bayanofmansorofisky :

Sounds good, they share the same color slider in lights color tab right? I feel it's the most convenient way without the need to have a color option for every mapping.
Modders can make differences using textures as long as the mappings function properly.

This way allows us to have whole set of lights mappings on each subobject individually

Yes, all the different l_head lights take their colour from the same colour slider in the Light tab.

You can have a whole set of headlight mappings for one configuration, and another set of different similarly named mappings on another configuration, even if they are all on the main object.

And for anyone else reading, if you didn't notice, you can call these different mappings a different name, if there is a space after the special name.

E.g.
l_head standard
l_head retro
l_fog race
l_fog road

These will work as expected, as long as (e.g.) only one l_head xxx is used in one configuration.

I expect to release an update tomorrow.

Quote from Scawen :

And for anyone else reading, if you didn't notice, you can call these different mappings a different name, if there is a space after the special name.

E.g.
l_head standard
l_head retro
l_fog race
l_fog road

These will work as expected, as long as (e.g.) only one l_head xxx is used in one configuration.

This will be super useful I'm mapping a blue light beacon on one of my mods and I use the l_extra light mapping for it. Now I can only map the sides but there is no second mapping available to map the top part properly.

Hmm, that wouldn't actually work as currently coded.

I think you've misunderstood me, but actually the thought in your head is how it should be.

I wonder if it could be that we eliminate the extra names for same lights, as they are confusing and don't seem needed any more.

E.g.
l_brk, l_sbrk, l_tbrk, l_cbrk -> l_brk [x]
l_tail, l_stail, l_ttail -> l_tail [x]

Maybe it should be a little more clever, and alow multiple colours of the same name (ignoring the [x] part which is for the mod creator).

I like your suggestion - it would be more convenient if there was just one mapping name for each light type and we could have multiple colours of the same name.

Quote from Scawen :

I expect to release an update tomorrow.

Sorry but this won't happen. Slight change to implement as mentioned above, which is a bit more complicated than you might imagine, because of backward compatibility (auto-repair code) and I don't have that much coding time this weekend. Free to work all day Monday so I expect to release D52 test patches Monday afternoon.

The material settings for wheels (allowing e.g. a chrome rim) and the more flexible light mappings are now available in Editor D52.

https://www.lfs.net/forum/post/2068083#post2068083

Quote from Slashpca :

Would it be possible to add a digital time clock to the s clock formula?

Also adjustable "red line" to the digital dashes where the hash marks turn red (or whatever color on a slider preferably) at a certain rpm to redline. I've tried to hack it by putting red glass over the area but it doesn't look good to me.

Thank you for all the hard work.

Also would it be possible to make it an option in the editor to disable passengers on specific configs? Like cars with sayh a racing config with the passenger seat removed, or on a bike config with the rear footpegs and seat removed?

It would also be cool to be able to enable that wheel and tire size customization option in the game pits like you guys did on the vanilla GTR cars.

Hope this isn't the wrong place for this

Would it be possible to to have ballast weights in truck/bus vehicles to exceed 200KG? Something near 40-50% of the vehicles frame mass? (10000 KG truck can have up to 4000-5000kg ballast for example) And would it be possible to have the ability to place it in a specific part of the frame under "object position" tab in editor? Considering weights can be added live to a vehicle in recent updates i think it would be nice to have this feature for RP servers with cargo jobs.

*- is it possible to make the new pop up lights activate on a key switch or a command like the /light head command , instead of it being auto activated when lights are on?
maybe a command like /head popup on off toggle.

it would allow us to use this subobject in many.. many other ways


*- New subobject (rotating sub) that rotates at a given RPM and can set pitch roll heading etc..
activated by a command, ex: /sub rotate

Quote from bayanofmansorofisky :

*- is it possible to make the new pop up lights activate on a key switch or a command like the /light head command , instead of it being auto activated when lights are on?
maybe a command like /head popup on off toggle.

I think it's good to have it pop up automatically, otherwise it would be a hassle to run two commands to turn on lights + pop them up.

There could be another subobject type which would have the same rotating features as the pop up light, but it would be triggered using a special command instead of being activated by headlights. This would be handy for simulating opening doors, bonnet, boot, tipping body of a truck, wipers etc.

Here are a few examples of what's possible now but doesn't make sense to be tied to headlights:


(by Egor K)


(by justawastedsoul)


(by dz0fps)

Quote from Flame CZE :

There could be another subobject type which would have the same rotating features as the pop up light, but it would be triggered using a special command instead of being activated by headlights. This would be handy for simulating opening doors, bonnet, boot, tipping body of a truck, wipers etc.

Here are a few examples of what's possible now but doesn't make sense to be tied to headlights:



(by justawastedsoul)

Yes i agree then, having seperate new subobjects is better.. yes i wanted to add it to the LineRunner but being mapped to lights is a no no.

(This was suggested before but I wanted to include a bit more detail about the topic)

Could a new turbo lag slider option for engine editor be added to make high-boost turbo cars behave more realistic?

I think this option is missing in the current editor. The turbo inertia multiplier does help the turbo spool up slowly at first but makes it stay spooled after letting of throttle making the lag almost non existent after first spool up.

Here I did a test with the original XR GTR and the one in the editor. The original XRR spools up the turbo really slowly and after letting off the throttle and getting back on it the turbo still spools slow.
The editor XRR spools up the turbo really fast all the time without any of the engine settings being changed making it unrealistic.

Original XR GTR


Editor XR GTR



Here is a engine I made with 2.0 Bar pressure and 2.0 turbo inertia using hex editor since the max value is 0.6. It does spool up slowly at first but the lag decreases afterwards.

I'd like to preface this by saying I have no idea about coding, especially how this game is coded lol.

Would it be possible to set certain subobs like bumpers and wings as "removable" in cases where they sustain a certain amount of "damage hit points" or deformation. They would eject from the vehicle in that case.

Ejectable downforce subobs could be tied as the aero points as well so when they eject from the vehicle you lose that aero effect.

This might be too far off the scope of possibilities right now but I just wanted to mention it.

So far, the way to have open roof with proper interior sound (like with windows open) is to name the config "OPEN ROOF" (capital doesn't seem matter). Would be nice in the editor to have something like a toggle next to config name to switch between "Open" & "Closed" sounds.

Or is there any other way to have proper open roof sound?

I would like to suggest having multiple rotator/slider/spinner values on one object depending on the use. (for ex. indicators for left and right, headlights - fog, low, high etc.)

This would add more variety for interior switches but could be used for other things as well.
Also an option to connect multiple rotating objects



Example:



On a side note more options for object type that use in-game axis (for ex. steering wheel) could also be done for gas pedal, brake pedal, handbrake but this could take quite a while to implement since driver animations would need to be adjusted accordingly.