Scheduled to "after next release" Spell handling
1.1) more general configuration in “spell_info.json” as described here
1.2) full config format for mods (including graphics). This will allow to add new spells (w|o scripting only timed effects with existing bonuses)
2.1) Introduce BonusTypeHandler responsible for handling new bonus types and config for predefined bonuses (such as names, descriptions, graphics in creature window).
Look on object properties: now imagine that you’re editing not static object but town or hero which contain dozens of properties.
Layers - H3 does not have anything like that (and I don’t think that this is needed). Surface\underground “layers” are very different from this.
It is very different from what we need for H3. Perhaps forking it will be the best approach - at least we don’t have to start from scratch.
Right, Tiled map editor looks like something different than what we need. But we could probably use some code/solutions from it.
I think general editor-related stuff like object placement, movement, terrain fill, undo/redo etc. will take relatively little time to do compared to all OH3-specific things like map and object properties.
I’m not sure, they do a lot of things we don’t need. Their internal representations of things will probably be ill-suited for our purposes.
Main problem is that editor may be designed for simple property-less image objects. I doubt that editor that is also used for platformers will work for H3 maps. Using Tiled as it won’t work - from what I can see it does not allows plugins except for save\load.
Yes. For two purposes:
a) Apply filters\transforms\etc to specific part of image. Not applicable for editor.
b) To introduce some OOP-like designing. Not applicable either - map editor is already object-based (not pixel-based)
Some kind of grouping or smart selection to allow (for example) changing same property on multiple objects at once would be useful but this is far away from Tiled layers.
Some features like undo\redo ARE complex - for example restoring\removing any references to another objects may not be trivial.
On the other hand starting from scratch would also allow us to make GUI specifically tailored for our needs - certainly a good thing.
[size=59]and it looks like one more thread has been successfully derailed…[/size]
Have you actually used Qt? Compilation time is same as with c++ (obviously) but working with gui is extremely easy.
Map saving, map loading, data loading (def’s and such), probably - filesystem with mods + all data structures from lib.
Certainly you can rewrite all of this to pascal but this means time & more code to maintain.
One more issue - porting. Are you going to maintain editor (and if needed - compiler) on all other platforms (Linux distros, Mac’s)
Certainly you can make VCMI-compatible editor but editor that will be part of vcmi should be written on C++
Main issue is compilation speed. And its not as C++ problem as a problem of current VCMI codebase (to much boost, to many dependencies).
Loading and saving (to from JSON) will need nearly no code at all - JSON (de)serialization of classes is supported out of the box. Defs, lods, filesystem is not a problem (def loading already works). data structures from lib are not needed - editor requires own design.
Mac will be an issue - I don`t have a MAC to maintain for it.
Linuxes will work, I hope. I use no platform-dependent features. But its to early to talk about it.
BTW build freepascal programs with CMAKE is possible but not trivial of course. (But once configured need less maintaining than c++ - no need to put all sources to “lists”: only one file + paths to other sources/libs)
That all is just-for-fun. And my fun is pascal and not c++
You’d spend weeks recreating what’s already done. Compilation speeds are close to nothing in comparison. Our structures are perfectly suitable for editor. If writing pascal is fun for you, then ok, write something else.
Compared to Qt with its auto-generation of all glue code, built-in documentation and object-oriented API…
Problems I know about - size of QT core library (~10 Mb) plus Qt has its own version of stl (QString, QMap and so on).