Changes (2019-07-04):
- Added 32-Facing support for SHP Vehicles with SHP turrets and corrections to 8-Facing cases.
- Added parameter for modconfig.xml to disable tiberium remap for TS mods.
- Added shapes for startup location marker namely Squared, Circled, Diamond and Ellipsed with size options of 2-6.
- Generate preview pack now can use SelectedAsAbove option to inject the shapes and sizes provided for startup markers.
- Tiled position option is also adapted to use the size parameter and is made available for generate preview pack.
- Other bug fixes and UI changes.
Attachment contains a generic version, a TSClient version with the pre-set UI settings and source code.
@Bittah Commander: Attaching modconfig.xml updated with disabled tiberium remap and disabled tiberium randomization.
Awesome, 32 facings are working perfectly for turreted units now and tiberium is no longer remapable.
I noticed 2 small issues however:
Units without turrets that don't have WalkFrames=1 specified no longer have the correct facings. Could WalkFrames=1 be used as the default (or is there an option to do so)?
When I render the rsovm8.map mission, one of the gunboats near the top-right corner of the map appears like you see in the image below. Apparently the gunboat's shadow is being drawn over the unit for some reason, but even though there are several other gunboats with the same facing on the map, all other gunboats are properly drawn over their shadow instead of the other way around.
Changes (2019-07-06):
- Editable dropdown of the start location marker size can now draw the markers with decimal value sizes except for the Tiled marker type.
- Fixed: Cases where the renderer button won't work for more than once without restarting the application.
- Fixed: Facings corrected for SHP vehicles where its ART.ini section won't have WalkFrames=1 specified.
- Fixed: Shadow problem(s) fix for rendering the first instance of a 32-facing SHP vehicle placed on its first or last 8 directions.
Attachment contains a generic version, a TSClient version with the pre-set UI settings and source code.
I think everything aside form the walls is in order now (and for the walls mappers could just learn to place them as overlay instead of buildings ), so thanks a lot! _________________ QUICK_EDIT
For the TS tunnel entrance tops to be displayed, attaching an extra mix file and the modified modconfig.xml which are to be placed in the map renderer folder of the TSClient version. It contains tunnel top graphics added to the tunnel floor tiles. It looks better than what the tool currently shows but it comes with couple of glitches - objects are drawn over the tiles so objects that are supposed to be under the tunnel are shown above and lighting isn't completely adjusted. This is an optional or stopgap alternative to coding in the tool (have yet to figure out why tile anims are not getting displayed).
I just tested it and can confirm that building walls are properly connecting now, good job.
A somewhat less important suggestion I have is to make all infantry display a random facing in order to make them look more natural. I made a tool script for Final Sun to do this a while back, but IIRC infantry facings were always ignored (and nobody used the tool script anyhow).
Game randomly changes facing when infantry is standing idle, so mappers would probably ignore it. For renderer, will look into it when time permits. It can't be generic as people would want to see the facings as it is placed in the maps. If FinalSun scripts work then it is only a few clicks to randomize. QUICK_EDIT
It is not always ignored. At least in RA2/YR infantry on certain missions (such as Sleep, IIRC) do not shuffle the facing. Might have been restricted to singleplayer only, though.
Just stick to the tool script if it is a concern tbh. _________________ QUICK_EDIT
The problem is that the game itself seems to entirely ignore specified infantry facings and all infantry just face east until their idle animation has played. _________________ QUICK_EDIT
Changes (2019-07-29):
- Sequence entries are now read from Art.ini for infantries and its Ready values are used for facing calculation.
- Added parameter for modconfig.xml to enable infantry facing randomization.
Attachment contains a generic version, a TSClient version with the pre-set UI settings and source code.
@Bittah Commander: Attaching updated modconfig.xml for DTA with infantry facing randomization enabled.
I tried it out and while randomized infantry facings do work now, the renderer appears to fail whenever a map has visible structures present on it:
Code:
...
[Info] Drawing tiles... 44%
[Info] Drawing tiles... 49%
[Info] Tiles drawn
[Info] Drawing objects... 55%
[Error] An unknown fatal exception occured: System.NullReferenceException: Object reference not set to an instance of an object.
at CNCMaps.Engine.Game.ShpDrawable.Draw(GameObject obj, DrawingSurface ds, Boolean shadow)
at CNCMaps.Engine.Game.BuildingDrawable.Draw(GameObject obj, DrawingSurface ds, Boolean shadows)
at CNCMaps.Engine.Map.Map.Draw()
at CNCMaps.Engine.EngineSettings.Execute()
Unknown exception.
Another thing I noticed is that the size of the visible map area isn't always correct. Below is an example of DTA's "Crossroads" map, which (because the space between the blue and red borders is less than 4 cells) actually shows 1 row of cells less ingame than indicated in the map editor, while the image generated by the map renderer at the same time shows 1 row of cells more than what's indicated by the map renderer.
While I'm not sure if it's possible for the renderer to consistently cut off the same amount of cells from the bottom of the map as the game does (because when the red and blue borders overlap, the game sometimes cuts off 4 rows of cells and sometimes it's only 3 rows), it should at least not show more rows of cells than the map editor itself indicates.
The ambient light shown by the renderer is also brighter than ingame in this example (using Ambient=0.950000), but IIRC getting the lighting to match the game exactly has always been a challenge.
The renderer no longer fails on maps with structures, thanks.
Starkku wrote:
It is not always ignored. At least in RA2/YR infantry on certain missions (such as Sleep, IIRC) do not shuffle the facing.
Does this mean that RA2 doesn't ignore specified infantry facings like TS does or will those infantry just always keep facing east? _________________ QUICK_EDIT
Does this mean that RA2 doesn't ignore specified infantry facings like TS does or will those infantry just always keep facing east?
In sleep mode etc. for SP maps, infantry don't change direction in YR and have the facing as given in the map. In TS, those do the same but face east instead of the facing given in the map. In other cases like guard mode for both SP and MP maps, random facing is set when the map loads and then those could get changed based on the time given in IdleActionFrequency. QUICK_EDIT
Changes (2019-08-01):
- Added parameter for modconfig.xml to crop the map bottom during the image rendering for local size option. Values can be in range of 0 to 16.
- Added parameter for modconfig.xml to adjust map lighting with comma separated values for ambient, red, green and blue. This delta value is added to the values obtained from the map's lighting section. Decimal values can be in range of -1 to 1.
Note: The cropping of bottom rows is applicable for image rendering (JPEG/PNG) only with local size option. It does not affect the preview window or preview map pack generation or when used with full size option. When the bottom rows of the map have some height, it shows vacant portion. To avoid that, there is a cutoff logic which will override the modconfig parameter for cropping the bottom rows when its number of rows to crop are higher.
Attachment contains a generic version, a TSClient version with the pre-set UI settings and source code.
@Bittah Commander: Attaching updated modconfig.xml for DTA with adjusted values for map bottom cropping and lighting.
@Fortranm: I just checked with the freeware TS version with Forced FS on fsgdi08.map and it works fine with all overlays of walls and correct palette for the dam. Choose the installation path for mix files path and Forced FS option. Both TS and FS maps can be rendered with Forced FS option. Don't use the Auto detect, it is flawed as it is based on the vanilla game's registry entry. I would suggest to use the TSClient and use the latest update of this tool.
I even tried to install the Origin version so that the game is registered, but I still get the same results. The Origin version seems to be identical to the freeware version content-wise.
I couldn't get the renderer to work with the TS client at all even after the latter is updated to v5.44. I tried choosing the path of the client and the MIX folder inside it but neither of them worked. QUICK_EDIT
For the vanilla game, just selecting the Mix path and then choosing the Forced FS option makes it work. It doesn't need the Load special mod config option.The Mix path should point to the game installation path where the game's mix files are present.
For TSClient, unzip the latest update of this tool and copy the TSClient folder into the TSClient installation. You can rename this tools folder from TSClient to any name but it should be one folder inside the TSClient installation. In this, Load special mod config option is checked by default which points to the additional settings of ..\Mix folder and ..\INI folders. Just select the map and render it.
TSClient also comes with an older version of the tool, which you should be able to run as is, just select the map and render.
Try giving admin permission if it is in system folders. QUICK_EDIT
Thanks for the improved lighting and cropping, although I am curious why you added them as modconfig.xml settings (since they're not mod-specific for as far as I know).
With MapLocalSizeBottomCropValue set to 3 it seemed to crop half a row of cells too many, but I think that with it set to 1 it at least always crops correctly whenever the map properly has a gap of 4 cells between the blue and red lines at the bottom of the map in FinalSun.
I have to say that the map renderer was always just something I included with DTA to convenience other mappers while never actually using it for the map preview images I make myself because creating composites from ingame screenshots gave noticeably better results, but after the recent improvements this no longer seems to be the case and I'll certainly be using it from now on. _________________ QUICK_EDIT
The game crop of the bottom was not changing in a test map I made, it was hiding 5 rows (10 rows interlaced) irrespective of the red/blue line overlaps or not. Couldn't figure out the game's logic about it. And the author of this tool seemed to have coded the bottom crop with some explicit rows calculation, so I felt it better to provide it as an option.
Color computation is correct in the code as per the parameters from palette and map lighting, but what the game produces on the screen varies a bit. So I think the modconfig option gives flexibility for the user. QUICK_EDIT
The problem is FA2YR no longer generates map code sufficiently around the map extents to avoid the engine cutting off aggressively, and because of that has also introduced that shadowy top line glitch. The old FA2 didn't seem to behave the same way. I'm guessing no one sufficiently tested for side effects when Westwood bought it and made their changes/updates.
When editing a map, I change the viewable area to 5 from the top and at least 5 from the bottom, so I lose like 10-11 rows, and I let the renderer use that without issue.
The height of the map also has an effect on the automatic engine cropping and visual glitches, as does the height of the tiles at the very bottom edge of the map. As long as you choose to cut 5+ the game should never override your values.
You have managed to (likely accidentally) cripple the Map Renderer's ability to properly read settings for the UI, especially the per folder ones (gui_settings.xml). The reason for this is two-fold.
First of all, CNCMaps.Renderer.GUI/Properties/Settings.Designer.cs portion of Settings class is lacking the SettingsProvider attribute, possibly eradicated by Visual Studio re-generating the code but I don't think it is supposed to remove it.
Secondly, CustomSettingsProvider class that is actually supposed to parse the settings file will not be able to do it properly even after that, because you have added a setting that uses a type that cannot be found in mscorlib.dll or CNCMaps.Renderer.GUI itself, namely WindowLocation, which is System.Drawing.Point. CustomSettingsProvider calls for Type.GetType method on the properties' type names, and for System.Drawing.Point this will return null due to the aforementioned assembly restriction. Particularly, when the settings file lacks the setting and it attempts to use the default one, it'll attempt to convert the default value to the actual type of the setting, which will throw an exception if it is null (which then gets caught somewhere I believe) and it stops parsing the settings entirely.
There's a couple of options for remedying this. First would be to not use System.Drawing.Point at all in settings, instead handling the conversion from (probably a string) to point yourself where needed. Second would be adding extra code to CustomSettingsProvider where it calls Type.GetType explicitly specifying the assembly for this case.
I also still think providing the entire changed source as-is in an archive like that instead of using git and a public repo makes everyone's life needlessly difficult, but I digress. _________________ QUICK_EDIT
Visual Studio removes that attribute when re-generating the Settings.Designer.cs file. Another oddity of VS to remember when changing UI in this tool. As you have already mentioned the reason and given the solution as well, will update the tool to enable the usage of gui_settings.xml. Otherwise, the UI settings work just fine with the user specific user.config file being generated by the tool. QUICK_EDIT
https://cnc.gamepedia.com/File:Tiers.jpg
It seems the veins aren't really rendered correctly. The renderer almost always reports missing objects on maps with veins. QUICK_EDIT
This may seem like a small detail, but totally damaged buildings on maps are shown as partly damaged, meaning they don't show as rubble like they should.
Small detail, increased complexity. Only applies to RA2/YR (not TS, so becomes game specific) and not for all buildings. And when it gets applied, all theaters may not have the needed frames. And all addons should be nullified like various building anims, turrets, upgrades, etc. With palette change, dependent features like remapability get affected. Not all is known to me like if it is always the 4th frame for rubble (does absence of occupy feature plays any role) and what happens when Ares custom palette is used etc. QUICK_EDIT
I'd keep it simple. In RA2 rubble is always the 4th frame, garrison always #3, for buildings that have rubble and no garrison, #3 is usually a copy of #1...
If there's no 4th frame, there's no standard rubble, I can't speak for Ares however.
Already does, although only on buildings, aircraft and vehicles which isn't complete since game allows attaching AlphaImages to other types of objects like Infantry / TerrainTypes as well. The reason for this is that renderer treats AlphaImages as separate pieces to draw (sub-drawable) akin to bibs, turrets & barrels - and infantry, terrain, overlays etc. are treated as simple, one piece graphics that do not use these sub-drawables at all. They exist but are never actually drawn. _________________ QUICK_EDIT
TI and DTA use AlphaImage on TerrainTypes for various street lights and fauna. Thus it would be quite useful and nice to see them rendered.
Projectiles, Particles, Voxel/SHP Debris and pretty much every object in the game can use AlphaImage as well.
But i guess since these are mostly temporary and created ingame, support for them isn't really needed in map renderer. (Except stuff like a scripted particlesystem on certain waypoints may be shown in future as well.) _________________ SHP Artist of Twisted Insurrection: Nod buildings
would have been more expressive if both images have shown the same spot on the map. _________________ SHP Artist of Twisted Insurrection: Nod buildings
I just thought of something that could be useful...
Allow % (or fixed ratios like 1:4 through 1:12) as the thumbnail output, so that just like the full renders you could render every map to a common scale.
Supposing your screen is large enough, you could flip through them all quickly at fullscreen with a viewer to see how they all compare without random scaling. _________________ http://www.moddb.com/mods/scorched-earth-ra2-mod-with-smart-ai QUICK_EDIT
Can easily use IrfanView or XnView etc. viewers, those can scale and show the images in fullscreen as is or also can batch process to resize the images with better quality to the percentage or size of your need. QUICK_EDIT
He would likely be referring to the un-shaded ore cells, which if I remember correctly use a different overlay. These patches of non-ore ore are present on the default maps.
Thanks for all the updates on this wonderful tool! 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
), so thanks a lot!
