elexis

Since the salt is the same for everyone, one can still create only one table afaics. The current hashing does not protect from a client attacker but prevents people with read access to the hashed password from finding out which password players use for the nukes in case they use the same password for 0 A.D., so it's not entirely useless. People with read access to the hashed password are moderators. The password is explicitly removed from the logfiles, but in case the user config gets leaked somewhere, it would have that little effect (so the current hashing is not entirely useless). Admittedly using some kind of private/public flavored crypto would be an improvement.

s0600204 is working on the browser that shows information of selected units. That includes the history strings. Some of them contain the information you have described above and it is proposed to separate the gameplay advice from the historical information. So in case we go with that, we might want to come back to your proposal.

We'd need a new simulation component to keep track of the environment variables that we want to control, equal to the CCmpWaterManager.cpp that updates the renderer. Not too hard to accomplish, limited context. Still would need someone willing to do it. We should also flesh out the use case beforehand. We could have different, fine-tuned sun angles for each map, or we could have a complete day & night cycle independent ot the chosen map.

The problem with slingers was that they nuked buildings really easily. We didn't want people that can throw tiny rocks to destroy fortresses quicker than siege engines. We can't fix that with accuracy, because a CC or fortress has a huge footprint. Slingers vs other units were not intended to be changed much by that commit. I did see a lot more cavalry rushes in a22, which is a thing I do like. People have complained a lot about turtling and rushes being useless in the past. So take care in case of proposing balancing changes. It'd be great to have a replay that undoubtedly proves skirmisher accuracy to be a bug and not a feature. It ought to be discussed and tested in svn lobby games (admittedly that can be done more easily if people have Phabricator access and in a21 we actually had these balancing testgames based on that with Grugnas, borg- and few willing guests).

Unless the fix (deleting Player.js) works for both 22 and 23. When testing DE, I couldn't find a way to get that 500 pop in the file, so nothing would be lost afaics.

There are 2 reported bugs on trac about that. One crash on window when minimizing the game and a crash on windows when doing alt+tab. They occur somewhat frequently, so should be fixed indeed.

Screenshot?

If it was rejected, it'd clearly state that. That what LionKanzen said is correct. The ones doing reviews first look at the patches they are interested in, then the patches they are personally asked to be reviewed, then the open ones on Phabricator, then (almost never) the ones on trac with rfc or review keyword, then (basically never) the ones without keywords on trac. We started Alpha 22 development with about 80 reviewable patches iirc. The handful of active developers we have spent their time doing somewhere around 400 reviews that ended in commits, maybe 100 reviews not ending in commits and barely any own coding. Now we have 65 patches on that work-in-progress milestone on trac, 205 open patches on phabricator and the will to spend much less time on reviews. Dunno how this should go on. Other than that, a quick review: Perhaps hiding the Restart button would be nicer for multiplayer. "New map generation" and "Same map generation" would be more clear to players than "Reseed". The Seed property is also used for the random number generator in general, for example the spawned hero in regicide, so skirmish maps will spawn the same one. The Seed setting was changed to use randIntInclusive or so. The AI seed could also be regenerated. Replay saving should be checked (iirc EndGame and StartGame take care of that already though) playerID variable not needed / can be inlined. Don't remove the resign comment. Dunno if it is. Menu -> Exit -> Single Player -> Start Match -> Start. 5 clicks does the same as these proposed 2 clicks. If the player wants to change any other setting besides the seed, he will still have to go through that route. We don't have a way to start the same map with the same Seed, so that'd be something new. Also I recall FeXoR saying that we could offer a Seed setting in the match setup. But that might also lead to confusion (as players dont necessarily know what a seed is) and that changing the teams, civs or other match settings makes the Seed setting irrelevant (misleading that it ends up with the same mapgen) and also would require a way to automatically reset the seed unless really wanted by the player. Dunno. Could be committed I guess if it's so desired.

Noticed and mentioned that too, it's reproducible for others but not reported yet. It was mentioned in D332. Unfortunately the problem didn't solve itself yet.

Yes

Most GUI magic numbers and strings are non-const globals and can be changed from an external file directly. In the simulation it's more tricky, but it should be possible to change prototype variables with a trigger script or custom mod system component directly for example. There might be more systematic and/or nicer approaches.

The ApplyValueModificationsToPlayer function was removed in r19924 and delenda est has a copy of Player.js. The only change in the copy is the maxpop = 500. @wowgetoffyourcellphone this max pop change doesn't work, does it? It's the gamesetup determining that right? IIRC it's different for skirmish/scenario and random maps. Modified copies from the public mod always run into that issue. A modified copy of population_capacities.json might do the trick already, dunno.

"this project took three years which is longer than we ever worked on a project before"

For both maps we have to keep in mind that both bots (for singleplayer folks) and new players should be able to enjoy the map, even if they ought to be wiped out by gaia after like 20 minutes. This way they are motivated to improve when they see that others survive longer. For danubius the idea is that players should eventually be able to overcome the gaia attacks, which is the reason why there are at most 1.5 ships per player with at most 30 units on board unloading at most all 8 minutes with at most 2 rams currently. (I wonder if it's too discouraging to attack though since all gaia 1.5 * players gaia ships attack the one player that tries to cross the river. So players are forced to spam many empty ships). We had that problem in the previous alphas too and I didn't figure a solution for that. Enemies 2x as often and spawning treasures 2x as often? Not sure if that might work as we can't speed up the construction & building repair rate, unit spawn times etc.

Re questions: 1. Simplicity. You can set the number of relics in the matchsettings. Unless you're playing a "relic hunt" game to accumulate bonuses, the best number is probably 1 or 2. 2. Relics are placed by a script, so that it works with random map scripts, so that the locations are different each gamestart and so that we wouldn't have to edit all non-random maps. However skirmish and scenario maps don't break if they come with relics at the gamestart (last time I checked). 3. The timer is reset once a team doesn't hold all relics anymore. Re suggestions: 1. Yes please 2. Indeed that has been proposed often. But there are some points which make it less important: a. The relics are not visible in the fog of war. Finding them and paying attention is the biggest part of the objective before they are all captured. Once they are captured, you'll have to scout the enemy bases directly, in which case you're more looking at your invadors rather than the minimap to begin with. The minimap icon would still be a nice-to-have feature for both players and observers. It's just not too trivial to implement it. The relics are currently marked as purple, so that they stick out somewhat. Pinging @Sandarac in case he as the author of the feature has something to add.

There are replays where players had won the game after losing all but 15 units. This becomes especially more likely in team games. The best strategy as an opponent to find the last units is to scout the map with like 10 cavalry, each heading into a separate direction. The current spy feature only focuses on trade carts. Revealing all enemy units for some time would also be interesting if it would be extremely expensive and help with that situation.

Currently only Survival Of The Fittest, Polar Sea, Danubius and Gallic Fields (3) spawn gaia units repeatedly after the gamestart. But it is planned/wished for to add a gamesetup option to spawn them on all maps and to have a difficulty setting in the gamesetup. Gallic Fields (3) only spawns a handful of roman swordsmen which become irrelevant after the first 15 minutes. Danubius does spawn unit types at random. Polar Sea only wolves. You might want to try Survival Of The Fittest. That was reworked in Alpha 22 too and now also spawns units like the fire raiser which were never seen ingame before. I hope we will see replays of good players of that. We played it a lot in Alpha 21 but the problem is that it always ended up in infinite games because gaia was too soft in late-game.

Danubius is the precursor of a great storymode, isn't it? Unfortunately it took weeks to implement the map and attackers. Campaigns are usually scenario maps, so it will be at least a bit easier to create than a random map script. A good campaign would also include some story, subtitles and cinematic cutscenes. Would be great to have that possible to play in multiplayer too, but that has the problem that we can't really script the opponent if it can be player-controlled. For the "King of the Hill" gamemode, checkout the map Extinct Volcano with rising water. We should have something like that where players have to fight for a hill (that is more usable than the volcano on that map). The water could also recede after some time which would allow players to capture their old buildings.

> can you please sum up and illustrate simply? been trying to figure out the frequency of Gaia unit spam in land and sea. In case the description in the code isn't simple enough, it should be rephrased. (The balancing changes from alpha to alpha and is expected (just as survival of the fittest) to require changes later. So it should be possible to fix the balancing even without understanding the code.) CC Attackers: /** * Time in minutes between two consecutive waves spawned from the gaia civic centers, if they still exist. */ var ccAttackerInterval = t => randFloat(6, 8); /** * Number of attackers spawned at a civic center at t minutes ingame time. */ var ccAttackerCount = t => Math.min(20, Math.max(0, Math.round(t * 1.5))); So time * 1.5 units (-> minute 10 = 15 units), but at most 20 units spawn at the civic centers all 6 to 8 minutes and are ordered to patrol near the map border (so players are attacked from all sides as opposed to only from the river). They stop spawning once the CC is captured or destroyed. Ship Attackers: /** * Time between two consecutive waves. */ var shipRespawnTime = () => randFloat(8, 10); /** * Limit of ships on the map when spawning them. * Have at least two ships, so that both sides will be visited. */ var shipCount = (t, numPlayers) => Math.max(2, Math.round(Math.min(1.5, t / 10) * numPlayers)); /** * Order all ships to ungarrison at the shoreline. */ var shipUngarrisonInterval = () => randFloat(5, 7); /** * Time between refillings of all ships with new soldiers. */ var shipFillInterval = () => randFloat(4, 5); /** * Total count of gaia attackers per shipload. */ var attackersPerShip = t => Math.min(30, Math.round(t * 2)); All 8 to 10 minutes the script respawns ships so that there are at least 2 but not more than 1.5 * players ships (so at most 12 ships when playing with 8 players). There are 2 * time attackers per ship (i.e. 16 attackers minute 8), but never more than 30 per ship. All 5 to 7 minutes the ships unload. One more thing to note is that the script doesn't distinguish between alive and defeated players. So there are still 12 ships if there are only 2 of 8 players alive. Ships only land units on that side of the river if there is at least one Unit on that side. Otherwise they patrol the sea forever. Attacker composition: /** * Likelihood of adding a non-existing hero at t minutes. */ var heroProbability = t => Math.max(0, Math.min(1, (t - 25) / 60)); /** * Percent of healers to add per shipload after potentially adding a hero and siege engines. */ var healerRatio = t => randFloat(0, 0.1); /** * Percent of siege engines to add per shipload. */ var siegeRatio = t => t < 8 ? 0 : randFloat(0.03, 0.06); /** * Percent of champions to be added after spawning heroes, healers and siege engines. * Rest will be citizen soldiers. */ var championRatio = t => Math.min(1, Math.max(0, (t - 25) / 75)); After minute 25 there each Gaul hero might appear (but no hero can occur twice simultaneously), certainly after 60 minutes. There can be 0 to 10% healers per ship / CC wave. After 8 minutes, there are 3% to 6% siege engines per ship (i.e. one or two). Before 25 minutes, there are only citizen soldiers, but then the number of champions per ship increases until after 1h there are 100% champions (besides hero, healers and siege engines). Gaia Defenses: The buildings are garrisoned only at gamestart. The defensive ones with random champions, the houses with random ratios of women and healers. var gallicBuildingGarrison = [ { "buildings": ["House"], "units": [femaleTemplate, healerTemplate] }, { "buildings": ["CivCentre", "Temple"], "units": championTemplates }, { "buildings": ["DefenseTower", "Outpost"], "units": championInfantryTemplates } ]; The CCs get a bunch of random champions to defend at the start: var ccDefenders = [ { "count": 8, "template": "units/" + pickRandom(citizenInfantryTemplates) }, { "count": 8, "template": "units/" + pickRandom(championInfantryTemplates) }, { "count": 4, "template": "units/" + pickRandom(championCavalryTemplates) }, { "count": 4, "template": "units/" + healerTemplate }, { "count": 5, "template": "units/" + femaleTemplate }, { "count": 10, "template": "gaia/fauna_sheep" } ]; The CC defenders and ritual participants are set to defensive, so if you retreat, they will retreat as well (otherwise it would be easy to lure them into your defenses). Gaia Ritual: The number of units at the ritual place depends on the mapsize (maleCount used for every skirmisher, fanatic and healer (unless there was a weird 'wall placement' bug): let mRadius = scaleByMapSize(4, 6); let femaleCount = Math.round(mRadius * 2); let maleCount = Math.round(mRadius * 3); > Ships spam in proportion to the highest tech/phase of any player imo Just as on Survival Of The Fittest, all players should have the same chance of being destroyed, so it depends on the players abilities whether he/she can survives Gaia, is able to cross the river and destroy the enemy.

The hashing of the password is done in JSI_Lobby::EncryptPassword and the PBKDF2 algorithm is used, which still appears to be secure. The hashing only protects the players from having their original password leaked in case the lobby db is leaked. But if an attacker gets the players config file, he can just use the hashed password to connect with that account. Implementing N different ways to protect the user pw that only work on a subset of supported OS seems like too much work to be supported for a long-term realistically. Also if someone hacks your computer, then the keystore is most likely accessible too, so it wouldn't help much.

RE WhiteTreePaladin: > There definitely were hundreds and hundreds of units. Yep, just looked at the code and the FAIL case is true - forgot to add the check whether that side of the river has any units on it for the CC units (it was implemented for ships at least). Thanks for the report (We never had this case when testing) > was just a free for all (That case with spawning indefinite units on one side of the river can still only occur if the game isn't won after one side of the river was defeated, i.e. more than 2 teams or equivalently FFA). > Generally the AI can survive if there are teams and often does not survive when alone. I was worried Petra was overwhelmed most often. Relieved to hear that! > The lag is pretty bad If there are too many units, that's definitely the foremost cause. > It's quite a fun and unique map though. I really do like it Thanks > new map category We have a map filter "Trigger" for maps with trigger scripts (they can occur on every map type). > for players that don't want anything but a pure random map, it could provide a nasty surprise Yep, odd maps showing up when using the random filter can be a problem (for example with Survival Of The Fittest, Extinct Volcano or Polar Sea too). However if we exclude the maps from the "Default" map filter, then they will be even less discoverable. (I was thinking whether to rename "Default" to "Land Maps". We might then add "Land Maps & Not Trigger" maybe, but that sounds ugly). Still wouldn't mind to see more replays :-) (The only thing more entertaining than playing this map is spectating a match on that map)

Thanks for the report. The HTTP interception of the hardware info transmission would require the attacker to be a Man-In-The-Middle, at which point he's tracking the target directly already (and then only that one target (or sitting in front of our server which would require him to do worse things already)). Don't see a reason to push out a release quickly for that. It would be safer to disable the UserReporter while noone maintains it. daker had also reported on 2017-06-28 that we still use an old django version for the UserReport tool and it was discussed with Philip.

Indeed. (Ping @Sandarac @mimo)

The balancing is tuned for experienced players. So it's like survival of the fittest for the bad to mediocre players and the better ones will overcome gaia eventually and be able to defeat their enemy. When testing, the AI often succeeded surviving gaia, but sometimes was completely crippled by stupid things like a tower of the stronghold reaching into the territory and the AI suiciding every unit one by one into the fortification. The lag is definitely increased, both graphical (many actors) and simulation (unit spawning). There were lag optimizations (not using the TriggerHelper function which uses the slow Footprint component to check for irrelevant spawn positions). Not sure how much it can be improved, but it didn't seem too bad to me. > had to be a couple thousand or more gaia units roaming That should (TM) be impossible. Should be 50-100 if one side of the river is wiped out. The gif at D204 is expected be representative. The ships stop ungarrisoning units on that side of the river, if that side of the river is wiped out. However looking at the code, it seems that that the civic center attackers don't have that check. In that case: Fail. Should only run into that situation if there are more than 2 teams at least. Here the exact, hopefully very easily understandable manifest of how many units spawn at which time: Since I'm really into Danubius replays: Can I haz?