"Some/all of the add-ons would break" isn't necessarily true though. The engine still relies on Torque Script, although some default functions may change based on name or variables for the new engine, so it's a matter of what can and cannot be ported reliably. Most script based add-ons should be fine. The main thing is that T3D uses a different format for basic shapes, the DAE format instead of the depreciated DTS shape format. Arguably the biggest hurdle with going to T3D is converting every shape from the game into this format with proper animations and stuff.
t3d can import older dts versions just fine iirc, and dae files are just converted to dts on load
however it uses a completely different material system
materials are objects instead of simply being used to look up textures in a folder, and each material must have a unique name
also weapons no longer use lods as viewmodels since t3d supports proper viewmodels, with movement anims too
i think a lot of people underestimate how much work it takes to make a moddable game on t3d without watering down the engine features so much that you might as well still be using tge
maybe t3d 4.x will have mod support back...
for functional mod support, you would need to:
-
keep all server assets in a list mod makers shouldn't have to register every asset manually (though they should be allowed to, for things like chat emotes or skyboxes)
you would need to make the server send clients all the assets they need, instead of letting them look for local files
-
reimplement file downloading while some file downloading code is left in the engine, it is even slower than blockland's and is not actually hooked up to anything
you would also need to implement a cache system, and make the resource manager use cached resources instead of looking for local files
-
make all client side fx objects into datablocks post fx, shaders, materials, and all the objects those require are entirely client sided in t3d
you would need to make them into datablocks (not very good for things like materials which you might want to manipulate at runtime)
you could try netobjects, but it won't work as datablocks preload materials and are ghosted before normal objects
in a project of mine i made materials into a special type that is ghosted after files are downloaded, but before datablocks
-
update all classes that use materials since they all expect materials to be client sided, you'd have to make them look for the datablocks sent by the server instead
-
fix terrain loading i mightve just done something wrong, but in my project, making terrain moddable seemed to take more than just making the resource manager use cached resources
i couldn't get terrain to load at all, it always ended up being a black plane (though this might just be my severe lack of c++ experience)
-
implement the new loading phases...and probably more
plus this isn't even including bricks, or the addon system itself
i typed most of this out a few hours ago and forgot to post :V
Show Posts
