This is the correct topic to:
- make request about mod you want to be made compatible with MCL2
- share information about the mod, that you made compatible with MCL2 (and MineTest Game, and ...)
- share information about the mod, that you ported to MCL2
Wuzzy wrote:My general notes and recommendations about MCL2 mods:
- Remember that MCL2 is very different from MTG architecture-wise, so don't make to many assumptions
- Remember the groups in MCL2 are different, too
- You can try to be compatible with both MCL2 and MTG at the same time, but you don't have to. Keep in mind that both games are different, so expect to add lots of boilerplate code. Sometimes it might be easier to for an MTG mod for MCL2, esp. when many gameplay tweaks are required. Use good judgement
- Add help support for all your items and gameplay mechanics. MCL2 is using the Help modpack:
viewtopic.php?t=15912. Besides, it is generally a good idea to write documentation for all your items. The help modpack is only as useful as how many mods support it. :)- Read README.md, API.md, GROUPS.md and CONTRIBUTING.md
- Play MCL2 and read the in-game help and make sure you understand all the mechanics well. Take your knowledge into consideration of the gameplay design
- Keep writing style consistent
- As I said before, ask me in IRC if you have questions
- If your mod re-implements a Minecraft feature very well, please contact me so I can include it in MCL2
Posting rules:
0. actually test your changes before publishing (hmm?)
1. link back to original base mod
2. provide description, which includes download link, picture, installation instructions, license
3. specify if your work is "compatible" (logic expanded to support MCL2 in addition to previous) or "ported" (logic modified to run in MCL2) mod.
- in case mod was made "compatible", consider contacting original mod author for upstreaming your changes
- mod should be preferably hosted on a version control hoster, like github or similar; so that your changes can be merged to upstream.
4. you might want to modify mod readme with version suffix (like "mcl2": 1.0 -> 1.0mcl2) to:
- distinguish between your version and original
- specify the version your changes were based on
5. don't forget to modify your posts once your changes were accepted or you have news.
How to make mod compatible
1) deprecated things:
depends.txt - use "optional_depends=" or "depends=" in mod.conf instead, then delete the file.
Ofc, check that the mod works for MT5.
description.txt - move text into "description=" in mod.conf, then delete the file.
2) dependencies:
Minetest Game mods hard-depend on the core mod default. This core mod is not loaded with MineClone2, instead mcl_core is present and as such also signalizes, that MCL2 is running.
Thus, compatible mods should have no hard-dependencies on these two core mods.
Use this string: "optional_depends=default,mcl_core" and remove default from "depends".
Compatible mods will load one or another of core mods. Situation where none of both mods is present means a different game is run, in which case the game will certainly throw an error with the mod and just won't run. Not big difference from missing hard-dependency.
2) After specifying dependencies, its time to assign correct behavior and correct items depending on which game is running. Usually its just different items, sometimes different sounds, but it could be expanded into different textures and so on with the switcher code below. The switcher is only a primitive abstraction layer that uses local variables on per-file basis to minimize influence on logic in the underlying mod itself.
Begin checking in init.lua and then other lua files for presence of default ("default: ...", "default.") items/functions. Afterwards check both Minetest Game and MineClone2 if everything works. Then re-assign proper groups and apply more polish, like MineClone2 documentations or mod dialogs (formspecs) in different, game-based color.
The switcher logic Part 1. This part checks for presence of core mods, which allows to take decision which part to execute later. This way you can also check for presence of other mods:
Code: Select all
local default_path = core.get_modpath("default") and default
local mineclone_path = core.get_modpath("mcl_core") and mcl_core -- dynamic detection of mcl2 instance
-- here is an example of extra game support: -- local someothergame_path = core.get_modpath("someothergame_lib") and someothergame_lib
Code: Select all
local moditems = {} -- central local table, which can be expanded with data, like below
if mineclone_path then -- mineclone2 is running
moditems.iron_item = "mcl_core:iron_ingot" -- example, mcl2 version of iron ingot
moditems.sounds_wood = mcl_sounds.node_sound_wood_defaults -- example of function matching, perfect to replace sound handlers; note absence of scores "()" here
moditems.text1 = S("MineClone 2 string") -- item description or similar string, loaded only for mcl2
-- elseif someothergame_path then -- example how to expand for other games.
else -- this is default, MineTest Game
moditems.iron_item = "default:steel_ingot" -- iron ingot in stock MT
moditems.sounds_wood = default.node_sound_wood_defaults -- default function
moditems.text1 = S("MineTest Game string") -- item description if mod is loaded in MT
end
Code: Select all
material = moditems.iron_item, -- replaces item string
sounds = moditems.sounds_metal()
..
sounds = moditems.sounds_wood({ footstep = {name="default_grass_footstep", gain=0.25}, }), -- replaces function, absence of brackets allows switcher to accept arguments
_doc_items_longdesc = moditems.text1-- replaces text string