In-game testing of new mods (reloading resources etc...)

Status
Not open for further replies.

only_a_ptr

Infamous Developer
Administrator
Developer
Joined
Jan 31, 2018
Messages
167
Location
Prague, CZ
Greetings.

At the moment, testing and tuning new mod (vehicle/load etc...) in game is quite tedious proces. You must start RoR, load the mod, see how it does, modify it in external editors and reload in-game. You can reload quickly using "top menubar -> simulation -> reload current vehicle" option (or undocumented hotkey TRUCKEDIT_RELOAD), but that only reloads the truckfile... it won't reload or add new resources such as meshes and textures.

Technically, adding/reloading resources on the go is easily possible... you specify an OGRE resource group as directory on your disk, and then you reload it as many times as you like: Resources and ResourceManagers | Ogre Wiki

To do this in RoR, we need to separate ready-made downloaded content from the work in progress. In RoR home directory, we have 'Vehicles', 'Terrains' and 'Packs' directories, which are really designed to carry the downloaded ZIPs - modcache, loader, all the infrastructure is built expecting them not to change.

I propose adding another directory, "Projects", where each subdirectory (name wouldn't matter) would represent a new mod (vehicle, map, maybe something mixed in the future). Loading these in game would be separate from loading completed ZIPs and it would always reload the whole directory.

UPDATE: This is what I have in mind:
mockup_project_directories_GUI.png
 
Last edited:
Like add that ror crash for me every time when I try reload truck file after I use visible node debug. Don't know that is it known bug but I hope its right place to mantion it.
Is anyone experienced same?
 
Greetings.

At the moment, testing and tuning new mod (vehicle/load etc...) in game is quite tedious proces. You must start RoR, load the mod, see how it does, modify it in external editors and reload in-game. You can reload quickly using "top menubar -> simulation -> reload current vehicle" option (or undocumented hotkey TRUCKEDIT_RELOAD), but that only reloads the truckfile... it won't reload or add new resources such as meshes and textures.

Technically, adding/reloading resources on the go is easily possible... you specify an OGRE resource group as directory on your disk, and then you reload it as many times as you like: Resources and ResourceManagers | Ogre Wiki

To do this in RoR, we need to separate ready-made downloaded content from the work in progress. In RoR home directory, we have 'Vehicles', 'Terrains' and 'Packs' directories, which are really designed to carry the downloaded ZIPs - modcache, loader, all the infrastructure is built expecting them not to change.

I propose adding another directory, "Projects", where each subdirectory (name wouldn't matter) would represent a new mod (vehicle, map, maybe something mixed in the future). Loading these in game would be separate from loading completed ZIPs and it would always reload the whole directory.

Not to be that guy, but I might as well bring it up...

In BeamNG you have the option in game to "unpack" a particular mod you would like to work on. It then puts it into an unpacked folder in your mods folder. This area then has basically the exact same properties as you are describing, so perhaps something along those lines would work for RoR as well? Granted I would also be totally fine with a "Projects" folder, and, if anything else, this should be the one folder that the installer can NEVER overwrite. I have lost many a file in the long forgotten past because I was an idiot and didn't back up my projects before I installed a new RoR version.

Also, perhaps this could be taken one step further... if the game is reading files from this special folder, it will already know it must be in some sort of debug mode and is constantly monitoring that folder for changes. Every time it detects a change (I saved my truck file for instance) it will then automatically go in and hot load the truck again as to streamline this process even further. Naturally this setting could be switched on and off, but it could be quite useful in speeding things up a bit.
 
... ror crash for me every time when I try reload truck file after I use visible node debug. Don't know that is it known bug but I hope its right place to mantion it.
No it isn't known, and no, this isn't the right place, our GitHub issue tracker is the right place.
However, I'm going to finish this node debug remake soon, and that will most likely resolve that problem.
In BeamNG you have the option in game to "unpack" a particular mod you would like to work on. It then puts it into an unpacked folder in your mods folder.
I don't like the idea. Many mods aren't supposed to be tampered with. Also I want the project directories to contain extra data (tool presets etc. - future development) which won't be contained in the download ZIPs - if the author wants to open his mod for changes, he should publish the project directory separately.
... Every time it detects a change (I saved my truck file for instance) it will then automatically go in and hot load the truck again ...
Yes, this can be done, I'll look into it.
 
Last edited by a moderator:
This concept sounds great, can't think of a way to improve it off the top of my head.

only_a_ptr said:
However, I'm going to finish this node debug remake soon, and that will most likely resolve that problem.

One thing I've been meaning to mention about this. I'd highly recommend keeping the wheel nodes included in the debug, or at least a separate option to see them. Quite a few mods, including most tracked vehicles have wheels with beams attached to them, and currently the node debug is our only way to know the node numbers.
 
I don't like the idea. Many mods aren't supposed to be tampered with. Also I want the project directories to contain extra data (tool presets etc. - future development) which won't be contained in the download ZIPs - if the author wants to open his mod for changes, he should publish the project directory separately.

Yeah, I would also prefer it seperate, but I figured that I would at least throw that out there.
 
(debug view) I'd highly recommend keeping the wheel nodes included in the debug, or at least a separate option to see them. Quite a few mods, including most tracked vehicles have wheels with beams attached to them, and currently the node debug is our only way to know the node numbers.

OK, I'll do it for now, but you've touched a topic which needs bigger discussion: Future: how to define N/B in truckfile
 
Last edited:
Talking about tracked vehicles, how do you make them go forward, backward, and turn. I have two excavator mods that do not work properly. Is there a way around?
 
Status
Not open for further replies.
Back
Top