elexis

But then there were no surprise effect when we would announce to implement Kushites for alpha 23 rather than just randomly committing that on a tuesday night after months of preparation with the best contributors for the job at hand.

Guess you're looking for binaries/data/mods/public/simulation/data/settings/population_capacities.json That directory has some other settings files too. (But don't assume that our codebase is so clean that this is the only place that defines population capacity defaults :-/ I think one of the Player.js hardcodes a 500 fallback somewhere too)

We also have the bicubic interpolation function in rmgen2/ somewhere in case that helps. Yes, giant maps are totally out of reach currently. The number of entities itself especially. The pathfinder struggles if there are more than 8 * 150 player entities on a normal sized random map. Given that you speak of InitMap, you must still be developing with alpha 22. That is reasonable on one hand because the library in alpha 23 changes every day. But judging from the screenshots, your project matures and we should start to think about committing something to our codebase. What matters most to me would be to throw out all redundant code. For instance I assume there is no invention in entiy placement, is there? The SlopeConstraint was implemented in rP21085 and one can do a createAreas or createObjectGroups on mapBounds using HeightConstraint + SlopeConstraint + avoidClasses to distribute as intended. About performance, I have replaced the log() entries with a call to g_Map.log() which measures and prints the time between two log calls. This way we can identify performance bottlenecks immediately: #5011. It seems the most of the time (up to multiple minutes) are wasted in pointless loops: Picking a random coordinate on the map and hoping to find a lucky position that isn't in water or a forest. Instead we can compute all locations that aren't water nor forests and then pick a random coordinate within that location and test against the variable constraints. The biggest refactoring in alpha 23 is that all x / z coordinate pairs were merged into a Vector2D object so that we can utilize the vector operations; replaced all cos/sin operations with one rotate() function; especially the cross products, normalization and perpendicular functions are now much more transparent. This is expected to have a some performance cost attached (creating new objects), but in my tests it had actually improved the performance. Can you upload a more recent version of your code (so that we can pick it up later in case you get bored)? In case you intend to work longer on that, you could also create a github branch. In case you can clean that library to the essence, rebase it for the alpha 23 codebase (BuildInstructions) and add one good playable map within the next 2 weeks (maybe little longer, we don't know yet), we might add it to alpha 23. But don't rush things, take the time you need :-)

Tried disabling all graphics options, playing a smaller mapsize?

Modifying and distributing pyrogenesis is intended and allowed as long as credit is given and the source provided, see LICENSE.txt for details. I don't know Godot3 or their license.

So housing does fit or what?

As of #4950 we also have a logger showing how long each operation of the map takes. This way we can identify bottlenecks. How much faster is that bitmask invention? I fear the increased complexity might just make things harder to read and maintain. It's easier if all maps use the same style and all maps can use all features and benefit from the same improvements. Which arrays are we talking about actually? I never timed the RangeOp code used by tileclasses.js.

Ambush is one of my favorite maps due to those bluffs / hills, but the perfect circle around the playerbases is so ugly. Correcting an error (artifact) after it has occured is not really good, better prevent introducing that artifact. For bluffs I suspect we just need to set the failfraction to a much lower value than the current 50%, so that the ChainPlacer fails entirely if it runs into a playerbase, rather than returning all points around a circle of the playerbase. Same approach might work for your problem I suppose.

Housing capacity and Population limit was my first thought. We should pick terms that exactly describe what we mean and noone will have issues comprehending which variant we mean. which doesn't imply that other terms can't improve the situation. Keeping things the way they are just because we have learned it that way is not a good argument to not try to improve issues. Shouldn't matter in theory either if we can do a better game than the common one :-) Those terms are synonymous so uncapable of identifying the difference. The two population limits should be well distinguished, I share Gallaecio's view that there is more than potential confusion in the terminology we use. We can keep it shorter than 3 words however. Indeed "housing" implies that someone is housed by someone else (So that term might be correct for romans but not for celts?) On the other hand it's defacto what happens ingame, no?

One can also set Omnidirectional in the SoundGroup with stereo files. Good job Lion.Kanzen, awesome sound!

@LukeV1 Are you still around? I believe we should fix this issue for the upcoming release, otherwise many people will report the same crash that is hard to figure out initially. Since you already wrote code around that bug, would you honor us with a patch that just shows a human readable message instead of a crash / debug breakpoint? :-)

I'd take the unique terrain generation + sample map packet without the redundancy. I assume you're working with alpha 22 code, but that was rewritten for 5 months. I can rebase it, but I expect the TileObjectMap to be dropped and or merged. Caching the slope might be an idea, but should be measured if really needed (it's better to keep g_Map state minimal).

The SlopeConstraint is definitely on my TODO list, some maps (see above somewhere) already use it indirectly. And yep, I missed some smoothing functions too.

Totally :-) Well if you just want to paint terrain or place entities on things between minHeight and maxHeight, that is already trivially possible with paintTileClassBasedOnHeight and paintTerrainBasedOnHeight. One can do things in a split up process as well: 1. mark areas with a tileclass 2. do something unrelated 3. place things in the tileclass (stayClasses) So for instance a createAreas(new HeightPlacer(minHeight, maxHeight), new TerrainPainter(tForests), [stayClasses(clLand, 2), avoidClasses(clMountain, 2)]) or whatever floats your boat :-) The HeightPlacer is new in a23. Pyrenean Sierra and Corsica also do have slope based terrain painting and I'm looking into making a SlopePlacer for that, so that one can paint cliff textures depending on height easily. I'll take a look at your heightmap generation code to see what it should become. To me it sounds like it could become a Painter. But even if it's just a helper function or prototype would likely be sufficient too. I just don't want this opportunity to go to waste :-)

alpha 22 rmgen code was changed for alpha 23, but that can be changed quickly when we're done with that HeightArray.prototype.createAltitudes has some duplication, that should be unified with a for-loop (or array-function) (Math.random() * off) besides the unneeded parentheses, we usually use the random helper functions from random.js, it could be randFloat(0, off) TileObjectMap.prototype.paintMap receiving arguments is much better than before, but it still hardcodes meaning and limits what random map scripts can do. Is it true that this function does what paintTerrainBasedOnHeight does? then it could just be moved to each random map script. this fills an area with 'terrain' adding actors from 'actorList'. This sounds a lot like what the Terrain prototype in rmgen does. Take a look at how forests are created on most maps, for instance on mainland.js: const pForest1 = [tForestFloor2 + TERRAIN_SEPARATOR + oTree1, tForestFloor2 + TERRAIN_SEPARATOR + oTree2, tForestFloor2]; https://code.wildfiregames.com/source/0ad/browse/ps/trunk/binaries/data/mods/public/maps/random/rmgen/gaia_entities.js This means that one of the array items is picked at random in each tile of the given area. Some of the items are only a ground texture, other tiles additionally contain a tree entity. If that Terrain is passed to a LayeredPainter, one can create forests where the outer 2-3 tiles are only forest-border-like ground texture and all the inner part this semi-randomized forest. This way stuff could be deleted from your library while gaining more features :-) The magic key to placing anything is the createArea and createAreas call. You should really look into the SVN code, it had been cleaned for the past 5 months. I suggest to read the few prototype names and descriptions linked here, to find the capabilities and limitations of rmgen. Basically there are createArea calls which create exactly one area at fixed coordinates passed to a non-centered placer, painted by a painter in areas that meet the given constraint. createAreas creates multiple areas with randomized coordinates. By being able to combine these things arbitrarily, one has a very powerful tool at hand to create entities. https://code.wildfiregames.com/source/0ad/browse/ps/trunk/binaries/data/mods/public/maps/random/rmgen/placer_centered.js https://code.wildfiregames.com/source/0ad/browse/ps/trunk/binaries/data/mods/public/maps/random/rmgen/placer_noncentered.js https://code.wildfiregames.com/source/0ad/browse/ps/trunk/binaries/data/mods/public/maps/random/rmgen/painter.js https://code.wildfiregames.com/source/0ad/browse/ps/trunk/binaries/data/mods/public/maps/random/rmgen/constraint.js What we really want is your core heightmap generation algorithm I believe. Maybe it could implement a Placer or Constraint and then the map could use createArea calls with fully arbitrary terrain modification and constraints. If it totally can't fit into that scheme, we might think about adding it to that heightmap library, which is about the diamond-square algorithm.

user1, Hannibal_Barca and mapkoc. Everyone else busy playing, coding or not doing 0ad things.

Indeed nothing of interest in that file. Try disabling GLSL. Did you have that problem only recently?

That should be the easiest thing to implement with regards to the pathfinder and simultaneously the most important setting. Mountains for instance should also not be buildable. Even if we fix that garrison bug that allow players to reach unreachable regions, players can still set a foundation on a mountain and units will never reach it. Might even improve performance with less tiles being marked passable.

The accuracy issue in a21 (units didn't hit often enough) was because a bugfix was committed before the release without considering balancing impact. Slingers being OP is rather a relic of the time when any unit could destroy buildings easily. Mauryan warriors and ptolemian cavalry archer rush... when was that, 3 years ago? It's mostly an issue that we don't have anyone in the team doing any balancing maintenace at all. It needs dedication. The few active people we have are either developers or artists. Would be nice to have someone we can trust to give commit access to, but one typically also needs to know basic programming in order not to make a mess out of the templates.

@Itms, @feneur, it seems quite bad to not have that on our own pages. If archive.org decides to stop their service, history would be lost :-S We need to do something, maybe especially in the lights of the upcoming release.

Don't confuse me, 1212 works

We typically have 5 to 10 die hard lobby fans playing svn games once svn is more interesting than alpha 22. This will happen very soon for a23. They find all the relevant bugs and then we release with some of them not properly fixed sometimes, which we should try to avoid.

Well well.

Not in alpha 23 I'm afraid.

Using the entity limits? Then one can train more than 2, but at most 2 simultaneously. Not a bad idea, but maybe this unit could remain useful in the later ages as well. Maybe if the global vision & attack range reduction would be implemented for all units except the scouts. Might be a desired feature for alpha 24. (Same as counters in my view :-/) For alpha 23 I'd rather nerf the skirmisher cavalry accuracy and be done with it. If we add anything else, I'm sure the balancing will break even much further in some unforseen way than only one random unit being OP.