I'm suggesting if the tile specified in the pack is invalid, that it gets replaced by the Clear of whatever theater it is currently, or whatever theater it's specified to convert into.
This would be specifically for maps that were corrupted, or converted impromperly, or a tileset changed later. It would be a case where the user wouldn't know which tiles are bad or where they are and thus no rules could be made for them, it would have to be auto-corrected.
The tool doesn't take any terrain INI file like temperat.ini as input to validate whether a tile is missing or a pack has invalid tiles. IsoMapPack5 contains a set of numbers. A profile supplies what number changes to what other number. Any number that is not specified is not touched. Already where there are cases in vanilla theater change like temperate to snow or snow to temperate etc., the provided profiles already gives the closest matching tile if there is no 1 to 1 match or even clear tile on complete mismatch.
Say in case, someone wants to convert a mod map which has more tiles added than the vanilla game but has not changed any vanilla tile indices, users could create a simple one line profile that can give a range higher than the tiles index that vanilla uses and convert all of those to clear tile. But if the mod has changed tile indices then a generic profile would do no good.
If a tileset is changed altering tile indices after creating a map, then all the tile indices that come after that tileset also get affected. A profile could be created to correct such cases. Once you look at the documentation which comes with examples and also at the provided profiles, it is not that difficult to create your own profiles. QUICK_EDIT
I'm testing a simple conversion between a few tiles and I'm already stumped. I get the following error, and I've no idea why.
Code:
Error encountered. Message: The requested operation requires elevation
EDIT: Jesus Christ, it took me 20 minutes to realize it meant elevated user access instead of map/tile elevation. Now I feel dumb _________________ QUICK_EDIT
Changes 2019-12-07:
- Object rules can have multiple comma separated replacement values, one of which will be chosen randomly for substitution.
Note: Profiles for building replacement should be careful of the foundation sizes. Replacing with a bigger building could cause problems.
@Bittah Commander: Examples -
Code:
[ObjectRules]
TREE04|TREE04,,TREE16,TREE17 ; Empty entry will get a chance to remove
TREE08 ; Will remove TREE08
NEGLAMP|CABHUT,TSTLAMP,TSTLAMP,, ; Repeats will have more chance
@Starkku: Glanced at the updates at github repository. Of the significant changes, your out of bound feature seems flawed. When the maps are compressed for IsoMapPack5, height level 0 clear tiles are removed, resulting in the number of tiles being less than the number of cells in the map. For such cases, your feature could remove all objects/overlays from non-present height level 0 tile cells, making it unsafe to use. The repo also doesn't contain my previous changes after 2018-06-24 upto 2018-11-25. Couldn't spare time for correction and merging, so branched from an earlier commit.
@Starkku: Glanced at the updates at github repository. Of the significant changes, your out of bound feature seems flawed. When the maps are compressed for IsoMapPack5, height level 0 clear tiles are removed, resulting in the number of tiles being less than the number of cells in the map. For such cases, your feature could remove all objects/overlays from non-present height level 0 tile cells, making it unsafe to use.
Yeah this was an oversight in the logic. I went and changed it so that it checks this purely on coordinate-basis and does not care about tiles at all.
E1 Elite wrote:
The repo also doesn't contain my previous changes after 2018-06-24 upto 2018-11-25. Couldn't spare time for correction and merging, so branched from an earlier commit.
This is something I should've addressed a while ago already, but my attention has been elsewhere and it is also why I have not updated the downloads on the first page for a long time.
To be direct, I am not a huge fan of how many of the things mentioned in this post are implemented and I am unlikely to merge them as is. Particularly the UI change looks sloppy and I'd rather look for a solution that looks nice for all DPI settings. The ability to alter overlay frame data is nice, will probably implement that alongside some code refactoring (on a related note, is there any particular reason why ModifyOverlayRules is its own thing rather an extension on OverlayRules?). The profile edits I have not gone through yet in detail but I assume they are fine too. The rest seems like mostly superfluous or even pointless feature creep, the raw data dumping in particular sticks out as something entirely out of the scope of this tool.
Once the codebase and the missing features are sorted out, I would also appreciate if any future contributions from you (or anyone else for that matter) come through GitHub (look up how pull requests work) instead of being posted here. It was barely excusable when version control wasn't involved on your end and understandable in case of C&C Map Renderer where the original author is absent for all intents and purposes, but not here any longer.
Also try to avoid those large, single commits with lots of unrelated changes bunched together. Amongst other things, makes keeping track of the changes and potentially reverting them pain in the ass. _________________ QUICK_EDIT
Raw dump and extended log feature were not requests, I coded those to learn and then shared it so that others could also benefit from it. Raw dump was helpful in analysis for me and Verlusti also found it useful. ModifyOverlayRules came up later to take input and apply it to the map. It has different set of inputs compared to Overlay rules, parsing those from the same section would have lead to complexity. UI was small for 125% DPI that I use, some text were not fully visible, if you do better, will try that.
You are free to merge as you wish at your own pace, I am not insisting, only gave reason why I had to branch out. Its been more than a year since I touched this tool. Did it now because I could finish a request by spending few minutes. It could use further improvements, bug fixes and IsoMapPack5 compression is outdated when compared to Map Renderer, that could be overhauled etc..
You have a DLL, is it open source? I had to make use of what is available in one instance instead of changing it myself. QUICK_EDIT
@Starkku: Glanced at the updates at github repository. Of the significant changes, your out of bound feature seems flawed. When the maps are compressed for IsoMapPack5, height level 0 clear tiles are removed, resulting in the number of tiles being less than the number of cells in the map. For such cases, your feature could remove all objects/overlays from non-present height level 0 tile cells, making it unsafe to use.
Yeah this was an oversight in the logic. I went and changed it so that it checks this purely on coordinate-basis and does not care about tiles at all.
Wait. I use this compression a lot. Which release is "safe" to use? _________________ QUICK_EDIT
Raw dump and extended log feature were not requests, I coded those to learn and then shared it so that others could also benefit from it. Raw dump was helpful in analysis for me and Verlusti also found it useful. ModifyOverlayRules came up later to take input and apply it to the map. It has different set of inputs compared to Overlay rules, parsing those from the same section would have lead to complexity. UI was small for 125% DPI that I use, some text were not fully visible, if you do better, will try that.
I don't deny that the extended logging and data dumping can be useful in certain circumstances. A case could be made for some sort of more verbose logging in debug mode, but I don't think the full map data logging / raw data dumping fits in. Purpose of the tool is manipulation of map data, primarily for the objective of map conversion from one game/mod to another and to apply optimizations and fixes etc. SectionRules already kind of skews this a bit since it ventures into generic INI structure manipulation, and I have purposedly kept trigger manipulation out of the scope even though few use cases have since cropped up. I wouldn't mind separate tools based on my code doing other things as long as their release abides by the license.
As for ModifyOverlays, increased complexity is a fair concern. However I'd rather take slight increase in complexity than a massive increase in redundancy. The rule parsing code is a mess which I aim to address regardless. I don't think adding a coordinate filter, potentially to both tile and overlay rules, that is checked before anything else is out of the question, but I do wonder if it'll lead to feature creep towards stuff that traditionally belongs to the realm of full-fledged map editors.
E1Elite wrote:
You are free to merge as you wish at your own pace, I am not insisting, only gave reason why I had to branch out. Its been more than a year since I touched this tool. Did it now because I could finish a request by spending few minutes. It could use further improvements, bug fixes and IsoMapPack5 compression is outdated when compared to Map Renderer, that could be overhauled etc..
Yeah I understand that, I was just likewise explaining why I have not already merged them in. Also in case it wasn't clear, I wasn't trying to sound ungrateful for the contributions or help. I actually do appreciate the principle of others stepping up and filling in where I could not, it is just a territory that often comes with clashing ideas and standards. And even if I do not directly end up using your implementation, you've at the very least laid the groundwork for these things to me and I am grateful for that.
E1Elite wrote:
You have a DLL, is it open source? I had to make use of what is available in one instance instead of changing it myself.
The utility library DLL is currently not open source. Might change in the future but that'll be left for me to judge. Feel free to point out what part specifically would have necessiated alterations to the library code, though.
Crimsonum wrote:
Wait. I use this compression a lot. Which release is "safe" to use?
No binary distribution available currently even has this problem, much less having a fix for it. It is also only a problem if you would use the 'delete objects outside bounds' option (which was added for and should purely be used to get rid of problems stemming from downsizing a map in FS / FA2 which often does not purge the object/overlay data properly) on maps that have been through the compression (including combining the two in same profile). If you do not, there's nothing to worry about. _________________ QUICK_EDIT
The raw dump and extended logging were in debug mode only earlier until I decided to share. I don't see how more logging goes against any tool's objective. It doesn't even activate without actually giving it as a parameter to the Exe. If you feel it doesn't meet the objective of the tool, that is fine with me.
For ModifyOverlays, the complexity is not for coding alone but for the user as well. The entries that are different for modify overlay and overlay rules could be interspersed in a profile under the same section. This feature tend towards the category of map editor as it can take input and insert into the map. The rule parsing for this feature was the one instance that I mentioned earlier of not having the DLL open source and had to use what was available.
@Crimsonum: IsoMapPack5 compression effort was done because of the game had an artficial restriction on the decoding size of that section. This hack makes the need of it obsolete unless you are reducing the map size by a few lines. I use the ts-patches version of the hack to compile the exe, will share if you need it. QUICK_EDIT
No, it will screw the map. Old cliff themselves have height of 4 and the new cliffs have height of 2. Whatever the old cliff tops were connected will be at earlier height and all the tiles above those height will also remain as is. QUICK_EDIT
Is the command line able to make a profile out of two unique temperate.ini files?
No. It does not create profiles at all, merely provides info to do it manually. This probably won't change, as the theater configuration INIs alone do not contain enough data to build profiles from accurately. _________________ QUICK_EDIT
MapTool version 1.1.0.0 can now be downloaded from here.
Changelog:
• OverlayRules now supports additional parameters for changing overlay frame data.
• Both TileRules and OverlayRules now support tile coordinate filters, allowing rules that only apply to tiles at specific coordinates.
• DeleteObjectsOutsideMapBounds option, deletes objects and overlays outside map's physical bounds that can sometimes be left in the data when resizing maps.
• FixTunnels option, corrects malformed tunnel data generated by map editors.
• TheaterTileOffsets feature, allows defining theater-specific offsets for tile start & end indices that apply to all TileRules.
• IsoMapPack5 sorting, ice growth manipulation and removing level 0 clear tiles are now applied even without TileRules present.
• Updates to Tiberian Sun conversion profiles.
• Better high DPI support. _________________ QUICK_EDIT
Couldn't the ice growth flag be set on all ice tiles in a map using the tile numbers, instead of the 1x1 building workaround? Unless someone modifies snow.ini, the ice tile numbers are always the same (though preferably the indexes should be customizable for mod support).
As FinalSun fails to set the ice flag on ice tiles, it will not only prevent the ice from regrowing, but it also leaves the water gaps passable (yes, units will be able to walk on the water), hence the flag should always be defined on all ice tiles. Also AFAIK ice can only spread on the special icy water tiles contained in the ice tilesets, not normal water tiles, so I don't see the purpose of not defining it. _________________ QUICK_EDIT
Ice grows on both the ice tiles and normal water tiles. Developers have programmed it to be selective and the info resides in the map rather than in the ice tiles itself. Ice growth is strategically placed like in the map nod8a for connectivity if the bridge is broken while in nod12a water grows into ice to give connectivity. Making all ice to grow is not the right approach.
I had tested ice growth on normal water in the test map. As I remember, if the ice growth marker was placed on land tiles like paved roads, it would crash the map but wouldn't crash if placed on shore tile edges. QUICK_EDIT
Interesting, I thought the ice growth would be limited to the icy water tiles in the ice sets, since maps have clearly marked ice growth areas with them instead of using just regular water. I checked nod8a and nod12a and this is the case in both (though nod8a has already preplaced ice bridges). Another example is Desolation Redux. The fact that ice grows on normal does explain why the flag is coded in IsoMapPack5, but on the other hand it makes the icy water tiles redundant.
Still, I think setting ice growth on all ice and icy water tiles is a preferable option; it's much easier for mappers, and you can still strategically limit ice growth to certain areas (icy water tiles = ice growth allowed, normal water = no ice growth allowed). _________________ QUICK_EDIT
The IsoMapPack5 rules part doesn't deal with tile ranges (Getting tile numbers from tileset is long route and restrictive).
May be the TileRules could get another override for ice growth like it already has for subtile and height overrides. Profile could look like
200-300|200-300|*|*|1 ; Ice growth could be set to 1 or 0.
It also gives flexibility if the mod changes the ice tile numbers. And it could also become selective for an area if coordinate range is supplied with Starkku's update which supports coordinate inputs. QUICK_EDIT
MapTool version 1.1.1.2 can now be downloaded from here.
Changelog for 1.1.1.0:
• Attempted to fix incorrect calculation of valid tile coordinates (used when removing objects outside map bounds) that also invariably crashed with maps of certain size.
• Valid tile coordinates are now only calculated when they are needed.
• Moved ice growth flag manipulation to TileRules, fifth value now works as override to the flag value. Old keys under IsoMapPack5 are no longer functional.
Changelog for 1.1.1.1:
• Fixed Tiberian Sun ice growth fix profile file.
• Added file extension to license file for easier opening on all operating systems.
Changelog for 1.1.1.2:
• Fixed DeleteObjectsOutsideMapBounds feature always removing every object on map if enabled. _________________ QUICK_EDIT
MapTool version 1.1.2.0 can now be downloaded from here.
• BUGFIX: OverlayRules are no longer applied recursively - only the first matching rule for each cell of overlay is applied. This is consistent with how TileRules have always worked and how OverlayRules used to work prior to version 1.1.0.0.
• BUGFIX: Program will no longer crash without an error message if it encounters invalid map tile data. Logging for these types of failures has been improved in general as well.
• Map tile data is no longer read if there are no rules or settings enabled that would change it.
If there is a genuine need for the rules to apply recursively, I could consider adding either a profile-wide toggle or a rule-specific flag that'd allow it to continue processing until it encounters a rule without it. But right now I don't see the need for either. _________________ QUICK_EDIT
MapTool version 1.1.2.1 can now be downloaded from here.
• BUGFIX: Tileset data listing no longer parses tilesets with malformed section names.
• BUGFIX: Enabling file logging for Maptool.UI will now output debug-level logging to file.
• Added command-line argument (for both executables) that enables showing debug-level logging in console or UI log textbox. _________________ QUICK_EDIT
MapTool version 2.0.0.0 can now be downloaded from here.
• BUGFIX: Fixed a bug with coordinate filter wildcards.
• BUGFIX: Fixed a bug where value ranges were being calculated incorrectly for Tile/OverlayRules in scenario where source value is a range but target value is not.
• BUGFIX: Processing log textbox now always scrolls to bottom when new text is added to it.
• NEW FEATURE: Sub-tile index conversion - two additional value ranges defined after all existing values. TileRule is not applied if tile doesn't match both source tile index values and source sub-tile index values. Defining the existing sub-tile index override takes precedence over the new target value range.
• NEW FEATURE: Upgrade filters / conversions for ObjectRules. Defined as a comma-separated list of upgrade IDs (None for empty upgrade slot, * as a wildcard to match any existing ID, including None) as a suffix to the object ID separated by +. Only applied on building objects and only up to 3 upgrade IDs are parsed and used.
• ENHANCEMENT: Program now asks if user wants to exit when attempting to close when maps are still being processed.
• ENHANCEMENT: Improved tab control handling, changing tabs is disallowed during map processing and tab automatically changes to main tab if maps are added through drag & drop.
• ENHANCEMENT: Profile & map file listboxes now contain context menu options with hotkeys. The remove / select maps buttons have been removed in favour of these.
As an additional note, the software has been relicensed from GPLv3 to GPLv2. This does not affect end-users, but opens up a possibility to use code included in the project in projects that with licenses compatible with GPLv2 but not GPLv3. _________________ QUICK_EDIT
MapTool version 2.0.0.1 can now be downloaded from here.
This is a patch to a couple of issues that were found in the initial version 2 release so far.
• BUGFIX: Tile rules are no longer skipped when sub-index rules are not defined.
• BUGFIX: Empty upgrade slots are no longer incorrectly counted as present upgrades when updating upgrades on structure object. _________________ QUICK_EDIT
MapTool version 2.0.0.2 can now be downloaded from here.
• BUGFIX: Level 0 clear tiles not defined in map tile data are now filled in when loading map tile data and consequently no longer ignored by tile conversion rules. _________________ QUICK_EDIT
MapTool version 2.0.0.3 can now be downloaded from here.
• BUGFIX: Multiple TileRules are no longer applied on a single map tile, only the first matching rule is now used much like in versions before v.2.0.
This is quite a serious issue that was caused by an oversight when refactoring code for version 2.0 and went unnoticed for quite a long time it seems. Apologies for any issues it may have caused for people using the tool. _________________ QUICK_EDIT
Happened to use this tool recently from my last download. Retro fixed that for couple of known bugs which I should have fixed long ago. Updated just in case somebody is still using that old version.
Note: Starkku's github version is the latest and is already updated with these bug fixes. QUICK_EDIT
MapTool version 2.0.1.0 can now be downloaded from here.
• BUGFIX: Fixed multiple parsing issues with [SectionRules]. NOTE: This includes a breaking change, = is no longer accepted as separator between old & new section / key names, need to use -> instead, this has been amended in documentation.
• BUGFIX: Fixed an issue where non-comment lines before the first section in INI file caused the program to crash.
• BUGFIX: Fixed an issue where the GUI program wouldn't let one to add maps with valid extension if the extension contained uppercase letters. _________________ QUICK_EDIT
You can post new topics in this forum You can reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum You cannot attach files in this forum You can download files in this forum
