@cernel said in Map to Engine Compatibility Problems:
I'm mostly worried about an automatic converter not messing up very complex and big conditions / triggers xml codes, as well as all current triggers / conditions capabilities being still available (like a trigger checking for a condition that checks for other conditions and other stuff).
In this suggestion, from me, the converter would not be
XML -> XML. The map parser of today is effectively a converter from
XML -> java objects (POJO). The problem we have is that the java objects created are 100% specific to the XML, there is no leeway to remap the java objects. To make it worse, we use those java objects everywhere in the system, so we're coupled to the XML text all throughout the game code. To make it worse we save that to disk on peoples hard drives, which then goes on to live for a very long time. It's an ugly problem, but we've actually done some pretty good work to unwire the POJO's from the rest of the game engine, so we basically have something like:
XML -> single java converter object -> POJOs
So an in-game converter would basically be: "If you see the word 'infantry', map it to 'army'".
XML -> adapter(java) -> single java converter object -> POJOs
Personally, the xml works just fine, so I don't feel a huge need to move to something else
yes and no. There is a lot of unnecessary complexity in the spec. Take note for example how certain relationships are redundantly defined. The XML spec file for how a game is setup, should not be thousands of lines long, let alone 10k, or 30k. All we are doing is specifying map and unit positions, and game rules. The fact it can grow so large makes it not accessible; we want map making to be really easy. I'm not necessarily saying we need to move to YAML, but the current spec is overly-complex for what it is, it can be simplified.
but if you have, like, 100,000 or more lines of coding, then it starts getting really heavy on the RAM (and on the CPU mostly if you are doing recursive stuff, like having a lot of activations), so the only thing I can think of I may be wanting is something that allows enormous xml to run with less RAM and CPU requirements, or being read and loaded faster.
There is the efficiency of parsing large XML's, but fundamentally we should not have such large files. We've already lost when any map file is over 1000 lines long.
Aside from this, I'd stick with what we have now, since it works fine enough, and I don't see compatibility as something to worry about that much.
@Cernel is that only because we do not break compatibility very often? Do you think the map XML is approachable for new people? We ideally want new map makers to join the group, IMO that should take 30minutes to an hour to create your first map, and maybe 10 minutes max to update an existing map.
I think it also depends a lot on the kind of followers a map has. If you break NWO savegames, I can see people getting angry, while I wouldn't expect reactions from TWW players, instead.
Hehe, when dealing with the engine, often the answer can be all, so we'd be talking about all savegames for every player. It's a bit of a running myth/theme that we lose n% of all players on every non-compat release. The splintering of community and trashing of save games is very upsetting.