MX Simulator

aeffertz wrote:Okay, that explains it perfectly and is actually easier than I was expecting. It's really nice to actually be able to place the flaggers in the editor now! Now if only we had the height adjust slider for statues. :P

I just place all the flaggers in editor first and then copy and paste the statue lines into a new document and do a 'replace all' flagger.jm with flag.jm and same for the png.

BTW, if you use that code set g_flagger_updates_per_frame to be >= the number of flaggers. I was messing with incremental updates to the flaggers but the cached poses make it fast enough that it's not worth it.

Freddy694 wrote:jre didnt like being a flagger, he is clearly showing it lmao

The flagger armature has an extra segment in its spine.

https://gyazo.com/cf6634dfb5129adf99559380fbdb2b20
why is it saying that?

Because it's an indie-game an isn't a signed (?) executable, which costs a lot.

Nope. It's because it's a .exe file. That means it could be a virus installer. If it was compressed, it wouldn't give that message.

Wahlamt wrote:Because it's an indie-game an isn't a signed (?) executable, which costs a lot.

I don't think it's that expensive. I should probably look into it.

jlv wrote:The flagger armature has an extra segment in its spine.

I added a new model to the armature in your flagger test and mapped/assigned all the bones to the new model and it does the same thing as Freddy's picture.

It was an issue when I was exporting it from 2.79. I copied the file over to 2.8 and exported it and it fixed the issue.

jlv wrote:I should probably look into it.

PiBoSo eventually did with MX Bikes. It would take forever to load or say it wasn't a reliable address or not load at all for a while. Now it just takes a while, kinda. I use Chrome.

Can you make the game non single core, so we don't lose frames from a simple 3d flagger update etc.

Ryan721 wrote:Can you make the game non single core, so we don't lose frames from a simple 3d flagger update etc.

jlv wrote:

Wahlamt wrote:Because it's an indie-game an isn't a signed (?) executable, which costs a lot.

I don't think it's that expensive. I should probably look into it.

I don’t want to harp because I know you’ve heard this a lot, but what prevents you from updating the game to run multicore support? Is it just very time consuming, would you be able to hire a dev team to help you?

I feel like the load times have increased with this new snapshot or something? I wouldn’t time out when joining a server before now I’m timing out and when I disconnect and reconnect it seems to reload most of the track again.

aeffertz wrote:I feel like the load times have increased with this new snapshot or something? I wouldn’t time out when joining a server before now I’m timing out and when I disconnect and reconnect it seems to reload most of the track again.

No changes related to loading in this snapshot. There were some inactivity timeout changes on the last server, although now that I look at it again it looks like I only fixed it for inactivity timeouts (i.e. player is connected but not doing anything) so a dropped connection timeout still won't kick you like it should.

MOTOZ293 wrote:I don’t want to harp because I know you’ve heard this a lot, but what prevents you from updating the game to run multicore support? Is it just very time consuming, would you be able to hire a dev team to help you?

For games it's kind of hard to find super parallel things that aren't already on the graphics card. That's why you don't usually see much threading in games. Another problem is that it's only a fairly recent development that low end CPUs have lots of threads to use. It makes more sense now. I'm planning on redoing the terrain engine first though since there are bigger gains to be had there. After that I'll probably make erode use multiple threads since I'm pretty much out of ideas for more optimization there, although redoing the terrain engine will speed up erode too since I won't have to make it work on cards that don't support GLSL shaders this time.

jlv wrote:For games it's kind of hard to find super parallel things that aren't already on the graphics card. That's why you don't usually see much threading in games. Another problem is that it's only a fairly recent development that low end CPUs have lots of threads to use. It makes more sense now. I'm planning on redoing the terrain engine first though since there are bigger gains to be had there. After that I'll probably make erode use multiple threads since I'm pretty much out of ideas for more optimization there, although redoing the terrain engine will speed up erode too since I won't have to make it work on cards that don't support GLSL shaders this time.

Awesome news! Thanks for not giving up while dealing with all us whining assholes

any news on the stuttering/freezing issue?