Suggestions & feature wishlist

[SiSL]

Basic example:



my_mod_base_blender means where your mod files are (where you will select as base folder in Blender)
base is newly created folder where you can put things that you dont want to export in your mod (like common textures and libs so on) (it should be named "base") or if you will use same base on many projects, you can always use single base folder named base on some drive and symbolic link it to parents of your projects

[50keda]

Yep, as SiSL wrote. You should actually link root game path not just "vehicle" folder or any other. And yeah, I believe you that it would be more convinient for you to have it in UI, but everything should be thought trough again about paths. So blender tools for blender 2.8 might bring some changes.

[vad&k]

@ SiSL, Is the standard folder structure of the game stored in your "base" folder? Simply put - are there any folders like "material", "ui", "vehicle" with all the necessary subfolders inside your "base" folder?

You should actually link root game path not just "vehicle" folder or any other.

Yes, but in this case, the blender will use "//base/vehicle/bla-bla-bla" as the path to the texture, and not "//vehicle/bla-bla-bla" as it should be.

but everything should be thought trough again about paths.

Simply, when importing a .pim file, do the same behavior as for "ConverterPIXWrapper" (all specified databases are available for reading). When exporting - do not process files located in the texture library (similar to the contents of the "Hookup Library"), but the contents of the pit files, inside themselves, must contain the correct texture paths.

So blender tools for blender 2.8 might bring some changes.

understand. )

[SiSL]

May be that might give an idea



BASE folder and MOD folder has same structure just like game structure: def / material / unit / vehicle etc.

1. MOD folder will be your own Mods Base Path in Blender settings.



2. Blender can see and use textures and such from base folder which is sibling of your MOD folder. You can go ahead and pick textures from sibling "base" folder (like vehicle_reflection.tobj from base/material/environment etc.)

3. When exporting your mod, only MOD will be exported/converted as final mod and base will not be included. Therefore, base is only used for common textures, hookups etc. where they are already in game and dont need to be in your mod.

[50keda]

@vad&k export is not as simple as you wrote it, but we could do sth similar to what we have for imported shaders, where you set path of the texture and additionally preview texture: https://modding.scssoft.com/wiki/Docume ... ted_Shader

[vad&k]

@ SiSL, thank. As it turned out, it did not work for me because of the icon that is not shown on your screenshot (the magnet icon was turned off).

@ 50keda, if you are interested in my opinion, then I find such a setting, though convenient, but still unnecessary. Because the textures from the base can be very much and then we get the opposite effect. Instead of light work with models, you will have to sit for a long time and turn off unnecessary textures.
I would prefer to have only .pit files with the correct paths. But I do not use the direct envelope of the models immediately to the finished mod, so maybe I don’t understand the expediency of your decision.

[AlexeyP]

@ 50keda Is it possible to add some kind of new lamp switcher tool (light switcher tool ) to SCS BT in future updates? Just to be able to check and test dif.lum, light.tex, lightmap.night, reflective, sign and their combinations with different flavors, instead of testing lamp materials.

[50keda]

Not everything you want uses same procedures, some of them are actually impossible to replicate. So what ever requires sth else than normal blender light, can not be achieved. Now if you are talking about simple day/night switch, then why don't you just switch between deferent presets in SCS Lighting panel (https://modding.scssoft.com/wiki/Docume ... e_Lighting)?

[vad&k]

@ 50keda, I would like to ask you in the future to consider the possibility of remaking the light switching buttons in the "Lamp switcher" panel.
The buttons themselves work fine, but unfortunately we have no indication of the status of these buttons. I know about short-term text messages in the dashboard. But I am saying that I cannot visually determine whether a button is on or off at a given time. I have to press the button again and read the messages. This is a little inconvenient, it seems to me more convenient if, after turning on the button, for example, they change color to a darker one (by analogy with the “Variant-Part Table”).
Or, instead of buttons, use a vertical list with check box.
By the way, a similar problem with state visualization is also present in blocks "SCS Parts" and "SCS Variants". I can perform a large number of actions with the elements in these blocks, but I also don’t know for sure whether the objects in these blocks are currently visible in the 3D-view window.
It would be convenient if for example the icon of the eye somehow changed its image. Or again go to the option to display lists with check box.
I hope I have not tired you with my wishes. BT is a great tool, but I would like it to be perfect.

[50keda]

Ahaa, yeah make sense about button indications, yeah it will be considered for 2.8

However not sure what you mean about parts/variants. You want to see icon to mark it's objects visibility: if all objects from some part are currently visible or if some of them are hidden or if all of them are hidden?