elexis

I only know the following thing: If a unit starts and stops a move on the same turn, the walk animation will not be triggered, thus gliding. This can be tested by starting a multiplayer (500ms turn length as opposed to 200ms in singleplayer) and moving a female a very short distance.

The development of that code is in progress by @Sandarac and @mimo , see #4431 Petra responds to diplomacy changes #4143 Petra Last Man Standing support

I'm passing this ping on to @fatherbushido

That last game: Map: Mainland Players: ShadowOfAzrael43, MacWolf, imrobbyg, philosopher, Grugnas, LilBlast, Letticia, PrincipalityOfZeon (FFA) Gametime: 3 hours (not 4 as displayed here, nor 5 as displayed in your list due to an embarassing timezone bug. But if there was casual lag you might get there.)

Marked for later: #4449

Last release we also added portraits in feature freeze time (otherwise we'd have had placeholder/duplicate icons and icons that don't show the thing that is placed wooden/stone tower). That implies proper testing before the commit though (we already had PNG transparency crashing the thing).

Judging from the last four releases.

A circular shape would be ideal obviously, but I'm not sure if those sqrt() things might be too slow. Perhaps we can also first test for the square selection and then the circular one for the candidates.

I doubt that

Perhaps nuking configuration files makes a difference: GameDataPaths

Thanks for the report, I marked it for later #4448

So we need to distinguish the numeric options between integer and float, probably some other sanity checks. Empty string also bugging. A brief ticket on http://trac.wildfiregames.com/ would be welcome.

Perhaps some directory permission thing. Try reinstalling it, potentially to a different directory.

As far as I know, the obstruction size is relevant to pathfinding, the footprint relevant to the selection box and selection ring. See also #3861 for example.

Everything in the green box is assumed to be the civic center when selecting. What we do observe though is that the footprint is circular, but the engine ignores that and acts as if it was a square one. In particular input.js calling PickEntityAtPoint from Selection.cpp which calls PickAllEntitiesAtPoint from CCmpUnitRenderer.cpp which uses a CBoundingBoxOriented to check for the things beneath the mouse cursor. In BoundingBoxOriented.h we find this unflagged TODO that would probably address this issue: * However, it could also be used to represent more generic shapes, such as parallelepipeds. A hexagonal shape would likely help with the reported issue without causing a too bad performance impact.

See also the bounding box overlay.

If I understand correctly, his issue is that moving the cursor above the CC ends in the game assuming the cursor hovering the CC. So the selection box of the CC would be too big (in particular too much height). However testing, in particular using Alt+D to open the developer overlay, removing the camera restriction and rotating the camera so as to get a front view reveals that the height of the briton CC footprint is actually correct. If we reduce it, the highest point is not inside the footprint anymore. So the mismatch comes from the cuboid shape, while the graphical model doesn't have that.

Performance. The thing is lagging already, adding more checks will make it much worse. Also every unit must have a hitbox, otherwise units will walk through things like ghosts. Perhaps the hitboxes could become significantly smaller (for siege engines and ships, like 4 -> 2.5 or something).

As said above, scenario maps determine themselves what settings they come with. Skirmish maps work with all settings as it always has been. These three discussed options and the victory conditions should be independent of each other, so we can play last man standing survival nomad regicide wondermode on every random map and many skirmish maps (see also #4014)

Actually I had started to rewrite all random map scripts to: Firstly remove their syntax errors (missing semicolons, whitespace, unused variables, unneeded variables, bad indentation) (see also RMS rewrite spam after some a21 freeze). Secondly remove code duplication hell (basically all old map were done by coping some other map, changing numbers and adding more code to it). For example adding a function to place berries, a function to render a city patch, a function to place the CC and initial units, a function to place initial stone and metal mines. (See also something stashed in some github repo). Thirdly fix resources collision bugs that can now be fixed in the new function instead of in every map individually. For example initial mines can be placed in trees, mines or berries (since the angle where they are placed is hardcoded and there are no collision checks at all ). On stronghold map even in the neighbors CC. Fourthly profit from the cleanup by easily extending the features. For example nomad and survival are very enjoyable gamemodes, but they only work on two maps each. Instead, we can add an individual gamesetup option for these two modes, so that they can be played on every map! (Checkboxes, not a victory condition dropdown choice, so that we can combine things arbitrarily). Survival mode would be similar to this proposed "capture the flag" / "capture the military colony" gamemode in that it's RMS implementation could be optional. The map may or may not place some TriggerPoints. If there are some, place the military colony / survival waves there, otherwise find a place that is far away from the players (respectively very close). See also the regicide gamemode script that places the hero near another unit of the player (and garrisons the @#$% if that unit is a ship). The nomad mode however needs RMS involvement to skip the placement of initial resources (and place proportionally more random mines). (Placing starting entities and them removing them after the fact sounds terrible). Scenario maps are supposed to be inflexible. The map determines the modus operandi, so it should also place these trigger points if it choses the colony / survival mode. (A scenario map could also come with custom survival / colony scripts and disable the generic scripts). The map would also has to decide whether it is a nomad map or not. Skirmish maps are created in atlas, but their gamesettings are open to changes. The SkirmishReplacer is used to switch the entities placed in atlas with the equivalent of the civ chosen by the player. We either completely outrule nomad on Skirmish maps or remove all replacable structures from the map. (Since the SkirmishReplacer part is done before the first turn, it wouldn't appear too bad). The survival / capture mode would have to be implemented by adding TriggerPoints to each map. So the lucky one to implement these three gamemodes has to rewrite about 70 random maps 4 times, edit 50 skirmish maps once and add 3 generic triggerscripts. Seems feasible in few sleepless nights.

See also https://play0ad.com/about/the-story-of-0-a-d/

0 A.D. detects collisions by testing for intersections of simple (square / circular) two-dimensional hitboxes. As seen int simulation/data/pathfinder.xml, we only have three different choices for the radius: 0.8 for infantry and cavalry, 4 for rams and 12 for ships. Since the length and width of the obstruction are identical, this won't work well for non-circular / non-square models like ships. Visual models overlapping can be addressed by increasing the size of the obstruction of the particular unit. But that causes more annoying pathfinding situations where the unit can't pass forest or straits. In case where units are blocked by other movable units, those could be pushed away (for example infantry could evade rams). Due to the current performance being already too bad to keep up with the attempted ingame time ("performancelag") when too many obstructions exist, adding more complex shapes is not accomplishable without major rewrites.

Would still require to educate every map about new game conditions. Better write a script that works for all maps by trying to find a smart solution (random coordinates, try placement checks. Might end up in an uneachable position I guess, unless we would do a pathfinding check to ensure reachability)

Map: Gear (new years eve mode, mountain climbing) Players: (Grugnas, User|Master) vs. (ycswyw, elexis) vs. (Smurf_Juice, _zoro_) vs (Vercingetorix, Feldfeld) Summary: As usual, Gear is a promising map. Especially if there are more than two teams, the one taking the middle attracts the enemies attention, since the mountain in the middle provides access to all players and can even prevent them from trading. The small lakes in between players can easily cause tension. If water control is lost, one can quickly find oneself in a bad situation, leaving half the village vulnerable. By building houses around a garrisoned ram near a mountain, the ungarrison process will transfer units to the mountain, thus being able to build a fortification that can only be destroyed with catapults. At the end of the game, it is also demonstrated that unit and building colors can be changed, even if the others dont have that disco patch installed. (The demo replay shows it immediately after the start of the replay.) 2016-12-31_gear_2v2v2v2.zip 2016-12-31_new_years_eve_demo.zip disco.patch

When planning new gamemodes, it's good to have the compatible on every map (It's unexpected if settings are only available only on some maps.) In case there are new entities relevant to the victory condition or gamemode, they have to be placed after the game has started, if we want to avoid changing all maps (that should support the gamemode). If we want to place some military camp, that would have to pass the build restrictions, but that shouldn't be hard at all actually.