You may want to poke around the Zero-K codebase as well:
https://github.com/ZeroK-RTS/Zero-K. I have pushed the engine further than BA so you should find some more mechanics and examples.
1). 32 unit classes (mostly for targetting AI)
Unsure and unclear. I believe that unit categories are only relevant to NoChaseCategory, BadTargetCategory and OnlyTargetCategory so if there is a limitation it is contained to a few cases. However, my
target priority gadget allows for target priorities and targetability to to be set arbitrarily on a per weapon and unit basis as well as allowing for these settings to change during the game. Therefore much of the purpose of BadTargetCategory and OnlyTargetCategory is replaced by lua, it may well be all replaced. I am unsure exactly how NoChaseCategory works in the engine and interacts with target categories so maybe it can be replaced as well.
2) 4 unit types (kbot, vehicle, hover and ship) .. ..which made me scratch my head, because air?
Not really a thing as this concept is mostly deprecated. As far as I am aware the unit types are even less used than unit classes. These four words only appear together in reference to speed modifiers that are added on top of the maps terrain. There is no real limit to the type of interaction your units can have with the terrain of a map. You can independently set their slope tolerance, slope speed malus, whether they hover, max water depth, min water depth etc.. I think that units can even have their movement type changed during runtime.
If there is a limitation it is that there are only a few types of speed modifiers (think roads) that exist on maps.
3) max map incline of 89.99 degrees. (no over hangs or bridges)
Yes.
4) a unit max, i think. (5000, or perhaps the engine could do as many as a cpu could handle)
Others would know better than me for strict technical limits. However, I would be surprised if someone made a game with a playable framerate with unit counts exceeding 5000.
5) only two resources, (metal and energy)
Not a limitation. The engine contains handling for these two resources, however, the scripting is easily powerful enough to replicate any resource system you may want. Zero-K uses metal and energy but the engine implementation has so many issues that I have almost entirely replaced resource handling with lua, so I know it can be done.
6) fuel systems have been deprecated
Not a limitation, same reason as 5). Any behaviour you may want to link to a "fuel' attribute of units can be scripted. Zero-K has a system similar to fuel in which bombers return to airpads to reload and this system is entirely lua.
7) there was the yard tags, about only 7 of them, iirc. (more can be coded, i assume, not really a problem)
There is no limitation related to restricting structure placement, I don't know what else yardmaps might do. Zero-K has metal spots which are enforced to only be able to have metal extractors placed on them. You could make a system of arbitrary spots with limited structure selection.
there is only three types of collision boxes, but you can make custom collision boxes around unit pieces.
This is not a limitation, with a caveat. It is correct that units can only have spherical, cylindrical or rectangular collision volumes. However, there is a piece collision volume system that I have not looked into and, in the worse case, a game that really requires more extravagant collision volumes can simply paste multiple units together to seamlessly create one big unit.
9) this one is a question, which i will find out later, but it seems maps need pathfinding meshes. i assume this is for optimization, and the engine does have a bulk cpu pathfinding routine as well, if a defined mesh is not available.
Incorrect or unclear. The engine generates pathfinding meshes for the map when it is loaded. This mesh is cached for future games and updates when the terrain changes during the game. Map makers and game developers do not need to worry about generating path maps.
10) weapon types. although there are various ways of making them, and certainly some awesome tricks i have envisioned to get what i want, there was one weapon type that was removed, it seemed to be an arc-swing type weapon? in my vision, there will be many many arc/wave type weapons, a little different from pyros fire, but i envision using the flamethrower script in short bursts if necessary)
Not a limitation. For arc type swing weapons I recall an experimental unit from years ago which effectively wielded a lightsabre. This was probably done with a noexplode constantly emitted beamlaser. In any case, lua can set damage and effects once the weapon collision is detected.
11) detection types: radar, seismic, los, sonar
Sort of a limitation. The terrain-raytraced LOS and radar systems would be slow to replicate in lua so if you want this sort of detection you are limited to the options within these systems. That said, you can add more systems on top. For example there was a Spring game with mass-radar which would should blobs of enemy units as a region of high mass instead of inidividual radar dots. Lua also allows for units to be arbitrarily hidden or revealed.
12) 32 bit
Yes, in my experience. The 64 bit windows build does not work for me and has not been tested on many users so it is unlikely to work.
13) no way to define the effects of a weapon depending on the unit type it hits, (ie, a bullet will make the same noise and explosion effect if it hits a person or a tank)
Not a limitation. Weapon impacts cause events which can then be handled by lua to spawn effects or do any other game mechanical thing you may want.
14) 2 weapon effects: damage and stun
Not a limitation. You can create just about any status effect you may want and weapons can also apply impulse to knock units around. Zero-K has a general slow effect as well as a weapon disarm. See
https://github.com/ZeroK-RTS/Zero-K/blo ... ibutes.lua
