Quote from ELDemon :

Hi, Scawen there seems to be an unintentional bug with the editor, it also seems fairly related to the other XRR restriction bug I mentioned in another thread.

So for my dragster, I have been tinkering with many settings to get this rocketship to go even faster but I noticed a problem when changing the drag settings of the aero when for example I removed all the drag from the body and wings (leaving 0.001 lowest drag value possible), I noticed that the lower values for the suspension had been drastically increased, stiffness, antiroll etc all well above whats actually needed, it's very strange and I'm sure it's not intentional.

also, the car breaks entirely when you completely remove the drag.

I am relying on specific values in the editor to make my dragster even work, but it's limiting me in ways like that.


It still puzzles me whether I am doing something wrong somewhere else, now the car reaches 470mph ish before the end of the small 8mile dragway and is sent into retirement (edited)
It's so frustrating

I see what you mean about lowering the drag. An internal calculation goes wrong because it calculates that with the given engine power and unbelievably low drag, the maximum speed is some insane number.

This is one of these issues with releasing a development editor. It doesn't matter when I'm the only one moving the sliders, as I simply wouldn't try to set near zero drag!

I think in your case you could try sticking to reasonable drag values, something like 0.3 would be OK, I guess? I don't know what the drag of a dragster is really but I'd guess it's not too different from an ordinary racing car. I don't know what sort of downforce amounts they use but the wings look quite big, seemingly a lot more substantial than a Formula 1 car.

About the top speed, there is a built in limit of 200 m/s. It's around 720 km/h or 450 mph. But according to Wikipedia, the fastest dragsters reach around 335 mph so that limit shouldn't affect you too much. To me it seems like tyre physics are the biggest problem the dragster faces at the moment.


I was thinking today how far we can go. I realise your dragster and some other vehicles have trouble with tyre physics limitations. But it doesn't seem sensible for me to delay the public release, in order to work on the old tyre physics. I've got a new tyre physics system in development and it seems as if that's where my work should be focussed.

For the mods support, there are quite a few bugs and issues to sort out and it seems sensible to me to make this a public release at that point, instead of going on trying to support every one of 100 features that 'so nearly could be supported' for the first release.

new bug when change cutout

Quote from Flame CZE :

There seems to be a bug in the spoke editor: I was trying to import an OBJ file as the spoke model, so I put a file spoke.obj into data/obj, go to Edit Spoke, press the OBJ button, select spoke.obj, but it shows an error saying "could not open file data/3dob/spoke.spk".

I also have this problem, can anyone help?

Quote from denis-takumi :

new bug when change cutout

Thanks, I'll try to reproduce this.

Quote from Cronick_ :

I also have this problem, can anyone help?

Yes. You can do this: [EDIT: Actually you can't do this - see superlame's post below]

- enter the modeller from the main screen
- load OBJ
- save as an LFS object
- now you can load it in the spoke editor

Please let me know if that doesn't work.

i create full empty SRE file with
- no lods
- no vertex
- no faces
- no maps
- no cutouts
- no pages

editor can load file but:
- when i click "tri" tab - it crash
- when i click "build" tab - it crash

Quote from Scawen :

Please let me know if that doesn't work.

The lfs object file extension is .sre, while the rim/wheel is .spk . So It does not work.

Well it can work but will some extra steps. You need to modify 1 value in Hex Editor.

Steps:

Load .sre which you saved as LFS Object from The Modeler in HEX EDITOR.
You need to modify the first values - Replace the SREOBJ with LFSSPK
Save the file with new extension - filename.spk

After this you will be able to load it from the spoke editor!


All thanks to Draggo.

Here is what you can see inside Hex Editor.

Quote from Scawen :

About the top speed, there is a built in limit of 200 m/s. It's around 720 km/h or 450 mph. But according to Wikipedia, the fastest dragsters reach around 335 mph so that limit shouldn't affect you too much. To me it seems like tyre physics are the biggest problem the dragster faces at the moment.
.

Well I already knew about those speeds but top fuel dragsters are limited to that speed for tires and insurance purposes I have provided a video timestamped to the section which explains this
( https://youtu.be/g0KTGHGXqsQ?t=344 )

I do not which to delay any updates but if this could make the todo list then I will be happy to sit and wait for it to be addressed, I will go ahead and amend the changes based on your information and see where it leads me, with the limitations of the game I stepped out of the "realistic" spec just trying to chase down a realistic time then I wanted to work backwards from there but I have not yet even been able to replicate a real-life timeslip but I will not give up!

Thanks for your detailed explanations and support you give.


edit: 10:30 is an interesting timestamp also (regarding power to the ground), maybe worth a quick peak, if you have intentions of drag features in future.

Quote from denis-takumi :

i create full empty SRE file with
- no lods
- no vertex
- no faces
- no maps
- no cutouts
- no pages

editor can load file but:
- when i click "tri" tab - it crash
- when i click "build" tab - it crash

OK... this is an invalid file. There must be one mapping, one cutout and one page. LFS doesn't create files like this, so I think we are talking about a file created by an external program?

I think the bug here is that LFS loads that file without complaint. Instead it should say "corrupted file" I suppose?

Quote from superlame :

[b]
The lfs object file extension is .sre, while the rim/wheel is .spk . So It does not work.

Thanks for the information. I should have checked before. I had forgotten that the spoke files were saved separately.

Now that I think about it, this is because they are not really compatible with ordinary object files. The reason is because triangles can be connected from one spoke to the next. It has a rotational symmetry system instead of the mirroring system. The way it was designed, you are supposed to build a spoke in the spoke editor, and make use of the special connection system from one spoke to the next to build an object with rotational symmetry.

A triangle that refers to a 'mirrored point' might now refer to a 'point from the next spoke' so it can all go wrong and that is why .spk objects are different and kept in their own folder separate from .sre objects.

The spoke system has not been designed to load complete wheel objects from other software. What about the fact that the minimum number of spokes is 2? I'm a bit concerned now that people may be loading in entire wheel objects and then LFS will double it and the whole wheel will be drawn twice, which is very inefficient.

Quote from Scawen :

OK... this is an invalid file. There must be one mapping, one cutout and one page. LFS doesn't create files like this, so I think we are talking about a file created by an external program?

I think the bug here is that LFS loads that file without complaint. Instead it should say "corrupted file" I suppose?

yes. it will be great, because some times i saw this message

I think that this bug is related to maps, when you delete all triangles and points and then in the "build" tab try to delete an unused map.

my guess is this happens when the program tries to link maps to triangles

if you can satisfy my curiosity, I would like to know what 16 empty bytes are present at the beginning of each sub-object of the VOB file

and what are the 20 empty bytes after the "number of lods" byte in the SRE file

Quote from Scawen :

The spoke system has not been designed to load complete wheel objects from other software. What about the fact that the minimum number of spokes is 2? I'm a bit concerned now that people may be loading in entire wheel objects and then LFS will double it and the whole wheel will be drawn twice, which is very inefficient.

That's why we have to cut the whole rim like this to load it properly (which is not ideal).
360 / 5 (spokes) If would be possible to load the full rim ... minimum number of spokes 0?

Quote from denis-takumi :

I think that this bug is related to maps, when you delete all triangles and points and then in the "build" tab try to delete an unused map.

Yes, that bug you reported before is fixed in my version, by not allowing the last mapping to be deleted.

Quote from denis-takumi :

if you can satisfy my curiosity, I would like to know what 16 empty bytes are present at the beginning of each sub-object of the VOB file

and what are the 20 empty bytes after the "number of lods" byte in the SRE file

These are just empty names.

Quote from Evolution_R :

That's why we have to cut the whole rim like this to load it properly (which is not ideal).
360 / 5 (spokes) If would be possible to load the full rim ... minimum number of spokes 0?

I did some testing and look what I found out

Edit: If you change the number of spokes the rim goes crazy Look what happens when you decrease the number of spoke by 1 ( 4 ) ( Second picture )

I wonder if that's rendering the whole wheel 5 times, but since it's perfectly symmetrical, it's not visible.

Yes, almost not visible, but very inefficient.

and new bug in game

- play the game on mod car in real time
- update mod (add new textures and maps)
- after public go to game
- go to box and then go to track
- mod was updated but new textures still not shown

Quote from denis-takumi :

and new bug in game

- play the game on mod car in real time
- update mod (add new textures and maps)
- after public go to game
- go to box and then go to track
- mod was updated but new textures still not shown

Maybe restart your game or reload the textures.

Options -> Graphics -> Textures ( excluding skins ) if its on high res, put it on low res and then back to high res as it is originally.

Quote from superlame :

Maybe restart your game or reload the textures.

Options -> Graphics -> Textures ( excluding skins ) if its on high res, put it on low res and then back to high res as it is originally.

ofcourse reloaded textures or resarted game fix it but its not normal

if car updated you must see all updates

Good point, it would be good if LFS automatically reloaded the car's textures after downloading an update.

thanks

nametags are going crazy + car model becomes corrupted.

Video-https://youtu.be/2ZhnlnUgmQ0

I don't know if this belongs here. But i recieve this message wenever i try to take a screenshot for a mod skin. The problem is that my laptop's max resolution is 1366x768

Thanks for the report. In fact it's not ideal that the screenshot function takes a screenshot from the actual screen. Maybe I can change it to use an off-screen surface of the best size.

Thanks, I agree my 'improvement' to the names above cars is doing some strange things. It was supposed to raise them a bit for the high vehicles, but it seems to vary depending on the track, or location. I'll look into that!

Is that damage problem reproducible? Does it happen only to that car or did you see it on others?

Another case of the player names raising, in a race on South City under the bridge, maybe it helps debugging:
https://streamable.com/b5x1lc
Attached .mpr as well.

Yes, I've just realised I mistakenly used a height value that depends on your car's altitude.

It was done too quickly this afternoon just before release, as I thought it would be an easy fix! It was kind of working at Autocross layout. How it is now it that if the ground altitude is at zero, the names are in a roughly OK position. Above that altitude, the names will be exactly as before. Below zero altitude, the names will go up in the air!

EDIT: Fixed in my version now.