MTS Editor

bzt
Member
Posts: 79
Joined: Tue Sep 24, 2019 14:26

Re: MTS Editor

by bzt » Post

Good News, Everyone! (TM) :-)

I managed to compile mtsedit under all mainstream OSes. Pre-compiled binaries are now available for Linux, Windows and MacOSX. Dear @texmex and @warpnarget, could you please give the mac version a try?

Compilation under Mac was extremely problematic, because they don't follow any standards, and their toolchain is just stupid (Apple deliberately made it dumber than the original OSS version). Here are some pitfalls:
1. first, you were wrong about the header's directory. If you install SDL2 from the dmg and follow the instructions, you'll have /Library/Frameworks/SDL2.framework/Headers (with version "2" in path and without "/Versions/A"). However you could use any directory you like, just modify the MACSDL path variable at the beginning of Makefile.
2. binary to object conversion is missing from the linker. That's just lame, had to create a tool to generate C header of the data.
3. gcc is not gcc really, it is a (badly) masquaraded LLVM Clang with strongly reduced functionality.
4. although nobody asked for it, Clang includes ALL the headers without hasitation. This caused (obviously) namespace problems with some variables. I simply don't understand why on earth do they include math.h for example when the source did not asked for it, and neither is -lm specified on the command line... This goes strictly against all C standards and common sense.
5. according to the docs as well as the manual page, the framework's default path starts with /Library/Frameworks. Well, not on the machine I've used. I had to explicitly specify -F/Library/Frameworks otherwise LLD complained about missing SDL2 framework.
6. there's no f*cking way to tell MacOSX what default argument I want to use to start MTSEdit as a GUI app (like with a .desktop file under Linux), so I had to hack the '~' into. Now if you click on the application's icon, it will start with the "Load Schematic from File" window, but if you execute it from a Terminal you have to explicitly use "-h" to get the usage info. Not a big deal, just little bit annoying.

Cheers,
bzt

User avatar
texmex
Member
Posts: 1752
Joined: Mon Jul 11, 2016 21:08
GitHub: tacotexmex
In-game: tacotexmex

Re: MTS Editor

by texmex » Post

Massive thanks, I’ll give it a spin!
Mods | Support Mesehub: bc1qluuests9rxmlnvpjrhsnyjg9ucwy6z3r0y3srw

User avatar
texmex
Member
Posts: 1752
Joined: Mon Jul 11, 2016 21:08
GitHub: tacotexmex
In-game: tacotexmex

Re: MTS Editor

by texmex » Post

Oops:
Makefile:17: *** Recursive variable `FDIR' references itself (eventually). Stop.

This is probably because the directory structure of the brew version of SDL2 is completely flat, no subfolders present.

Changing FDIR on line 17 to MACSDL starts compiling but alas:

Code: Select all

cc  blocks.o brush.o edit.o hist.o lang.o load.o main.o mts.o save.o schem.o sdl.o search.o util.o -o mtsedit -F/usr/local/include/SDL2/ -framework SDL2
ld: framework not found SDL2
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make: *** [mtsedit] Error 1
Mods | Support Mesehub: bc1qluuests9rxmlnvpjrhsnyjg9ucwy6z3r0y3srw

bzt
Member
Posts: 79
Joined: Tue Sep 24, 2019 14:26

Re: MTS Editor

by bzt » Post

Hi @texmex,

I was asking to test the pre-compiled version, but okay :-)

I'll try to help you out, but I don't know your environment neither had I used homebrew, so I'm doing lot of guesswork here with more options (-F/-L etc.). Pick the one that's closest to your configuration.
texmex wrote:Oops:
Makefile:17: *** Recursive variable `FDIR' references itself (eventually). Stop.

This is probably because the directory structure of the brew version of SDL2 is completely flat, no subfolders present.
Huh, dude, you really messed up a plain simple Makefile! :-) How did you managed to get this message? Your SDL2 path is not flat, you have "include/SDL2" for one. And I'm sure that the dylib file is not in that include directory! :-)
texmex wrote:Changing FDIR on line 17 to MACSDL starts compiling but alas:
You should not change FDIR. You should just set MACSDL to the directory where your SDL.h is, and the FDIR is generated from that by chopping off "SDL2.framework/Versions/A/Headers" (whichever parts exist in your configuration). This obviously only works if you install the SDL2.dmg as a framework from the official SDL2 download page, not through some third-party packaging tool.
texmex wrote:-F/usr/local/include/SDL2/
ld: framework not found SDL2
This won't work for sure, you've pointed the framework search path to the include directory. If you insist to set -F yourself, then set it to the directory which has the SDL2.framework subdirectory. The point is, XCode gcc will generate a path like this: "(what's given in -F)/(what's given after -framework).framework/" and that directory must contain the dylib. That's how XCode works. So for example,
"-F/Library/Frameworks -framework SDL2"
will look for the directory "/Library/Frameworks/SDL2.framework/". This is an Apple specialty, which you have to comply with if you want to link under MacOSX natively.

So if you don't want to follow the standard SDL2 framework install instructions, then do this:
1. specify your include directory after -I (uppercase i), like "-I/usr/local/include/SDL2/"
2. specify the directory which has the SDL2.framework directory after -F, like "-F/Library/Frameworks"
(this is just an example, I don't know exactly where your dylib is installed, you have to find it and use the correct path)

If you don't have a dylib file (nor an SDL2.framework directory at all), but an .so file is installed by homebrew, then
1. use -L with that directory, like "-L/usr/local/lib"
2. replace -framework with -l (lowercase L), like "-lSDL2"
(this will look for the file "/usr/local/lib/libSDL2.so")

If homebrew is as POSIXy as I think it is, my 2 cents would be:
in CLFAGS (uppercase i): "-I/usr/local/include/SDL2"
in LIBS (lowercase L): "-L/usr/local/lib -lSDL2"
and you can forget about the whole Apple-specific framework thing (but I'm just guessing here, even when I had a Mac I used macports and that was a looooong time ago).

If you are advanced user enough to use homebrew, you should be already familiar with these directories, because other packages are using these too. I wish sdl-config would be installed on the path automatically, but it is not neither under Windows nor under MacOSX... It would be a hell lot easier to get the correct compiler arguments just by calling it.

Cheers,
bzt

bzt
Member
Posts: 79
Joined: Tue Sep 24, 2019 14:26

Re: MTS Editor

by bzt » Post

Or maybe you should forget about homebrew, and install SDL2 in the official way? That's known to work out-of-the-box. Just a guess...

1. download SDL2-x.dmg from the official download page
2. open it with Finder and drag'n'drop SDl2.framework to /Library/Frameworks
3. in mtsedit/src directory, run make

Cheers,
bzt

bzt
Member
Posts: 79
Joined: Tue Sep 24, 2019 14:26

Re: MTS Editor

by bzt » Post

Hi Everyone,

New feature, blueprint generation.

You can press the E key to export blueprint of a schematic, or from command line, you can use the -b flag. It works pretty much the same as dump (-d), except it does not print hex values to the console instead writes pixels to a PNG file. The blueprint is saved with the extension "_bp.png".

Cheers,
bzt

bzt
Member
Posts: 79
Joined: Tue Sep 24, 2019 14:26

Re: MTS Editor

by bzt » Post

Hi All,

MTSEdit got a hell lot more interesting and more useful! I've added import functions for several voxel formats, so you can convert those into MTS files, and with that, load them directly into Minetest!

Full list of supported formats:
- .mts MTS files with different game mappings
- .schematic Minecraft NBT Schematic files
- .png Blueprint PNGs (not only exported, but you can import them too)
- .png Any image up to 256 x 256 x 1 can be voxelized
- .m3d Model 3D files with voxel chunks
- .tmx Tiled Mapeditor files
- .gox Goxel voxel editor files
- .vox Magicavoxel voxel editor files
- .qb Qubicle voxel editor files (full support)

Notes: Tiled .tmx files does not store tile names nor colors, so there's no way of knowing that for example tile id 7 is a Stone or a Grass Block. MTSEdit by default assumes tile ids are identical to the block ids of NBT files. If that's not the case (probably), then you can provide the block type names in a plain text file. Here each line corresponds to a tile id: the first line is the block type name for tile id 0, second line is the name for tile id 1, third line is the name for tile id 2 etc. With this option, you can load any tmx file (multiple layers supported).

Just for fun, I've provided Minetest_Tiled.tsx, which can be added as an external tile set to any Tiled map and uses Minetest textures and NBT block ids (so no need for block type names text file with this tile set).

Voxel image formats store colors only (save Model 3D, which optionally can store voxel type names too), so it is not possible to reliably load schematics from them. MTSEdit uses the closest color match to find block types for voxel colors. A GIMP Palette is provided with unique colors, which can be loaded into Goxel to remedy the situation. Using that palette only will guarantee that there'll be always an exact color match. There's still no way to handle block rotation using any of the existing voxel editors (except MTSEdit of course).

Qubicle file format support is fully featured for version 1.1.0.0. Uncompressed / compressed data, RGBA / ARGB colors, left-handed / right-handed coordinate systems etc. Magicavoxel and Goxel files may have several layers, they will be merged correctly. If the voxel image is bigger than 256 x 256 x 256, then it will be cropped.

Enjoy!

Cheers,
bzt

User avatar
texmex
Member
Posts: 1752
Joined: Mon Jul 11, 2016 21:08
GitHub: tacotexmex
In-game: tacotexmex

Re: MTS Editor

by texmex » Post

Wow, Magicavoxel support is ace!
Mods | Support Mesehub: bc1qluuests9rxmlnvpjrhsnyjg9ucwy6z3r0y3srw

warpnarget
Member
Posts: 15
Joined: Sat Oct 12, 2019 21:34
In-game: warpnarget

Re: MTS Editor

by warpnarget » Post

the app wont open when i try to open it normally, but if i run the binary from the terminal it starts up fine

bzt
Member
Posts: 79
Joined: Tue Sep 24, 2019 14:26

Re: MTS Editor

by bzt » Post

Hi,

@texmex: yeah, I've found that Magicavoxel's format is the best for voxel images. Simple and easy to parse. Qubicle weren't bad either, if there were a magic bytes to identify them. Now I just check if the file starts with 0x00000101 (which is the version), that's not really cool. Goxel format was the most difficult to implement, as it stores blocks and embeds an entire PNG image for every block, and it is not documented at all (for example it turned out that each 16 x 16 x 16 block is stored as a 64 x 64 PNG, but there are so many ways how to do that conversion from 3D to 2D coordinates... And it looks like the author of Goxel was absent from school when they were teaching about Cartesian / Descartes coordinate systems: not documented anywhere, but for him, Z is upwards, not Y as with all the other formats)

@warpnarget: thanks for your feedback! I'll look into it. Can you please tell me which MacOSX version are you using? If you could open Console and paste the relevant log lines here (if there's anything MTSEdit.app related), that would be extremely helpful.

EDIT: it looks like I might have found why you can't start it from Finder. https://stackoverflow.com/questions/102 ... rom-finder
Under some unclear and undocumented circumstances MacOSX looks like to append some unwanted arguments. These cause trouble to many cross-platform applications. Most solutions just simply remove that unwanted "-psn" argument, like here.
The problem with that argument is, that MTSEdit uses the "-p" flag to generate preview in batch mode. Therefore when you clicked on it and it got that extra "-psn" argument, it tried to generate a preview instead of starting the GUI interface.

I've updated the zip, please give it a try.

Cheers,
bzt

bzt
Member
Posts: 79
Joined: Tue Sep 24, 2019 14:26

Re: MTS Editor

by bzt » Post

Hi All,

New features:
- Air blocks are autodetected in rooms. Now not only their probability is set to 127, but force placement bit also set.
- Fixed minor issues with Tiled TMX import
- Checking out Discussion in other languages forum, I've decided to add Portuguese and Italian languages too (both seems to be popular among Minetest users). Now MTSEdit is available in 9 languages!

The Christmas meal awaits, I go. Merry Christmas to you all!
bzt

bzt
Member
Posts: 79
Joined: Tue Sep 24, 2019 14:26

Re: MTS Editor

by bzt » Post

Hi All,

New features:
- Ability to generate Minetestmapper colors.txt in batch mode (with "-C")
- Added Sponge Schematic format *
- Model 3D import finalized
- The blocks.csv has been expanded with a new coloumn, the minecraft block name. This non-conventional as it can have optional values, like "minecraft:air/minecraft:cave_air" (used by Sponge import)
- The Lua mod has been updated as well to export into this new blocks.csv format
- User interface: fixed searching for blocks with names that had some specific UTF-8 characters in them
+ Spoiler
I'd also like to call for testers and contributors. No programming skills required. All that MTSEdit lacks now is a proper blocks.csv. You can edit this file with Excel on Windows, with LibreOffice or gnumeric under Linux, and with NeoOffice under MacOSX easily (or with any text editor, vi, emacs, NotePad, etc.).

How to test? Just open as many files as you can in the MTSEdit app. Press "M" (for node mapping or node palette), scroll down and see if there's any node with unknown node texture. Missing node type definitions are also printed to stderr which you can see in the Terminal. These have to be added to blocks.csv.

Each row corresponds to a node type, and each coloumn corresponds to a file format or Minetest game+mod combination. So far it has the following coloumns:
- 1st is a canonical, translatable name, shown in the editor (please only report typos and bad translations with these)
- 2nd is a BlockID, used by Minecraft Schematic files and other formats without node names (only import uses this, like 11=lava)
- 3rd is now a BlockName, used by Sponge Schematic files (only import uses this, like "minecraft:cobblestone", not filled up entirely as of yet)
- 4th is a biome specific name, the Lua mod can generate these, should be no probs here (like "biome:node_stone")
- 5th is a mapgen alias, likewise, Lua mod generates these, should be no probs (like "mapgen_cobble")
- 6th is the Mineclone2 name, this is the most up-to-date and fully filled coloumn (like "mcl_core:cobble")
- 7th is the Minetest Game name, this needs some checking and fixing (like "default:cobble")

I'm looking for testers who help fill up and fix the 3rd and 7th coloumns, and help checking if the 4th, 5th and 6th coloumns are correct. New coloumns for other MT games are also welcome! The 7th coloumn (MTG name) has the MCL2 name in many places, simply because the default game has much less node types than MCL2. These should be replaced by a name used by the corresponding mod which is loadable under MTG (for example instead of "mcl_core:darkwood" there should be "moretrees:oak_dark" or something).

Cheers,
bzt

User avatar
texmex
Member
Posts: 1752
Joined: Mon Jul 11, 2016 21:08
GitHub: tacotexmex
In-game: tacotexmex

Re: MTS Editor

by texmex » Post

Hotdang, you’re on fire bzt! This is a grand contribution to MT. I have to check it out for real now.
Mods | Support Mesehub: bc1qluuests9rxmlnvpjrhsnyjg9ucwy6z3r0y3srw

bzt
Member
Posts: 79
Joined: Tue Sep 24, 2019 14:26

Re: MTS Editor

by bzt » Post

Thanks @texmex! I know nothing about grand contribution, I've just created a tool to import schematics into Minetest, because my older boy was complaining that there are not enough structures and he searched for free schematics online which I couldn't load at the time. Once the basics were done, adding more input formats was quite straightforward (he has also found a T-Rex in VOX format... What's with kids and dinosaurs?). Since I had troubles with importing rotation info, it was quite obvious to provide a GUI too to allow modifications.

I wrote this for my boys (originally as a Xmas gift), and it was a huge success so the project already served its purpose :-) I figured if they liked it that much, maybe others will too, so I made it available under FOSS and shared it with you. That's all!

I think the real kudos goes to the Minetest developers and to Wuzzy for MCL2, I simply can't tell how happy it made my boys to play this game! Thank you!

Cheers,
bzt

bzt
Member
Posts: 79
Joined: Tue Sep 24, 2019 14:26

Re: MTS Editor

by bzt » Post

Hi All,

It occoured to me that the workflow is quite a one-wayed: you can import almost anything and save it as MTS. But there's no way to export MTS files to third-party tools. So I've added that.

New features:
- convert to VOX files, like "./mtsedit -V minetest.mts minetest.vox"
- minor fixes in VOX parser
- fixed node rotations when you rotate the entire structure

Please note that VOX file is a voxel image format and not a schematic format. This means it can only store colors, nothing else. Node names, rotation info, probabilities will all be lost. But you'll be able to load Minetest structures in Goxel and Magicavoxel if you want. You can open VOX files with MTSEdit, and it will look up nodes by best color match. If that's incorrect, then you can easily flood fill areas with a different node. Probabilities will be recalculated to a reasonable default, but you have to set node rotations manually.

Cheers,
bzt

User avatar
Wuzzy
Member
Posts: 3988
Joined: Mon Sep 24, 2012 15:01
GitHub: Wuzzy2
IRC: Wuzzy
In-game: Wuzzy

Re: MTS Editor

by Wuzzy » Post

Intereting tool. It's nice to look up a schematic without opening Minetest and it seems useful to fix SMALL mistakes. However, larger edits are very inconvenient and time-consuming, I think [worldedit] + [schemedit] are much more efficient methods of editing.

I like the preview image feature.

The program fails if your schematic has a lot of nodes that the program doesn't know yet. It seems there is some kind of import feature, but I'm too lazy to use it. It's too much additional workload. Anyway, I think I'll keep this program.

Problems I found with the program:

Bugs:
- It becomes very slow for large schematics
- The load file browser closes whenever you change directories
- param2 only ranges from 0-31, not 0-255
- Rotating the schematic overrides param2 of all nodes, irregardless of their paramtype2. This screws up all nodes that are not facedir nodes
- Unknown are never translucent and look broken when moving upwards in layers
- Deleting or adding X or Z layer does nothing
- Rotation of ladder is wrong
- Window title does not update when loading a different schematic from the load menu
- Many node preview images are incorrect
- default:snow is confused with default:snowblock
- Rail can be rotated (it is not rotatable, param2 is meaningless)

Bad UI/UX:
- No way to see or set node probability
- It's not clear what the node's param2 value is
- Can't start program with no file selected
- I find it very tedious to move the mouse. Even at 200% zoom I often misclick. Maybe this is because the mouse cursor is invisible
- Editing large parts of the schematic also feels quite tedious. It's not fun. I think [worldedit] + [schemedit] is still my favourite method of editing schematics

Other stuff:
- The preview looks kinda ugly, the outlines are pretty jagged but its better than nothing.
- Shading of preview is too extreme. I would recommend flat shading for simplicity

Mising features:
- Toggle force node placement
- Per-node probability
- “New file” button
- Layer probability does not show raw value, which leads to loss of precision
- Display/set schematic boundaries
- Node pipette

Nice to have:
- Add toggable node overlays:
-- param2: Display param2 number on all nodes (except 0)
-- probability: Display probability number on all nodes (except 100%)
- A "full preview" mode. If enabled, the full schematic is visible at once.
- A "random preview" mode. Same as full preview, but with node/layer probability applied. Would be very useful to test out the randomness of your schematic. Due to the nature of this mode, this might only be a “view-only” mode, i.e. no editing possible

Now some comments about your documentation:
Just for the records, because the Minetest wiki is very poor on documentation, I've also created a detailed description of the MTS file format (still incomplete).
I have copied over most of your text to https://dev.minetest.net/Minetest_Schematic_File_Format and adapted it accordingly. Hopefully, I made no mistakes. I really hope a core dev will come along an proofread it.

You can request a wiki account here: viewtopic.php?f=3&t=10473.
MTSEdit can save files with those
names, such as `biome:node_stone`. When reading these schematics, block types that start with "biome:" should be handled indirectly
by looking up the property of the biome where the schematics is placed. This is not supported by the Minetest Engine yet, but Lua
modules can implement this easily.
I recommend against using the prefix “biome:” for biome-specific nodes, it's likely to cause a name collision sooner or later. How about “_mtsedit_biome:” instead?
Rotation information is stored in `param2`. This is the worst documented part of the MTS files.
That's because the documentation of param2 is in lua_api.txt.

param2 is between 0-255 and its meaning depends on the node definition (paramtype2). Look for “param2” and “paramtype2” in lua_api.txt. It's not only for rotation. And yes, you need to support the full range 0-255 of param2, not only 0-31. Also, param2 is usually displayed in decimal form, not hexadecimal.

If you like to play around with param2 and see how it works, try out my DevTest game (viewtopic.php?f=50&t=24030). Enable debug mode, place the various test nodes and use the param2 tool on them and see what happens.
Normally MTS files can't store ground level information. MTSEdit solves this by setting `param2` to 0x20 for air blocks on
ground level. This is not a perfect solution (the ground level might have no air blocks), but at least it does not interfere
with the Minetest Engine.
That's a really weird hack. Why does ground level even need to be stored?
Anyway: This hack is unreliable for obiouvs reasons. I would save the ground level somewhere else. Maybe the node name table can be abused for this. Adding a fake node name like “_mtsedit_ground:X” with X being the ground level. Minetest will discard is since this node is not actually being placed, but MTSEdit can read it just fine. It should also be possible to set no ground level at all.
But in general, I dislike introducing any hacks like that.
My creations. I gladly accept bitcoins: 17fsUywHxeMHKG41UFfu34F1rAxZcrVoqH

User avatar
Wuzzy
Member
Posts: 3988
Joined: Mon Sep 24, 2012 15:01
GitHub: Wuzzy2
IRC: Wuzzy
In-game: Wuzzy

Re: MTS Editor

by Wuzzy » Post

Missing MCL2 nodes:

- Corner stairs
- Mushroom blocks
- Cauldron variants (different water heights)
- Damaged anvils
- Many redstone trails (but this is VERY overkill, there's hundreds of them)
- Upper part of doublehigh plants
- Different piston/dropper/dispenser orientated nodes

Incorrect node textures (MCL2):
- Bedrock
- Wooden slab (most wood types)
- Wooden stair (most wood types)
- Chorus Flower
- Chorus Plant Stem
- Dead Chorus Flower
- Cracked stone bricks (+slab, +double slab, +stair, +infested)
- Mushroom stem
- All-faces mushroom stem
- Infested nodes
- Poppy, red tulip, rose bush (uses MTG rose textures)
- Powered Redstone spot (unknown node)
- Powered/nonpowered Redstone trail (unknown node)
- Quartz block, slab, stair, double slab
- Redstone block
- Redstone ore
- Redstone lamp
- Carved sandstone
- Carved stone brick
- Cracked stone brick
- Stone
- Stone brick wall
- Stone slab/stair
- Realm barrier (special MCL2 node, must be tinted purple)
- Void (special MCL2 node)
My creations. I gladly accept bitcoins: 17fsUywHxeMHKG41UFfu34F1rAxZcrVoqH

bzt
Member
Posts: 79
Joined: Tue Sep 24, 2019 14:26

Re: MTS Editor

by bzt » Post

Hi Wuzzy,

First of all, thank you for checking out, and thank you very much for your translation fixes! I've merged them, I'll review your suggestions here and commit a new version soon.
Wuzzy wrote:Intereting tool. It's nice to look up a schematic without opening Minetest and it seems useful to fix SMALL mistakes. However, larger edits are very inconvenient and time-consuming, I think [worldedit] + [schemedit] are much more efficient methods of editing.
Yes, exactly. It's main purpose is to convert other formats into MTS. The GUI editor is just an extra for small fixes (mostly to correct import problems), it was never intend to replace worldedit + schemedit.
Wuzzy wrote:I like the preview image feature.
Thanks!
Wuzzy wrote:The program fails if your schematic has a lot of nodes that the program doesn't know yet. It seems there is some kind of import feature, but I'm too lazy to use it. It's too much additional workload. Anyway, I think I'll keep this program.
What do you mean "program fails"? Is it throwing some kind of errors? I made it in a way that unknown nodes are added to the node palette automatically, so that you can use those without a technical name translation rule (obviously there's no node image for them and you can't change the node mapping in lack of translation rules).
Wuzzy wrote:Problems I found with the program:

Bugs:
- It becomes very slow for large schematics
Could be. I haven't optimized the GUI really, which means it does not cull nodes when it generates the surface caches (one for below, one for above and one for the currently edited layer). Good news is, once you have those caches, it works smoothly.
Wuzzy wrote:- The load file browser closes whenever you change directories
Never noticed that. I'll definitely take a closer look and see if I can reproduce this. You should only click once, double-click has a different handler (but if it closes the file browser it must be fixed).
Wuzzy wrote:- param2 only ranges from 0-31, not 0-255
That's intentional. MapNode always masks getParam2, and the largest value is 31.
Wuzzy wrote:- Rotating the schematic overrides param2 of all nodes, irregardless of their paramtype2. This screws up all nodes that are not facedir nodes
This is a known issue. You can change param2 for those nodes with [shift]+[left] or [shift]+[right]. There's no way of knowing a node's paramtype2 outside of the game, and what's worse, there's no consistency among mods. For example "mcl_core:chest" could have one paramtype2, and it's corresponding "default:chest" could have something different (just an example).
Wuzzy wrote:- Unknown are never translucent and look broken when moving upwards in layers
That's right. I have tried translucent "unknown node" image, and it was even worse, ugly as hell :-(
Wuzzy wrote:- Deleting or adding X or Z layer does nothing
Are you sure? Were you at the middle of a structure or at the side? Those use the current cursor position, so I suggest to use keyboard shortcuts and not the icons on the left. This is definitely an UI issue, I'll have to figure out something.
Wuzzy wrote:- Rotation of ladder is wrong
Thanks. I'll have to replace the node image.
Wuzzy wrote:- Window title does not update when loading a different schematic from the load menu
Thanks, this is a bug, I'll fix.
Wuzzy wrote:- Many node preview images are incorrect
Incorrect how? Could you ellaborate please so that I can fix the preview?
Wuzzy wrote:- default:snow is confused with default:snowblock
Yeah, could be. Getting the correct node for all game+mod variants is difficult. I'll fix.
Wuzzy wrote:- Rail can be rotated (it is not rotatable, param2 is meaningless)
In general the editor does not know how a node's param2 is interpreted, it just sets param2 value. But if param2 is meaningless for the engine, then this isn't an issue I suppose.
Wuzzy wrote:Bad UI/UX:
- No way to see or set node probability
That's right. Node probability is not changeable for now. This is a missing feature.
Wuzzy wrote:- It's not clear what the node's param2 value is
Exactly. I don't know either. So the editor allows to set it's value, and might display the result incorrectly. Here I though it would be better to allow changing of param2 and saving into files even if some displayed incorrectly in the editor, rather than disallow (previous versions only allowed param2 values that had node images, I've removed this constraint).
Wuzzy wrote:- Can't start program with no file selected
This is not a bug, it's a feature :-) The editor is primarily a command line tool, so you have to run it in a Terminal. Without arguments, it displays all the options. Providing a GUI editor is just its secondary goal.
Wuzzy wrote:- I find it very tedious to move the mouse. Even at 200% zoom I often misclick. Maybe this is because the mouse cursor is invisible
That's correct, zooming is done in run-time, therefore it might lag when you use big structures. There's a simple solution, press [A]. This will toggle the display of below and above layers, and scaling only the current layer is pretty fast even for large structures (there's an X and Z culling, and by turning off below and above, you eliminate the need of iterating through Y). First version displayed the mouse cursor, and that was just annoying, I couldn't see what's the node beneath, that's why I turned it off.
Wuzzy wrote:- Editing large parts of the schematic also feels quite tedious. It's not fun. I think [worldedit] + [schemedit] is still my favourite method of editing schematics
This editor's main goal is to import other schematic formats, and allow you to do small fixes. However if you have some ideas how to make the UI better, I'm open to suggestions.
Wuzzy wrote:Other stuff:
- The preview looks kinda ugly, the outlines are pretty jagged but its better than nothing.
- Shading of preview is too extreme. I would recommend flat shading for simplicity
Preview uses the simplest orthographic projection. Shading is the only thing that provides some sense of depth. In the first version there was no shading at all, and I was unable to tell from the preview which part of the structure is where. I've noticed this in mtsconv, and I've implemented a simple shading in mtsedit too.
Wuzzy wrote:Mising features:
- Toggle force node placement
That's not missing. You can toggle force node placement for non-air nodes with [D] (both [F] and [P] shortcut was already taken). For air nodes, the force placement bit is automatically calculated by detecting rooms in the structure.
Wuzzy wrote:- Per-node probability
Yep, this is missing.
Wuzzy wrote:- “New file” button
Yes.
Wuzzy wrote:- Layer probability does not show raw value, which leads to loss of precision
Yeah, I was thinking about this. But my boys had issues with raw values, so I decided to display percentage. The value changed and stored in MTS files is correct though, full precision, it's only converted to percentage on screen. I can revert to raw value in no time.
Wuzzy wrote:- Display/set schematic boundaries
This is most definitely never gonna happen. There's no such thing schematic boundaries. You are free to edit anywhere, and the bounding box is calculated automatically when you save the structure.
Wuzzy wrote:- Node pipette
This is implemented when you delete a node with [Backspace]. You can place it back right away with [Space], but having a separate pipette tool is a good idea!
Wuzzy wrote:Nice to have:
- Add toggable node overlays:
-- param2: Display param2 number on all nodes (except 0)
Good idea
Wuzzy wrote:-- probability: Display probability number on all nodes (except 100%)
I think I'll postpone this as you can't edit probability per node as of yet.
Wuzzy wrote:- A "full preview" mode. If enabled, the full schematic is visible at once.
You can zoom out, but having a non-editable full preview for the entire structure sounds good.
Wuzzy wrote:- A "random preview" mode. Same as full preview, but with node/layer probability applied. Would be very useful to test out the randomness of your schematic. Due to the nature of this mode, this might only be a “view-only” mode, i.e. no editing possible
I agree this would be nice, however I'm afraid this would made the interface too complex.
Wuzzy wrote:Now some comments about your documentation:

I have copied over most of your text to https://dev.minetest.net/Minetest_Schematic_File_Format and adapted it accordingly. Hopefully, I made no mistakes. I really hope a core dev will come along an proofread it.
You are awesome man! This is great!
Wuzzy wrote:You can request a wiki account here: viewtopic.php?f=3&t=10473.
Thanks!
Wuzzy wrote:I recommend against using the prefix “biome:” for biome-specific nodes, it's likely to cause a name collision sooner or later. How about “_mtsedit_biome:” instead?
No. Biomes are Minetest engine entities along with their properties, biome:node_top has nothing to do with my editor.
Wuzzy wrote:That's because the documentation of param2 is in lua_api.txt.
Not quite. The lua_api.txt has some more info, granted, but I think this should be documented properly. I've also read lots of forum topics about facedir, this seems to be a constant issue unfortunately.
Wuzzy wrote:param2 is between 0-255 and its meaning depends on the node definition (paramtype2). Look for “param2” and “paramtype2” in lua_api.txt. It's not only for rotation. And yes, you need to support the full range 0-255 of param2, not only 0-31. Also, param2 is usually displayed in decimal form, not hexadecimal.
Supporting param2 for non-rotational types is out of the scope I'm afraid. I've talked about this with @Sokomine. Besides, MapNode masks param2 to 0-31, so higher values are only relevant inside the engine, but thankfully not in schematic files.
Wuzzy wrote:If you like to play around with param2 and see how it works, try out my DevTest game (viewtopic.php?f=50&t=24030). Enable debug mode, place the various test nodes and use the param2 tool on them and see what happens.
This is exactly what I have done so far :-) But not with all the nodes, that would take more time than I have. :-(
Wuzzy wrote:That's a really weird hack. Why does ground level even need to be stored?
To avoid that even dirtier hacks like you've used with the igloo. Having two files for a structure is unmaintainable on the long run. This feature is needed for all structures that has underground part. Like the pyramid, well, etc. If you are in a doubt, read the viewtopic.php?f=7&t=23858 topic, several modders agree this is needed, and you can also see other hacks to this missing feature.
Wuzzy wrote:Anyway: This hack is unreliable for obiouvs reasons. I would save the ground level somewhere else.
Yeah, the best would be to store 4 ints in the header: width, height, depth and ground.
Wuzzy wrote:Maybe the node name table can be abused for this. Adding a fake node name like “_mtsedit_ground:X” with X being the ground level. Minetest will discard is since this node is not actually being placed, but MTSEdit can read it just fine. It should also be possible to set no ground level at all.
Not good, the MT engine would complain about the node, I've tried. If nothing else, it would display a red error message about it's texture. Since MapNode uses "getParam2() & 0x1F" in the code, we are free to use param2 bit for this, no errors reported (but I agree this is not an optimal solution).
Wuzzy wrote:But in general, I dislike introducing any hacks like that.
I couldn't agree more. Ground level should be added to the MTS header, but that would break compatibility with existing files, so this change should bump the file version.

Cheers,
bzt

User avatar
Wuzzy
Member
Posts: 3988
Joined: Mon Sep 24, 2012 15:01
GitHub: Wuzzy2
IRC: Wuzzy
In-game: Wuzzy

Re: MTS Editor

by Wuzzy » Post

What do you mean "program fails"?
Don't worry, no crash or anything. I just mean the concept fails / hard to edit because of tons of unknown nodes.
Since MapNode uses "getParam2() & 0x1F" in the code, we are free to use param2 bit for this, no errors reported (but I agree this is not an optimal solution).
Why do you still believe that param2 is limited to 0-31? That's most definitely wrong! For example, for paramtype2="glasslikeliquidlevel" or "leveled" or "degrotate", the param2 can can have much larger meaningful values. Also for the “colored” variants.

Also, lua_api.txt tells you exactly how param2 works for facedir and most other drawtypes. You just didn't look hard enough, I suppose. But I admit that wallmounted and liquid are still missing. Note that wallmounted uses different numbers than facedir.

I agree that supporting non-rotational paramtype2's is overkill. facedir and wallmounted are good enough for a start.
Still, you should drop the arbitrary 0-31 restriction for compability reasons. Just teach your node rendering routines to ignore large values to keep it simple.
My creations. I gladly accept bitcoins: 17fsUywHxeMHKG41UFfu34F1rAxZcrVoqH

bzt
Member
Posts: 79
Joined: Tue Sep 24, 2019 14:26

Re: MTS Editor

by bzt » Post

Wuzzy wrote:Don't worry, no crash or anything. I just mean the concept fails / hard to edit because of tons of unknown nodes.
Ah, okay :-) Yes, that must be fixed by defining all the block types.
Wuzzy wrote:I agree that supporting non-rotational paramtype2's is overkill. facedir and wallmounted are good enough for a start.
Still, you should drop the arbitrary 0-31 restriction for compability reasons. Just teach your node rendering routines to ignore large values to keep it simple.
The problem is, the editor doesn't know about facedir or wallmounted. It's just displays icons for ids. There's absolutely no rendering routine either. Originally I had, but I managed to remove it. My goal was to make the editor flexible, so that you can alter it just by modifying its data. Right now there's one row for each node in the csv. The editor uses that, and loads a png for each node. Then it simply displays a 32x32 icon from the png at offset (0, (param2*32)%(png height)). This way you can define different icons for different param2 values, and the editor doesn't need to know (could be icons for different rotations or icons with different water levels in cauldrons etc.)

Btw, sorry about the delay, I had other projects to attend to. But I finally got time for MTSEdit, so here's a list:
  • Fixed German translation (big big thanks to Wuzzy)
  • Loading window does not disappear when clicked on a directory, only if clicked on an mts file
  • Window title displays the filename correctly
  • Rotating code has been changed, now if you rotate or flip the entire structure, only the lowest 2 bits changed in param2. This works great for normal orientation, should work for wallmount, and hopefully doesn't mess up other special param2 values too much
  • Param2 now ranges from 0-255
  • I've added a rotate flag for the nodes, which should indicate if the editor is supposed to change param2 values on rotation, but it's not loaded from the csv as of yet
  • Param1 is numerically shown for the current node
  • The raw value for the level is shown if you hover above the level indicator (which only shows level relative to the ground)
  • Raw value for layer probability also shown when you hover over the indicator (but I've kept the percentage by default)
  • Node pipette implemented, if you press [N], then the node under the cursor is added to the palette if it's not already there
  • I've reviewed the preview code, and concluded that there's nothing wrong with it, the jagged outlines are simply caused by low-quality icons. This can be easily fixed by replacing the pngs with better looking ones.
Cheers,
bzt

User avatar
Wuzzy
Member
Posts: 3988
Joined: Mon Sep 24, 2012 15:01
GitHub: Wuzzy2
IRC: Wuzzy
In-game: Wuzzy

Re: MTS Editor

by Wuzzy » Post

Nice!
My creations. I gladly accept bitcoins: 17fsUywHxeMHKG41UFfu34F1rAxZcrVoqH

Marc37_300
New member
Posts: 3
Joined: Tue Jul 07, 2020 09:49

Re: MTS Editor

by Marc37_300 » Post

Great Work !!

Post Reply

Who is online

Users browsing this forum: No registered users and 0 guests