True. The main advantage of zip is that everyone has it. For the file sizes we’re talking about speed is indeed not an important factor, but level of compression and memory usage are, making 7z the better choice where matters (IMO).
Interesting detail though: h3m files take actually less space than in archived format, whichever that might be (zip, 7z, etc). Sorry if this is a known and easily explainable fact for the coders, but for me it was quite surprising to notice. I’ve seen file types for which the compression was almost useless in terms of space saving (less than 1%), but never cases where the “compressed” result was taking more space.
Do we really need compression?
1)IIRC currently ~90% of image loading time is spent on lod decompression. Uncompressed data should be much faster in use - decompressing it is really slow even for “fast” formats.
2)What are you going to compress? PNG’s? MP3? Video? All of them are already compressed. Json\python files are the only ones that can be notably compressed. And all of them are be much smaller then images\music\video so there won’t be any notable decrease in mod size.
BTW - just checked .deb packages from Wesnoth - compressed data is ~75% in size. Not much for disc space gain.
Reason why I proposed .zip is single file for mods - accessing over 9000 files scattered on HDD is really slow.
H3M and H3C are archives with one file in it - try to change its extension on .zip
The main idea was to put map in single file. About compression, let mapmakers deside what is better small file or fast map loading. Really useful will be to have ultra fast access to map header (f.e. move map header to mod config and dont compress this file) to allow quick map list loading. Load time of map private graphics will not be a “bottleneck” - most time consuming is loading common resources.
I vote to keep the files not compressed itself (no bzipping gzipping etc.)
and keep all files for one mod/map/anything_multifile in single 7z package
why?
One package per module is easier to mantain for user (and simple enough for modder)
7z is free format, is somewhat popular (definately more than arc or lha)
7z has high compression ratio (which is friendly for both modder and user)
7z is optimised for unpacking (you pack a few times but unpack thousand of times)
homm3 use flat raster graphic in low resolution so quality is important
so the modder doesn’t have to search supported loseless format but only put uncompressed file (eg. Bmp) into archive
this also cut out discussion on which loseless compression is best and makes using gif deprecated (gif is patent-ware so evil)
we can use package as analogy to lod file and even make lod and 7z interchangable
PS: please implement a feature to be at least a bit compatible with era2
for begin supporting resources from wog as a mod to era and make pac file extension understand as lod
this way we can leave off dependency on wog installer which is function-ugly
perhaps we can derivate later some elements from era mod system too (so treating /mods/anything/data as /data and autoload lods from it also use era priority sysem for overrides)
for now enough is to add /mods/wog/data/homm35.pac as standard lod so if user has oryginal lod files and era installed it understand to load files not in standard lod from this pac/lod
this way we will be compatible with both wog resources from wog installer or standard era mod
Sorry for double post but now i use imageless browser and edit button doesn’t have alt text
we can leave loose file folders for modders for testing, and by same time encourage modders to use archive as default publicate method
we can also add test mode in which there are no data-valid tests but doesn’t allow to connect to non-testmode servers
we can reserve some mod system features only to test mode (eg. Era modsystem compability, having different mod versions on connected clients, use of loose file overrides, allowing to cheat in multiplayer, cheatcommands adding etc.)
this way modder can do whatever evil on testing, but have to be gently on public stage, also we can ignore use of some testmode features in non-testmode instead of asserting theres none so public-mod-package can still be tested in testmode but eg. cheatcommands will be disabled in normal play
Engine should have more (than current) unified interface for map objects. (f.e. do not distinguish VisitableOPH, VisitableOPW). These unified base classes are exported to Python side. *Hero, Town need special exported classes, but all others probably not. F.e.
A pickable object it simply deleted after visit.
Not visitable object has OnVisit event but it will never fire
Every visitable object may get guard and become Armed
Every visitable object may be altered to support Garrison on-the-fly.*
behavior of existing objects can be altered only with event subscription. This allows two mods to alter same class independently
New objects can be created with the help of subclassing or events (new object is defined in config; in fact new class is implicitly defined by engine and then altered with with event subscription).
9.2 Identification
All objects are defined by string identifiers (ID=class name, Subtype). String IDs can be mapped to h3 numeric ID, Subtype via config (they are constans in OH3, so dynamic allocation is impossible).
String ID, Subtype are namespaced with mod name.
AdventureObject clases are accessible via global dictionary, mantained by engine.
Subtypes can be defined only in config.
Numeric ID,Subtype can be mapped to any combination of string ID,Subtype. *Distinct classes can handle objects with same ID and different SubID. F.e. WoG objects id 63 *
Do we really need this? The best way IMO is to create string ID’s for all original objects so any access to them can be done via this ID’s instead of memorizing all that magic numbers from H3.
As I said earlier - it’s OK to allow access to numeric ID’s but strings should be the “main” way to access something.
I thought that we decided not to use namespaces - [forum.vcmi.eu/t/modding-system-discussion/451/39)
If modder uses object from another mod he must mark it as dependency or he won’t have access to strings from that mod. As result there won’t be conflicts in ID’s between two unrelated mods - mod A doesn’t have access to strings from mod B and vice versa.
Wow … 5 pages. I’m really sorry for not reading it all but if I can I will try to add something maybe new into this deabate.
IMHO whatever language will be the default one for mods scripts basic solution for modding should be txt (jason) files with configuration options like hp for creatures , their special abilities , hero specials, town setups, what a certain skill do etc etc.
That includes adding new cratures, towns just as new position in config file , defining it and adding a link to it’s animation. Thorugh config files we should also be able to remove game features (skills, towns, creatures etc. )
Config files are something that even a non programer can do so basic and advanced modding should be possible to be done with it. Only very very fancy things should be something that people would have to use scripts for.
Numeric IDs needed only for compatibility. I agreed that string IDs should be “main” .
How to design map using both two such mods? (Def options in map also use string IDs to identify objects) Map scripts must have access to ALL objects in linked mods.
And simply there may mod C (not a map) depending on A&B.
One thing I would love to see is implementing the “view battlefield configuration” for each square clicked on adventure map. There are external tools made by chinese and russians allowing this, but we need to open outside game. I am surprised 3DO did not think about, as it is a major feature in battles, terrain configuration can change drastically issues. And we know that a fine strategist should be able to choose WHERE to fight, and plan the outcome.
Probably it could be tied to internal options, like we click on kingdom overview, activate option, then right click on adventure map, then disable next, and get usual info about squares.
The program should show position of battlefield obstacles in the grid.
The problem is that we don’t know the algorithm that places these obstacles. Sure, we can try lookup tables, but what happens when there are new battlefields or new obstacles added?
I think same algorithm is used for every map regardless each square. Such problem was already solved by PhOMM in russian forums, he released a tool which will show every square corresponding obstacles. I will contact him if any of you is interested. Similar tool is available in chinese forums, they use it constantly when designing new maps.
There are not new battlefields configurations, only backgrounds (pcx). I don’t know in VCMI, but in WoG, if we want to add obstacles manually, usually we clean the BF before, then add.
Is there any reason to have exactly same battlefields as in H3? Implementing similar algorithm would be easy but creating same algorithm is almost impossible IMO.
Wow, this post is long. I won’t read the entire post, sorry.
But, I have a suggestion for the modding system. Recently, I found this (FIFE Engine) game engine that already has python support and it’s written in C++. They use SWIG for python binding, You should check it out.
Also, a game based on it (Unknown Horizons) is using YAML to describe the objects in the game. That might also be of an interest to you.
Hope this will help.
Later Edit: I wasn’t suggesting adopting their engine, just implement their system of modding.
Warmonger is right, compatibility is a must, there are few chances someone starts to create new top maps for VCMI, it must improve playability with previous ones.
I contacted PhoMM and sent him here, to give infos about his tool. He made a special editor where we can see each square configuration.
I think we should keep the same BF as in table only for classic terrain or even only for classic (H3M) maps.
If you add new terrain, such TR don’t have to have similair BF as original. If we depend on map format it is even easier (but converting could be a problem).
If mods adds new obstacle types for classical TR the map should trigger if use classic or new set (new set = new algorithm) for each terrain independently.
