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)
Bonus system
2.1) Introduce BonusTypeHandler responsible for handling new bonus types and config for predefined bonuses (such as names, descriptions, graphics in creature window).
This seems reasonable but only once scripts are done. Currently there would be no way to give those bonuses/spells new mechanics.
Wouldn’t you like to make map editor instead, maybe? I will probably have some free time in February so I could help. And without new map editor our mod support is almost worthless.
Tow dragon, what do you think we should use for editor GUI? Qt? Or something else?
(no - I’m not planning to work on editor. Just wondering)
Are you talking about spellbook icon or spell effect in battle? Implementing second one may be far from trivial.
I think that this should be implemented before scripts, and is needed for my scripting experiments 
[quote=“Ivan”]
Both.
I think Qt would be the best choice.
As to map editor, do you guys remember Tiled Map Editor?
It uses QT already and all basic GUI work / map handling is done. Also stuff like json export/import, just need to put VCMI-specific stuff into the framework.
My main concern about Tiled is this:
images.mapeditor.org/tiled-qt-screenshot-4.png
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.
If you want to have property window for each object in game, you probably have to write it from scratch anyway. No shortcuts here.
H5 editor has custom windows for certain objects, but also complete property tree for every object in game like in the picture.
Actually it makes it powerful, but that is thanks to game engine.
Don’t you use layers in any graphics editor? Very useful feature, but I agree not essential.
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]
I can write editor but not in C++. I`m using freepascal for GUI.
Writing GUI in Pascal will be only waste of time. It’s neither designed for GUI programming, nor elegant as a language, nor easy to connect to our existing C++ codebase.
Writing GUI in ObjPascal is much faster than on c++ (+ very fast compilation speedups development more - as I mention it`s an issue for me regarding VCMI codebase)
No connection is needed to current codebase (the only exception is RMG, but RMG can be called as separate process then will be integrated to editor)
Mod & filesystem formats are becoming stable - so no need to use c++ implementation in case of compatibility with current code.
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++ 
Biggest issue with porting is that f you’ll leave team then there won’t be anyone who can maintain the editor.
Map editor certainly will need import from H3M. So one more part from lib.
How C++ can be not fun? Only here you can get several pages long error just because of missing comma
BTW - if you really want to do it you should at least ask HotA team - I know that they have work-in-progress editor (very likely pascal). Finishing it may be easier than starting from scratch.
No, no, no, no. Just no. You need access to a lot of lib structures; there should be only one implementation of handling them (don’t repeat yoiurself!):
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.
I.
II.
There are also advantages for me to use C++ and integrate to current codebase.
s universal graphics handling (when itll be finished). Expecting full support for 32 bit RGBA. (But if may become useless for editor if will be closely linked up with SDL)III.
If Ill use C++, Ill use “native” to C::B vxWidgets but not QT or smth else. Regardless of widgetset, studying it will take some time - so not expect smth working soon.
There is no editor yet to be sure it that
Looking into wx docs right now. API is much worse than Qt. Looks more like a port of some native C library.
For example this - why should I bother with ID mapping’s?
docs.wxwidgets.org/stable/wx_helloworld.html
And this ID’s are everywhere
Excellent documentation:
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).
Hmm. Core vx is also 10mb.
Ill try building QT (there is no official binary release for mingw with gcc 47), but Im afraid it will be useless waste of time - may fail during linking in case of not enough memory.
Hosting provided by DigitalOcean