I was announcing this already because in your previous comment you said you were done editing the map, and at this point the map loads fine (except that lighting problem you pointed out, I'll see what I can do). But it's not yet ready for heavy editing. Though editing the nodes themselves should work with no problems, saving changes in the entities is not perfect.
Wuzzy wrote:could you please give a brief explanation of your new chat commands?
The commands are /tsave and /treset, the "tutorialmap" privilege is required to use them (though that's given by default right now).
"/treset" is the load command, though it can be renamed.
It's intended for both commands to respectively save/load both entities and schematics (both "save_schematics" and "save_entities" get called on /tsave), but like I said in my previous post, right now there's no perfect way to manipulate the entities table from Lua (only entities that have been loaded in memory can be operated with, and there's no clear way to determine whether all the entities of a given area have been loaded.. usually only the nearest entities around a player are). Because of this:
* "/treset" doesn't really remove all the entities in the map (neither restores the saved ones at this point), only the nodes
* "/tsave" will only save new entities that are loaded and didn't exist before in the data file. It uses the currently saved "entities" data file so that it still keeps saved entities that are not loaded. This is why I was saying that saving is incremental. Right now the entities won't be removed from the saved data when you remove them (I can't clearly tell apart an entitiy that's unloaded from one that got removed)
I was thinking of defining a radius around the player in which the entities are properly removed and readded (already there's a radius of 1 block around each loaded entity that will do the refresh). So if you remove an entity, saving the map when the player is close to the palce where the entity was will get it properly removed. But I'm unsure on the radius to apply yet (too big of a radius could potentially remove entities that were simply not loaded in the map). The default value that minetest can ensure the entities to be loaded is only 2 blocks, that's very short.
Perhaps a better alternative would be to manipulate the __builin:item definition to keep a table that caches the items that the player has dropped/removed. But I'm not sure how much of these entities is hardcoded and if it's possible to override the callbacks.
Wuzzy wrote:With LZMA it could probably be even made smaller.
That's not supported by the lua API. Right now I'm using minetest.compress / decompress which uses zlib. Still, I think zlib is a good compromise between compression ratio and speed. Probably LZMA would make map generation noticeably slower.
Wuzzy wrote:you just included a full copy of WorldEdit.
Like I said, it's not really a full copy. None of the user-visible functions from Worldedit are there. Basically only the schematic handling logic was taken. Worldedit is actually a modpack and I only included the mod with internal logic.
Your biggest headache won't be updating, it won't make much difference to update the code because right now it's simply not possible to use the full-blown worldedit mod along with the tutorial game, because the names will conflict.
It could easily be renamed. But I was rather thinking on experimenting with the functions from Sokomine's handle_schematic. She implemented a way to store metadata in a separate file and use the official ".mts" format. I have a feeling that using this would improve the map generation speed (also perhaps this would help with the lighting problems, otherwise I might have to find a way to recalculate the lighting).
I'm also unsure if Worldedit's AGPL license would be fine for LGPL minetest.
Wuzzy wrote:the editor is included with the object that is subject to editing itself. That gives me the biggest headache. It would be better if the editing environment is loadable as an independent mod, so I (or any other map maker) could update WorldEdit independently.
This could be done, but I'm not sure if it's worth it. You still need the logic to load the data for the map generation, so you could only take out the saving logic. And this logic will still have to depend heavily on the same parameters used for loading.
We could add a separate privilege for actually saving the map so that people won't mess it if you want to give the player the ability to reset it. Though you could do this with some special block instead of granting them tutorialmap privileges and asking them to use the terminal.
Or to make it even more esoteric, saving could require a parameter in tutorial.state that's disabled by default, so only if you manually edit your world's configuration will you be able to save.
Wuzzy wrote:Overall, I guess it will be time for an update to version 1.9.0 in the near future, after a long time of no updates.
That's nice to hear! I'm a relatively new player and actually I still don't know what the cinematic mode actually does or what "list rings" are... and I didn't know about bouncy blocks or that combat mechanic.
Wuzzy wrote:(post more important core features if I forgot one)
What about navigation inside a boat? You could make a small maze filled with water (or lava.. do boats float on lava? that would be interesting to know) and put a gold ingot at the end. A maze would also be a nice way to introduce the minimap.
Some mods have other controllable transportation methods, like horses, that work with pretty similar controls as the boat, so it might be nice for new players to learn to use it.
I'm not sure but maybe the user should know as well about crafting locked chests and what it being locked means, since this is in minetest_game and it's handy if going for multiplayer. Thought it's not useful for singleplayer, and might be hard to showcase it.. so maybe it's not a good idea on second thought.
But you could perhaps include a locked chest "owned by Wuzzy" and add a sign saying "sorry, you can't open this chest because it belongs to someone else" :P
Wuzzy wrote:brand new section to the Tutorial: Combat arena.
That looks quite exciting. You could give the player a bow and teach them to shoot at some simple moving targets. Then add a static training decoy with a health bar (lott has this) so we can see how much health a blow removes.
I could try and help with this as well.
Though since mobs are probably gonna lose health and die, it might make more sense to have a block that spawns them.