WIP Alternate Loads for the Dry Van Trailer

So at the moment, I've been able to load the Randolph Dry Van with an alternate set of boxes...


The problem is that this particular trailer is supposed to be loaded with Tasticola:


I've tried everything I can think of to separate the two textures; even going as far as to save a copy of the "loads.dae" file under a different name and try to direct the textures to map there. The file below is as close as I could get to a working mod.

There's probably something I'm missing here - I'm not certain I understand how a texture being mapped to "crate_cola" winds up on a mesh called "loads", so it's probably something in there. Could someone explain that to me?

 

In blender what is name of the material of your load? Make that material name unique and use that material name in materials.cs.

What I did play today with materials, I found out that it did not matter what I set object or .dae file name to, only name of the material in Blender was meaningful.

 

The funny thing is, it's flat gray, just like the stock cola crate. In fact, it is the stock cola crate. When I renamed the file and tried to direct the new mesh to show up, I wasn't able to.

The stock one gets its textures from vehicles/common/loads/crate_cola_d.dds . I've somehow managed to divert it to my custom crate_dogfighter_d.dds - I'm really not certain how.

 

Everything is boring flat grey in Blender.

You see coupe_engine at right side of this screenshot? That is material name and that name is what materials.cs looks for and what is mapped to texture file you specify.


So if I set materials.cs to map material coupe_engine to crate_cola_d.dds then that is what texture will show up.

Reason new mesh not showing up can be origin (Ctrl-A, select apply location) or typo lower or UPPER case are different, those are most common.

So in my example I have this in materials.cs which makes coupe_engine to load coupe_engine_d.dds:
singleton Material(coupe_engine)
{
mapTo = "coupe_engine";
diffuseMap[0] = "vehicles/coupe/coupe_engine_d.dds";
specularMap[0] = "vehicles/coupe/coupe_engine_s.dds";
normalMap[0] = "vehicles/coupe/coupe_engine_n.dds";
specularPower[0] = "32";
pixelSpecular[0] = "1";
useAnisotropic[0] = "1";
castShadows = "1";
alphaTest = "0";
alphaRef = "0";
dynamicCubemap = true;
materialTag0 = "beamng"; materialTag1 = "vehicle";
};

.Dae file name or name of the object itself has no function at all, in my example select part is exhaust manifold with name of hopper_manifold_SR20VE2 and that is inside of hopper_engine_SR20.dae but as you can see none of those names appears in materials.cs that I pasted above, it is only name of the material inside of Blender that is the hook which game is looking for.

Also when you make changes, exit the level, then load level again, because changes in materials.cs is not reloaded while level is loaded, just guess how many times I have hit my head to wall with that...

Update: One bit that might be useful...

Mesh name, that is part's name in Blender is meaningful in .jbeam, flexmesh name has to be exactly same in Blender and in .jbeam.

However .dae file name is not used anywhere, game just goes trough ALL .dae files and reads names of parts/object/meshes (synonyms), so renaming .dae file itself does nothing, as long as it has extension .dae, game goes trough everything inside of that file and catalogs every piece.

Now there is then chance of conflicts, if you have two .dae files in your mod, with both files having part with same name, which one is loaded? It is pretty random which gets loaded, so make sure you don't have two parts/loads/whatever with same name inside any .dae with single mod.

That makes interesting situation if mod is for example:
/vehicles/Hopper

I make some.dae with part named hopper_engine_v8, then there is someone else who makes a mod for Hopper that has someother.dae with part inside named hopper_engine_v8, that creates a conflict.

Hence name of part inside the Blender is good to make something rather individual, same goes for a material name as if you have two .dae files with parts having same name of material, but you want to use different texture, it will not work if material name is not unique.
Game does not know difference of coupe_engine and coupe_engine, not even if I set another to be "vehicles/coupe/coupe_engine_v8_d.dds" and another to be "vehicles/coupe/coupe_engine_d.dds", because game reads only coupe_engine and not part name or .dae filename, so game can't separate materials of same name.

Everything works as long as we have /vehicles/Hopper or /vehicles/HopperV8, but if path of mod is same /vehicles/Hopper then things break down fast, that is why material name is good to be rather unique (that coupe_engine in my example is not very unique).

That is at least my current understanding of how this material stuff works and by those guidelines it has been working for me, hopefully you get yours to work with this information too!

 

I had a feeling I was saying something stupid in the last post ... I'm very much a blender beginner, so I should have looked a little closer.



After changing the material name in Blender, loading a new .dae file into the mod, and redirecting the material texture in both the .JBEAM and Materials.cs files, I no longer have a materials conflict.

Now to fix what looks like a mesh conflict - If I'm understanding what you're saying above, if I have two .dae files with the same name, one in my mod and one in the original game files, that will cause only one of them to load. Therefore, I should change the name of "loads.dae" in my mod?

I'm not quite certain what you mean here - first you seem to be talking about two .dae files, but then seem to be talking about two parts modeled within the same .dae file?

 

Sorry I'm confusing.

What I mean is that name of .dae file does not matter at all, but what is inside of .dae file matters. You can see in pic, there are name of parts that are inside .dae file, make sure name of parts are unique (no game file or other mod uses same name is best way to avoid conflicts) and make sure in your .jbeam flexmesh name matches to that part name. This has only meaning for mesh to load up

Then make sure that in materials.cs you have your material name that you can see in Blender and make sure there are no other materials of same name. This has meaning of correct texture to be loaded.

Whatever you name your .dae file, loads.dae or whatever, that has no meaning to anything, name of .dae file is not used for anything, afaik.

Hopefully that makes it bit more clear

 

Okay, I've gone through it, I think I've successfully renamed the mesh, (and the name of the .dae file too, even if it doesn't do anything), and I'm still stuck at the above stage.





If it helps any, the LUA.

The only other thing I can think of at this point is that I'm still trying to use the default diffuse, specular, and normal maps:
​

Code:

diffuseMap[1] = "crate_dogfighter_d.dds";
    specularMap[1] = "crate_cola_s.dds";
    normalMap[1] = "crate_cola_n.dds";
    diffuseMap[0] = "vehicles/common/null.dds";
    specularMap[0] = "vehicles/common/null.dds";
    normalMap[0] = "crate_cola_n.dds";

Could that be the source of the issue?

 

No, that is not texture issue.

Flexmesh named crate_cola is nowhere to be found.

crate_cola is vanilla in game name for 3d model of cola crates, from some reason game can't find such 3d model mesh from any .dae file.

I'm bit puzzled as of why such is happening as that should be inside a common.zip

If you have typed in crate_cola to your .jbeam, then that might happen, but I don't think you need to do that as cola crates come with a game and you just need your own load to be defined in .jbeam which will then add to available loads.

 

If you look in the .zip, you should find the .JBEAM file under "dryvan" - and I've checked to make sure that it doesn't contain "crate_cola" - just "crate_dogfighter".

That's what's really strange in all this - the stock .zip does not contain any .dae named "crate_cola" - but it does contain a dae ("loads") containing a mesh named "crate_cola". I just can't figure out how it works.

 

What if you move your mod to desktop and then try to add cola load, what happens? Maybe something has got broken in your game?

 

Running the game in safe mode causes the cola crates to work properly again. Furthermore, I've verified file integrity and personally checked that the file for the crate to make certain that I haven't messed that up.

So I know the problem originates within my mod somewhere - the question is exactly where.

Would you mind double-checking the mesh in the last .zip file there? It would eliminate one variable - I'm not entirely certain I did it correctly.
--- Post updated ---


This just gets stranger and stranger. After clearing the cache, the mesh is coming back in, but the textures aren't.


Notably, the wood pallet is still textured - since I duplicated that in the mod's files, I'm guessing that the game is now looking for the cola textures in the mod's "common" folder instead of the game's "common" folder.

 

When you do export, remember to tick option "only selection" and usually also "apply modifiers" is ticked, but that is not what is causing the issue.


From some unknown reason materials.cs is causing cola boxes to have no material in my game, not sure what is with that though.
--- Post updated ---
Try this, copy crate_cola material to your materials.cs so that you have your material definition and vanilla game material definition both in your materials.cs, maybe that works?

 

No luck with crate_cola.dds in the mod file. The texture issue persists.

Thanks for the new .dae by the way - hopefully that will prevent a future problem.

 

Well, throwing the original crate_cola_d.dds file into the mod didn't work, and throwing new crate_dogfighter_s.dds and crate_dogfighter_n.dds (along with an appropriate file modification) didn't work either.

I'm officially stumped.

 

There is two of us then, I can't see how your mod can affect original cola crate as names are original.

One thing that comes to my mind is that maybe you could make your folder structure so that it is loads\dogfighter and inside there would be your common and dogfighter folders, but I doubt that will do much.

 

D'oh! It's always the file structure for some reason... Thanks @synsol !



Now it's working as it should - I've even got the weights and values properly adjusted (as best as I can figure, 32 cans/box, 32 boxes/pallet, 8 pallets/load = 8192 cans at 0.5 kg each, or roughly 4,096 kg (plus extra for the pallets, cardboard boxes, and whatever other packaging)

I just have to tweak the artwork a little bit, and I think I'll be ready for the next step!

 

.