Project Modding Arc

[Immortius]

Added in a dialog for selecting what mods a world will use during creation. The "Create New World" dialog now has a "Mods..." which allows mods to be turned on and off. The mod selection is then saved with the world and restored when the world is loaded.

 

[Cervator]

Played around with it a fair bit more today and it looks really nice and handles well

I fixed a few minor namespace bugs (books & potions) just now along with a benign pathing error that was getting logged - here's for hoping I didn't break anything. It still seems quirky as all out to get the mods into the right state for IntelliJ to run (or even for the modules to be recognized, A'nW isn't even getting that - might be a lib jar issue) . Compiling each mod directory manually inside IntelliJ seems to be the way to go, but even that seems quirky

Applet locally is crazy. Two of the mods don't load and a couple in-game are showing "null" and what not. Totally unsure if I'm not doing something right there. Meh, it works if you run it with all the mods deactivated - nice touch that you can't deactivate Core!

Much easier to get it to run from the command line, although I think it failed for me once then I did a simple "Make" on the mod dirs and it worked. A'nW just ran it twice and it worked via command line

 

[Immortius]

Your changes look good.

One problem with running the applet locally is the applet will download the mods off of the terasology site, rather than using the local ones, due to the way the index.html is set up. The other is that if you have any of the old zipped mods hanging about in the .terasology folder then that may cause conflicts - the zips will be read but not the jars, so the code won't be found.

The problem with running from IntelliJ is that it doesn't recognise the mods as needing to be built to run Terasology. I'm not sure how to set that up, since they are not dependencies of the engine (they can't even be runtime dependencies since that puts their code on the classpath which isn't quite correct). I need to do some more messing around and see if I can figure it out. Probably less of a problem for Eclipse since it is pretty eager to build code.

I'm also not sure if the system works properly on Linux or OSX at the moment - if anyone on those OSes can test it out and let me know that would be great.

 

[Cervator]

Here's another potential feature to add to the list here sometime if it makes sense: Allow textures in a mod to have override priority vs engine or other namespaces to allow texture pack mods if there's overlap in exact block names.

I figure that might benefit either from making order matter in the mod list box (and including an always-on "engine" entry?) or a way to select/enable a specific mod as a texture pack / always pick like-named textures from here first

Edit: We could probably use the same for GUI skin packs. Just allow textures in mods to overwrite engine textures like the main menu title etc.

 

[Immortius]

Ah yes, I have been thinking about this a bit. I would probably go the route of having an explicit override list or directory structure as part of a mod, otherwise it undoes the benefit of having everything namespaced (mods would randomly conflict and replace each others elements). And after that, yes, some sort of conflict resolution would be necessary.

I would also tend towards having the server choose the skin for world rather than individual clients picking one unlike Minecraft, partially to be a little different but mostly so that all players on a server have a consistent skin.

This won't work for the main menu though - mods can't take effect until a game is started. The initial state of the game is currently sacrosanct.

 

[Cervator]

Okay, that's fine - progress will be progress, and different is good

 

[Immortius]

A small update on this one - I added support for asset overrides. This allows modules to replace assets defined in other modules (including engine). Which means it is now possible to create tile packs - to say the least.

The way this is done is by adding an "overrides" directory into a modules. Under this directory you can create a directory for each module you wish to override assets from, and then in those directories add assets as usual. So to override engine:grass tile texture, you can use the structure

myMod/overrides/engine/blockTiles/grass.png

There are two issues with it at the moment:

• If two modules override the same thing, the result is nondeterministic (one of them will be picked). Not guaranteed it will be the same one on different machines in the same multiplayer game either.
• Switching between worlds with different overrides, or worlds with and without overrides, during the same run of Terasology will probably have some issues - likely the first version of an asset loaded will stick. This is due to the currently broken asset unloading.