Posted: Sat Sep 12, 2020 10:09 am Post subject:
Improvements for the map editor
I have created a branch for improving the map editor. The branch will focus on improving the UI and usability of the map editor. I have no definite plan on how long I'm going to work on this project or what I'm exactly going to do; I'll just be improving stuff whenever I realize there's something that could be done better and I happen to get a spike of motivation for improving it.
Current features:
Downsized menu graphics by an user-configurable factor so you can see more placeable object types at once on sub-4K monitors
Improved zoom levels
Fixed a couple of crashes
Made tool windows remember their previous position, size and other settings upon closing and re-opening them
Replaced drop-downs with list boxes in object type selection dialogs to allow switching between objects with fewer clicks
I'll also accept pull requests that fit in the scope of the project.
On the last game patch, they expanded multiplayer to 6 players. Someone must have misinterpreted that as "expanding the amount of possible players by 2", rather than "unlocking the real internal maximum of 6", and decided the map editor's amount of multiplayer starting points should also be increased... while that actually already went to the real internal amount of 6. So it's been increased to 8 now.
This in itself is wrong, but would be fairly harmless, had it been done correctly. The issue is that the game has a set of special singleplayer scripting waypoints at 25, 26 and 27 (respectively: flare pos, mission start pos, default dropoff pos), and whoever did the "+2" thing on the multiplayer starting point range forgot to decrease the amount of waypoints between those multiplayer starting point and the special ones at the end, causing the special waypoints to shift to 27, 28 and 29.
This causes real issues for making singleplayer missions, since the game still requires these special waypoints to be 25, 26 and 27, of course. Not only are they now indicated wrongly in the editor, but the editor actually checks if the "mission start location" waypoint (normally 26) is placed before it allows saving the mission, and now that's checked on the completely useless waypoint 28.
[edit]
It seems they actually "fixed" the issue in the github code, but the wrong way around; they changed the range on the in-between waypoints to Range(8, 17) instead. It's still messed up in the editor included in the game, though; it must have been built with that second line still set to Range(8, 19).
So, yea, the special waypoints are already correct in your current builds, but, for the sake of correctness, please fix that back to Range(0, 6), and the next line to Range(6, 19). The game can't handle more than 6 multiplayer players anyway. _________________ QUICK_EDIT
Joined: 24 May 2004 Location: Flanders (Be) Posts:300000001
Posted: Sat Jan 02, 2021 5:06 pm Post subject:
Here's another one for you...
I believe the map editor for TD saves empty tiles as their actual tileset ID, meaning they end up as byte blocks "00 00" to "00 10". The original game's maps, however, all use an internal default of (-1, 0) as empty tiles, which translates to "FF 00" in the .bin file. (XCC Editor also makes this mistake, and the older CCMap uses "FF FF" for some reason.)
If you look at Red Alert, however, you'll see it correctly uses (-1, 0) for saving clear terrain (which translates to "FFFF 00" in the binary map format there)
It would be nice if this map editor actually saved the TD clear terrain as it is saved in the original game files. _________________ QUICK_EDIT
Vanilla Conquer has just merged my pull request with the mega maps code for Tiberian Dawn. I did try and implement support for this in the Remastered Map Editor when the source code released, but I was unable to get it loading the maps correctly.
On load, I checked for the new INI key to decide what map type to load, and on new map I just had a checkbox option.
I have attached a map I created in this format using Vanilla Conquer. Perhaps you might be more sucessfull at implementing support if you find the time.
How does the internal WW map editor save these empty tiles?
It saves all tiles belonging to the clear set to -1 with the tile index of 0 as nyerguds states because this is how blank tiles are initialised and stored within the in game data structures for the map. QUICK_EDIT
I'm curious on your Mega Maps support, I'd been thinking about trying to build support for larger maps into the remastered code, but it seems you've already done so. Does the revamped code support sizes up to 128 provided the MegaMap config is in the ini file? Are there any ramifications from the increased size? E.g. minimap, Nod transport aircraft, Gunboats.
Would you mind if I ported the code to my AI mod and gave credit for it? QUICK_EDIT
Joined: 24 May 2004 Location: Flanders (Be) Posts:300000001
Posted: Fri Jan 22, 2021 10:05 am Post subject:
EGG wrote:
Hi CCHyper
I'm curious on your Mega Maps support, I'd been thinking about trying to build support for larger maps into the remastered code, but it seems you've already done so. Does the revamped code support sizes up to 128 provided the MegaMap config is in the ini file? Are there any ramifications from the increased size? E.g. minimap, Nod transport aircraft, Gunboats.
Would you mind if I ported the code to my AI mod and gave credit for it?
His upgrade was done not on the remaster itself, but on a reimplementation of the original game using the released code. I'm not sure if the GlyphX engine won't have any hardcoded issues with regards to the maximum expected size of TD maps. _________________ QUICK_EDIT
There are undocumented XML flags that need to be set for it to work correctly in the remaster which CCHyper provided. I need to add proper documentation for using it to the Vanilla Conquer wiki once we get one up.
As an aside, we are mostly focused on developing the standalone aspect of Vanilla Conquer at the moment, but it would be great if more people were trying our code with the remasters and reporting bugs. QUICK_EDIT
I went through and added support for 128x128 TD maps to Rampastrings code. I can't get it to load the example mission CCHyper uploaded. It will parse the ini successfully, but doesn't like something it finds when it moves onto the bin file.
However it seems ok with creating/saving/opening 128x128 or 64x64 files where the binary has come from the TDRA editor.
I haven't put a pull request across to Rampastring's repo yet as frankly this is the first C#/.Net project I've worked on. I'll put one through if no-one seems to think the code is terrible.
On compiling Rampastrings code;
a) VS2017 needs JSON, Pfim and System.ValueTuple packages
b) It possibly needs the NETStandard package
c) It needs the .csproj file modified to add the following line alongside the References:
<Reference Include="netstandard" />
d) The EA/Petro code has no comments, unless they're hidden in some way.
e) I swear in an earlier version of the TDRA map editor, RA had the possibility to set map size on creation, but I couldn't find any legacy handling for that which could be re-used. QUICK_EDIT
So I found a cncnet forum post with unsurprisingly, most of the same names from this thread, discussing the sole survivor binary format in 2014 and went from there.
It now uses that format when saving/opening 128x128 maps and can open BreakingGrounds and save it again after map alterations. I tried several of the sole survivor maps with the MegaMap=1 flag added and they were fine also.
64x64 maps still use the old binary format, and there is a flag in TiberianDawn.Constants.cs if ever someone wants to revert to saving 128 maps in the 64 binary format.
The code as implemented in Vanilla Conquer checks for Version=1 rather than MegaMap=1 which is what sole survivor checked to decide which format to load. CCHypers original mod was going to use MegaMap=1 but that was never released and I decided to stick with what sole survivor used for future compatibility with that games data.
Great to hear support has been added for the format, when I get chance I'll build the editor and check it out. Builds of https://github.com/TheAssemblyArmada/Vanilla-Conquer will load megamaps so long as the ini has the correct key set as discussed above. QUICK_EDIT
The code makes assumptions that certain datatypes underlie cell numbers and coords so I'm not 100% sure how much work it would be to increase it further, especially since those data types are also assumed to be different from a function overloading POV. IMO 128x128 maps feel pretty large as is though. QUICK_EDIT
Joined: 24 May 2004 Location: Flanders (Be) Posts:300000001
Posted: Wed Mar 10, 2021 1:20 pm Post subject:
Some very simple requests:
-Add Drag & Drop for opening maps.
-Add classic shortcuts ([Ctrl]+N, [Ctrl]+O, [Ctrl]+S) to the File menu.
-If a map is opened from a custom folder, open the Open menu in that folder again, rather than defaulting to the folder under Documents of the opened map type.
-When holding [Shift] in Waypoints and Celltrigger mode, actually give a half-transparent preview of what to place down, like it is done with the other types.
-Just like how units or structures get detail info when double-clicked, it would be nice if in Celltrigger mode, double-clicking a celltrigger opens the Triggers list with that trigger selected for editing.
-Make it so placing down the Clear cell actually clears the terrain (identical to shift+leftclick), rather than placing down that one specific cell. Clear is actually a full 4x4 block anyway, and it's not possible to specifically place any of its other cells.
Bugs I noticed:
-There's a strange smaller "ghost frame" visible when you click on the terrain tile to select a single cell from it
-Units can't be placed on the impassable cells of structures, even if the structure is only on the Rebuild list and is unbuilt from the start.
-If you open a scenario where the above situation exists, the structure seems to be terminally bugged. You can't double-click the structure to open its settings, but you also can't remove it.
-Overlap of structures is actively blocked for no good reason, and they are removed on scenario load. Open the Covert Ops "Infiltrated" (scg36ea) to have an example of this messing up an official scenario. This scenario also has the above "unit on unbuilt structure" issue, on the west power plant in the enemy base. _________________ QUICK_EDIT
The developers wants us to add a waypoint 28 (home) to a map.
In the stock game editor, this warning doesn't show up, but in your editor it does.
I might not be entirely right. QUICK_EDIT
The developers wants us to add a waypoint 28 (home) to a map.
In the stock game editor, this warning doesn't show up, but in your editor it does.
I might not be entirely right.
The stock editor is wrong. Home is 26, not 28. The editor somehow expanded the amount of multiplayer waypoints for C&C1 from 6 to 8, which the game can't handle at all, and it messed up the special waypoints that come at the end. _________________ 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
Improvements for the map editor
