Random tips for beginners!

[Jinxiewinxie]

I've just gotten into modding and so far, I've noticed that OFTEN I'll make a lovely little mod and then realize that I need to completely rebuild it from scratch due to random little things I wish I'd known when I was originally setting up the mod in the first place. Here are some things to keep track of so you don't have to go back and fix things later:


- It might seem smart to add all your textures into one big image file- don't do this! It bloats your end .pkm size SO much! A bunch of 512x512 images take up less space than a single 1048x1048 image (why, I don't know lol)

- Name your files uniquely! Don't use Wood.png as a name for an image, instead use something like XXXwoodDark1.png where XXX is some sort of reference to your initials or the initials you can use to easily identify your specific mod. (going back to fix this problem was SO bad!)

- Don't use the same named files in different mods you make, like if you have a favorite woodDark.png texture and you want to use it in two mods.. but realize later that the 2nd mod's woodDark should be even DARKER, then when you compile the two mods, they'll fight over which texture to actually use. You'll end up with mods using either the first image or the second (changed) image if they are named the same.

- Same for templates.. don't name your template SmallHouse.rsc because odds are someone else already has one called that and they'll interefere with eachother when both mods are loaded by the end-user. Use something like XXXuniqueName.rsc =)

-Use square textures whenever possible, like 256x256 or 512x512 because if you want to go back later and resize the image, you can just manually change the image itself to be smaller and not have to go back and change each model that uses it.. if you use odd shaped ones, when you resize the image then the uv mapping may not be centerred anymore and you may need to fix it on each individual model inside your modeling tool... ugh



These issues have cost me tons of time in re-work XD And of course, each one popped up just after I'd spent hours fixing the previous one, heh. Don't be like me lol

[RedKetchup]

we are calling this experience

[Jinxiewinxie]

I about cried when I realized I had to fix something with Bitty Housing inside blender.. there's was 90 different models I had to individually import, click around to make changes, export.. and keep track of because I'd named them in a dumb way XD

Now I know why not a lot of buildings have rotation options lol, it doubles your workload especially if you've already doubled it by adding a new texture/color option.. or three XD

[RedKetchup]

yup and multiply this by 12 diff textures ^^

[Jinxiewinxie]

I wish there was some way to ACTUALLY reference the material that's used for a model within the code. It'd be so much easier if we had a line like this in the mesh.rsc file:

Code: [Select]


GraphicsMesh resource
{

MaterialSlot _materialMesh
[
{

MaterialName _material = "Models\MaterialInstance\JXwhiteRoofA.rsc";
}
]
}


where we could just type the name of the .rsc for the material(s) we're using in models, instead of it being directly referenced inside the fbx =(

[RedKetchup]

yeah, but the good news it accepts multi-material method

[Jinxiewinxie]

I just had a random thought..

You know how you can have Mod Apple and inside Mod Apple is an FBX file that points to a material called AppleRed.rsc.. and then you can have Mod B which is literally just an override mod.. it might say to overwrite the texture called AppleRed which something else?

Could we have a mod within a mod.. that just overwrites its own textures.. without having to have a ton of fbx files and/or meshes? Could that work you think? Have Mod A and somehow also include Mod B with it?

My biggest irk is let's say I have House A with a red roof, House B with a Blue.. I have to have TWO meshes inside my fbx file which can take up a lot of space. If I could somehow just overwrite the texture that House A uses without losing its original texture, might have a real fix.