The online racing simulator
Nothing is broken (EDIT: Well, I don't think *this* is broken). That is and has always been the maximum number of editor vertices in a single object.

You need to distinguish between editor object and output object. Output objects are limited to 65536 (or maybe 65535 - can't remember) vertices.

A single editor object's output object can, however, reach up to that maximum because any vertex may be reflected, or duplicated multiple times.

Take for instance a cube made in the LFS editor. It may have only 4 editor vertices, which are mirrored to what may appear to be 8 vertices in the output object. But actually, each corner of that cube has 3 faces there with a different normal, so at each corner there are really 3 vertices. So an *output* cube really has 24 vertices (4 corners per face times 6 faces OR 8 corners times 3 normals per corner) and this is the same with any object submitted to a graphics card, no matter which software you use. So, regarding output meshes, a cube has 24 vertices, even though as an LFS editor object it will have only between 4 and 8 editor vertices.

The LFS number of editor vertices is necessarily limited to 32768, because each vertex of a triangle can refer to either a point index (from 0 to 32767) and that may be reflected - in which case the top bit is set (e.g. triangle referring to point '32768' is referring to the reflected copy of point 0 and '32769' is really referring to the reflected copy of point 1. This is the maximum that can fit into a 16-byte integer and that is the way it is coded at the moment, without any prospect of increase in the near future.

So... no, I wouldn't say you are being slow, you're just not quite up to speed yet! Big grin

EDIT: The difference between Blender export and LFS import number of vertices, may be different due to the normals as mentioned above. LFS importer duplicates points where they have multiple normals, then it assigns smoothing groups through a complicated algorithm and then eliminates duplicate editor points, so the resulting number of points can be different from that appearing to be exported from Blender. If you want to really understand it you could try with some simple objects like a cube, etc. to see what happens.
I'm just wondering now though, if it might be possible that the trouble is that that intermediate point in the process, mentioned in the last paragraph, maybe when creating multiple duplicates of points due to the normals in the OBJ file, the number exceeds 32768 for a while when in fact after group assign and duplicate point elimination it might have ended up back below 32768. If that *is* the case then it is theoretically possible to rewrite the importer to allow it to go above 32768 at that point in the import process, and check what the result is at the end, after eliminating duplicate points. This might be the case if an object has a lot of sharp edges. But actually I'm a bit surprised that your 21000 vertex object exceed 32768 in the import. Is there something funny about the smoothing settings, and have you followed our guidance for exporting from Blender? I'd be interested to know what happens if you chop off enough of the object so that it can be exported from blender and imported into LFS, if you do that does the resulting number of vertices in LFS match the exported number from Blender?
Quote from Scawen :Thanks, wonder if that's related to "You can roll during pitstop with electric car (e-challenger)"
I think here is a suitable place for that bug, added to my notes along with the others. Smile

I was wondering did this appear to be too big of a bug? It is a rather strange bug to have in the public version.
From my point of view, there are approximately 100 things (rough guess) that would take between two hours and one day (rough guess, let's say average 5 hours each to reproduce, identify, decide on best fix, implement, debug, test and merge) that are all "strange to leave in the public version". So let's suppose I fixed all them before release.

That would take around 100 * 5 hours, so 500 hours. Working 10 hours a day, that would take 50 days to do.

So there would have been no release this side of Christmas. Even if there were only 30 such "strange things" that would be about 150 hours of work, which would take at least a couple of weeks.

OK, just making up figures here, but hope you see my point.
I am not sure where I should report this, so I'll go with here.

I found a funny bug when fiddling around with suspension setup of the FORM07 vehicle mod. I was trying to make a 'wheelie setup' for the car, and when the front suspension motion range of this particular car is set to above or 0.115m (maximum is 0.120m), the front tyres just completely disappear from existence when you join the track. I can only speculate what is going on, so decided to post it here.

Car in pits before joining track with 'faulty' setup:


Car on track with faulty setup:


After you shift+p from track on faulty setup:


Suspension live data when on track with magically gone front tyres:


E: It also seems to happen on Shark C with above or 0.267m motion range
Snake-Z with 0.234m or above motion range
Attached images
unknown (1).png
unknown (2).png
unknown.png
unknown (3).png
Quote from fatalunfair :

E: It also seems to happen on Shark C with above or 0.267m motion range
Snake-Z with 0.234m or above motion range

Thanks for reporting this bug, I will follow up on the responses and try to fix it for the next version.
Some of the newly published mods seem to have invalid date so they appear at the end of the list when sorted by date.
Attached images
lfs_00001200.jpg
Fixed!
When typing /w f command,we get this:
Quote :LFSW - fuel usage on RO4 SHARK C : INF % per lap

Fuel data is stored in LFSW,so must be some problem of LFS client reading it. Shrug
LFS Client doesn't "read" the fuel usage. That message is generated at the database end and sent to LFS as a text message.
Quote from Eclipsed :When typing /w f command,we get this:

Fuel data is stored in LFSW,so must be some problem of LFS client reading it. Shrug

This is fixed.
Hi everyone, my PG 205 mod is pending since 3 days, is that normal?
Quote from NENE87 :Hi everyone, my PG 205 mod is pending since 3 days, is that normal?

It's currently in "requesting changes" state.
I see that now, but what changes are required?
Quote from NENE87 :I see that now, but what changes are required?

I usually receive in my email information about what needs to be changed in my mod.
Yeah, i'm adult now, must be check email etc Smile thx!
I'm not sure if this is a bug or user error but my model randomly switches to this looking thing. it sort of looks like lod1 mixed with lod 3
Attached images
weiord.png
Quote from RE Amemiya :I'm not sure if this is a bug or user error but my model randomly switches to this looking thing. it sort of looks like lod1 mixed with lod 3

I know this sometimes comes up (I think it may be that it happens more with some models than others). If it is reproducible then I can fix it. If it's really 'random' then it's hard for me to catch it in the debugger or identify the cause. I presume it is when the car receives damage, after a certain sequence of events before that time.

If you have a MPR which shows this happening, or a step by step reproduction method, then I should be able to fix it quickly.
Quote from Scawen :I know this sometimes comes up (I think it may be that it happens more with some models than others). If it is reproducible then I can fix it. If it's really 'random' then it's hard for me to catch it in the debugger or identify the cause. I presume it is when the car receives damage, after a certain sequence of events before that time.

If you have a MPR which shows this happening, or a step by step reproduction method, then I should be able to fix it quickly.

Basically, just hit the corner on a barrier gently 1-2x. you can see polygons go through the driver. then when you Shift+R, it stays glitchy
Attached files
CatDaddyDrift_WE5X_FZR_3.spr - 1.7 KB - 193 views
CatDaddyDrift_WE5X_FZR_2.spr - 11.1 KB - 176 views
Quote from fatalunfair :I am not sure where I should report this, so I'll go with here.

I found a funny bug when fiddling around with suspension setup of the FORM07 vehicle mod. I was trying to make a 'wheelie setup' for the car, and when the front suspension motion range of this particular car is set to above or 0.115m (maximum is 0.120m), the front tyres just completely disappear from existence when you join the track. I can only speculate what is going on, so decided to post it here.

Tnx for spotting this mate, i think we fixed it now. We tested and didnt could make it happen again. We gonna test bit more and upload soon.
Quote from RE Amemiya :Basically, just hit the corner on a barrier gently 1-2x. you can see polygons go through the driver. then when you Shift+R, it stays glitchy

I don't know what's up but your replay goes OOS immediately.

Hmm... is this a car you have made in the editor but is not on our system? I'm a bit confused as it says "FZR" in the replay name, but that's not really an FZR. If that's the case, I can't see it anyway as the vehicle is not included in the replay file.

I wonder, if it is a local vehicle, but you have left the name "FZR" as the SkinID... might be worth changing the SkinID and see if it helps - if LFS could be somehow confusing your car with an actual FZR.
Autor mods "Chansonje" and "NipeFive" problems
Those mods were published as public, but their authors have changed them to "custom" or "private" access, whihc means only listed people are allowed to drive them.
Quote from Flame CZE :Those mods were published as public, but their authors have changed them to "custom" or "private" access, whihc means only listed people are allowed to drive them.

I think it is not good that people can simply remove their published mods just like that. Unless there are serious issues to resolve. (like the sound-bug some time ago or license problems)

Also it would be nice to have a message on the website like "removed by staff: reason" or "this mod is set to private" when following a link. Currently it just directs to the list view.
Quote from Gutholz :Also it would be nice to have a message on the website like "removed by staff: reason" or "this mod is set to private" when following a link.

I really hate the private thing, there's plenty of scope for all sorts of fallout and I'm struggling to think of a case where it's useful now that we can test the crashbox against AI.

How can we organise events if the mod might disappear to a private setting 5 mins before race start? (Would we have the e-challenger event if michal couldn't guarantee the challenger mod's public setting for himself? or to NDR and SBTV?)

Could someone who has published a private mod educate me as to why? Better still, someone who has had a mod out there as public and now decided it should be private... what changed? What do I have to watch for if I want to use your mod for anything other than casual use?

Confused
This thread is closed

Cleanup - bugs fixed / problems solved
(405 posts, closed, started )
FGED GREDG RDFGDR GSFDG