Splitting the forest editor?

#21 The difference between the other issues and the forest issue is, that the forest editor a) produces errors deleting or corrupting data and b) cannot be fixed, since it is a unreadable binary and c) cannot be split, at least not by default.
You can split your settings script files like materials and move them where you want. If you have custom models, textures, materials, sprites, decals, you can just provide them with script files with your level and they will work.
You can also fix files by hand if something breaks or gets changed in the game, like files, names, paths, but with the forest you need to delete all and start from the beginning each time in order to be sure everything will be fine.

#22 I understand that it's all combined. Which is why I stated:

Quote:You will have to modify the forest and possibly other objects to deal with that, but if your modifying the forest to allow it (Edit: clarifying that "it" is to mean: forest per mission and reading it's data from an archive), the rest should be a lot easier.

So knowing that your already talking about changing the forest for a per mission setup. I was just suggesting using a package AFTER your modifications to support user mods / levels / models, etc. I suggested that because it sounds like your planning on having almost everything modifiable / extendable for a project in mind.

Why not just fork the forest object and create a new object based from it that wouldn't have the legacy forest issue? Then it's up to the designers what they use, and you can disable the legacy forest for your project if you don't want the headache?

#23 hold up Duion, I opened one earlier, its not binary, look at it, it looks to be coordinates and rotation settings to me, it even has names of stuff in there...

But its exactly the same problem as you would have with environmentals such as grass/groundcover, precipitation and decals as regardless of mission, each of them are stored within a central .cs datablock list that includes ever levels entry. they would have to be changed to work in the same way as the forest editor ideas to ensure something like 'drag and drop' level adding is possible, otherwise they still need to be opened up and any newly created entries added by hand for them to work too and the mission/level look correct.

#24 The names of the stuff is the only thing readable in the forest file and can already be used to repair things, you would need to create entries in the managedItemData.cs that are named like the entries appearing in the forest file and when you reload the level the trees will show up and you can edit them again.

But there are still some bugs I cannot solve, for example if I select an item in the forest editor meshes data the file 10 entries higher gets selected and if I press delete the 10 entries higher file gets deleted and not the one I selected. Then I have some rocks painted with the forest editor that disappear very early if you move away, while the TSStatic ones work fine.
These bugs are also in my Pack I released, so you can test them out, I tried to solve them, but the forest editor annoyed me so much that I left it that way.
Moments like these when the only solution seemed to be to delete everything and do it again from scratch made me think of a way to handle things better.

I am still not sure about how to do it, but so far I think the manageditemData should also be stored in the .forest or mission file so they do not get lost and you cannot destroy anything, the names of the items are already stored in there, so making datablocks of them would not use much more file space.

The ingame forest editor would then be used to create, edit and save forest presets. The forest presets could then be loaded from the levels forest or from separately stored files.

#25

Quote:I am still not sure about how to do it

1. Create a new folder in Levels (example: yourFolder)
2. Place the additional manageditemData.cs file in that folder
3. Open your script editor
4. Open core/scripts/server/games.cs
5. Add this line in function function onServerCreated()
just below %datablockFiles.add( "art/forest/managedItemData.cs" );

%datablockFiles.add( "art/levels/yourFolder/managedItemData.cs" );

6. Save your files and restart your game

Oh, and you know what, this also works for: managedParticleData, managedParticleEmitterData, managedDatablocks and managedDecalData.

And as always, with everything you do: Don't duplicate names!

With a little bit more scripting you can automate it as well.

Edit: Only do the steps in core/server/game.cs

#26 Two words: modular templates. I think the logical solution is that a level (or set of levels) is a module, with a dependency on a module containing forest items. Separate directories, but then other levels can also depend on the same forest items. And if you want different forest items for a different level, well, they're another new module.

T3D really needs to migrate to a module system like T2D's.

EDIT: I say this for two reasons. One: Mike's working on modular templates, so we should probably talk about this again when that's released. Two: I think modules accurately represent the ideal solution to the asset dependency problem.

#27 Yes, thanks, this worked, but it is "scripts/game/server.cs" instead of "core/scripts/game/server.cs"

A workaround for the first. Maybe I will try to manage the files in separate files for later use. So for others to install a level they will have to add the datablock to their game.cs and to uninstall remove it.

In long term something like with the materials would be cool, make him automatically check for files and load the settings or unload if they are no longer there. Or with the .cs files for models where you can specify to overwrite settings and if the .cs file is present he will load it from there and if not he will load the default.

#28 Oh gosh, did they moved that out of the core in the MIT version? I should have checked in the templates first. That's what you get when you port your game from 1.1 to 1.2 to 3.0... But anyway, it's much better to have it there. The core was initially for default stuff.

So it's scripts/server/game.cs !

The script to watch for files could be something like having the mission (level) name into a string, check if a folder with the mission name exists, check if the datablocks with their original T3D names are in there and load them.

#29 To weigh in here while we're talking about the forest editor... another issue I've found is that if I import a tree model, resize it, modify the materials etc and save it as a prefab, it works great for adding as a static mesh.
If I then want to add that tree to a forest and paint it, I can't, it wants me to specify the DAE file and then it loses all its scaling and materials I've set and I end up with huge trees unless I edit the DAE externally.

Am I just missing something since I'm a noob or should there be a feature there to allow forests to be populated with pre-tweaked prefabs?

#30 Forests are not painted as prefabs, you have a setting in the forest editor for random placement,rotation and scaling, so there is no need for making prefabs.

#31 Sure you can do random placement, rotation and scaling but how does that work if some of your trees are 500m high and some are 5cm high? And what if the materials suck? The only solution right now as far as I can tell is to edit the trees outside the editor - which seems unnecessary since torque can scale and edit static models and rescale them for the scene, you just aren't able to do it for forests.
Sorry if I am missing something here but if I import a tree and it appears 500m high in the forest, I have no idea how to scale that down inside torque.

#32 There is no problem with that, you probably just missed some settings. You can scale forest objects the same as static meshes and also edit the materials.
But why you would want to import wrong sized trees into the engine? It is much less work making it right from the start than fixing it all in the engine.
Otherwise this is not the topic here.