Haha, sorry, I'm just having a laugh. The point is that the concept of r̨͘ȩ͟d̵͠u͘͡c̢i͏n͜g̶̀ power causes me physical p̀ai̡͡͠n and threatens the release of el͝ḑ̛̛r͜͞i̧t̡̛͢c̴h͝͞ ̀͟h̶͞͡ơ͘ŗr̵̴o̢͡r̛s̡ up҉̢͡ǫn̸̸ ̨͟m̸y̵͢ f͘e̡e̢̧b͢͏͢l̸ę ̶͢h̶͏̕u͏̧m̀́͠á̢͞ǹ̡̛ ̡͟m͢͢͏i̸̕ǹd̶. No biggie lol. You too can release eldritch horrors! http://www.eeemo.net/ I actually will do the 500 hp version, would be i̕͠ńt͘͟e͏r͏́͟es̵̷t̶i҉̶̧n͘g͜.
Okay, I was talking about a few technical issues I was having with loading ESC configs and passing data to the UI. I've cracked both issues! First up with passing data to the UI, I'm a bit new to Lua, and an early test I had done led me to believe that I couldn't just pass tables with arbitrary values via the electrics stream. Turns out I absolutely can, it's as simple as building a table, eg, "saberData" and then saying "electrics.values.saberData = saberData". Boom. Done. So the UI debug app will get a lot more detailed, but for now it's finally showing negative throttle values: And secondly with the ESC configurations, the issue with only being able to load the ESC values if the file was named "esc.lua" was ultimately pretty simple to fix. Basically the section in the jbeam file that contains all the variables is a table named "esc". If I rename the table to "saber", I can load the values in a script named "saber.lua", so this mod will remain compatible with the standard SBR parts and any other mods made for the SBR. This is good news in my opinion. Now I'm setting up tuning options for the Saber ESC: So it's all going pretty well. Will spend some time tuning the various vehicles I've got and then I'll be uploading an update.
TL;DR: Figured it out, did a bit of manual text editing of the .dae files and added a materials.json file. I still don't know how to edit the .dae file in blender to get this result though. I would also still like to know if there's a way of reloading textures and meshes without completely refreshing the scene and engine respectively. I've done a little bit of cosmetic work, I've got some nice looking badges. I'm fairly happy with the font: I've done a little bit of colour adjustment on the logo: And here's the overall effect: In the stock game's badges there's some shading going on in the specular and diffuse maps, but I didn't know how to achieve that, or what exactly it was supposed to be modelling, so I just used flat colours for my own text and added a normal map for the 3D effect. It seems pretty good to me. If anyone can explain exactly what that shading is meant to be and how it's done I might take a shot at it. Blender help needed: I'm currently overriding the eSBR lettering .dds files in order to get these textures into the game. It seems to me that these textures are referenced in the .dae mesh file. I can manually edit these values in a text editor, but it's a tedious process and I'm not having any luck with it. Can anyone help me with how to assign these textures in blender? EDIT: I've got a separate .dae file called saber_lettering.dae, it only contains the few lettering objects copied from sbr.dae and renamed to be referred to in the jbeams. So far this is what I have in blender: But this is the result in beamng: Although I'm not yet 100% convinced that the .dae file is actually getting loaded by beamng, because I've tried moving the meshes around just to see if those changes show up and so far they don't. EDIT2: SOLVED! So it turns out that when I make changes to the .dae files, I actually need to completely close and reload beamng in order to see those changes show up for some reason. That's... not ideal. But anyway, it looks like the node layout shown in the blender screenshot above is exactly right. I just needed to restart the game. So some weird stuff I've noticed: changes to scripts and jbeams can be reloaded just by hitting CTRL+R. Changes to .dds files require me to drop out to the main menu and completely reload the level. Changes to .dae files require a game restart. Pretty odd, and it does slow down the workflow a little bit. Is there anyway to force a reload of these files without closing & restarting the game completely? EDIT3: No, it's not solved. My problem was being masked by the fact that I had sbr_elettering_x.dds files in the same folder with the saber_lettering_x.dds files. The material node layout wasn't doing anything at all. I still need to know how to refer to .dds files in the .dae files so they will show up. EDIT 4: Finally figured it out. I had to make a copy of main.materials.json (found that info here: https://wiki.beamng.com/Introduction_to_skin_system), then just keep the lettering entry and change a few names. Then I went into the text of the .dae file and did a search and replace, so sbr_elettering -> saber_lettering tailgate_300 -> tailgate_1000 and so on. That seems to have done the trick. Now I just need to add a 500 version and it'll all be cushtie.
Hey, so I've just come back to work on this and I noticed that my rally configs were sitting rather low-slung, and I noticed that the ride-height adjustment options were back to the defaults. I checked my jbeams and they were different to what I saw in-game, so the next thing I checked were the stock jbeams. Turns out the stock car now has a rally suspension part, and it shares the exact name of my jbeams. Now I don't mind you using my parts, obviously that's part of the license required for making the mods, in fact if my work makes it into the base game I'm really happy about that, but there are a few issues. First of all I'll need to release a hotfix to get the Saber's rally suspension back to the way I've set it up. I've just changed the jbeam names, it's not a big deal. The second issue is a bigger problem. See, in order to get spring rates soft enough for a proper rally suspension I had to boost the available ride-height levels to absurd levels, like 60cm at the back, otherwise the chassis would just drag along the ground. I assume this is because "ride height" adjustment is not actually adjusting the ride height but the adjustment collar for the coils. Now however that's simulated it doesn't seem to be causing issues but obviously in the real world a rally car wouldn't have that much adjustment and if you did it that way then the springs would be so short they would be bottoming out. It seems like it would work better if "ride height" were set with the spring rate in mind, so that the game simulated a longer unloaded spring length for softer springs, and calibrated it so that a ride height of +0.0m would be the same for all configs, regardless of spring rate. Anyway, just a thought. In the short term the solution would be to change the stock rally coilovers to allow the boosted ride-height. This whole situation has got me wanting to create a suspension tuning app that sets the spring rate according to desired frequency and automatically adjusts the dampers for a given type of suspension, like road, rally, race, hillclimb, etc. It would enable people to ask for "more stiffness, less damping, raise the front a bit" in a simpler way, rather than needing to dig into the nitty gritty of all the exact numbers.
