elexis

I did so in that commit! But even that is outdated by bb having implemented the C++ code for automatic resizing depending on screen size! r21379

First of all we want wraitiis patch in D11. It's nearly ready to commit even. The sooner we think about coop mode, the better. We should speak of campaigns instead of restricting us in advance. It's like with Atlas. If you start creating a map in atlas, you're stuck with that forever. Can't relocate or resize too well and if you do, there are issues coming up. It's one of the reasons why I'd like to use random map scripts that possibly use atlas maps as a basis for that. I will need some more months working on the old planned projects. But after that I will probably dedicate myself to campaigns. After some years of playing this game extensively and watching numerous documentaries on our civs, the history is more interesting to me now and I'd like to transport that amazing experience to the players. Will be a shitload of work however, IMO about 10 levels per civ, probably much more for Romans if we want to cover the history well. But then we also need narration, a little year number in the GUI, possibly dialog interaction and beautiful maps as level selection screen. Anyway, just the things I wish for that will take probably one more release before we can dedicate to that.

In the works, something similar to Danubius. I'm particularly happy about Skhorns map because I couldn't get any elevation model of this mountain anywhere on the net. The NASA blue marble heightmap has only 2 or 3 pixels for that area, the pictures are only topographical maps that we can't import, OpenStreetMap data useless too. So when Sundiata revealed that Skhorn has this mountain I was delighted as I can import this mountain using the random map script! hey did a good 3D model but they sell it, so meh http://www.learningsites.com/GebelBarkal-2/GB-hist2_CSS3-update.php

The problem with that is that the dropdown can exceed the screenspace this way and the players won't be able to select some civs then.

This reveals that you have done the very first generation based on that random map. It should be deleted since it is unused. If there is no "pyramid" in the XML file of your map anymore, you'll have to place new entities. As they are ruins, they were most likely moved. Perhaps they disappeared from the entity list by opening the map with the broken references and then clicking save.

We got at least one, at most two more weeks. But the sooner, the better.

Maybe the remaining team can adopt, finish and maybe improve this map next release. I've always wanted to see it and never lost my expectation that it is going to be finished. (It could become a random map script too by loading the PMP file created in atlas.)

r21353 adds 3 more civs to the dropdown item, which is the most we can display on 1024x768. There might already be a ticket or patch about automatic resizing (@bb_?)

Was looking around if I could help somewhere. I'd suggest to not copy gamesetup.xml. It's easily outdated (already the case) and then either breaks or doesn't get the new features. I noticed two changes. The first one is giving more space for the civ selection. I can commit that for mods. The second change is resizing the tab buttons. I can't offer that because the space can easily be used by translated strings. Obviously this isn't the final UI design yet either. But if you really want to change the size, you could it externally too. But keeping the xml copy around will only cause more maintenance trouble.

Treasures were moved to gaia/treasures/, ruins to gaia/ruins/, see #4770. You could open the XML file and replace it manually.

A map can't default or enforce playerassignments yet. You could try to do a mod or just add it to the gamedescription for now. The player is currently assigned to the first playerID. Entities that can't be selected ingame are called actors. They are just meant for decoration and should be placed where units can't reach them.

I will ask the rest of the team if we can commit this map after feature freeze too. Shouldn't be a problem in theory as it can't cause any bugs and shouldn't take long to review.

I'd take the map without alpha 23 models too.

Locking some player settings is not possible yet. The closest we got to it was probably the campaign patch which wasn't so far from being finished D11. https://trac.wildfiregames.com/wiki/Atlas_Manual_Starting#TheMoveRotatetool

http://trac.wildfiregames.com/wiki/SubmittingPatches https://trac.wildfiregames.com/wiki/Phabricator TLDR: Register, click on create differential revision somewhere. To get the new models, just checkout the most recent code on svn. http://trac.wildfiregames.com/wiki/BuildInstructions or the link Lion.Kanzen gave you. (As long as you don't change c++ code, you don't need visual studio)

You can upload it on Phabricator already. You can certainly place the buildings and units on your map.

Playtest not really needed, just start it and see if it gives a bluescreen of death or something like that. The map design is the decisive part. This skirmish map doesn't have to go through Phabricator, the latter can't test anything with it. Also committing works just as before, just that we add "Differential Revision: <url>" in case there was a phabricator page to the commit message. What is important is that the map is balanced between the opposing parties. On the screenshot I see some players with prebuilt cities and walls and one player with only a civic center. That is okay however if it's supposed to be a 2v2 and both teams have a player with an advantage and one without. Same for the resources, teams should have roughly the same access to resources. Also new maps get the keyword "new", so that they are listed under the "new maps" mapfilter. Don't forget the art.json entry in case. Commit this map for us, plieeeeeeeees Also does @mimesot know that we have the Kushite civilization now that also come with new pyramids? Not sure if it's exactly their territory however.

The github branch is a very good idea for maintenance. PointXZ was nuked because it was a duplicate of the Vector2D. The entity placement method was changed, like many other methods. A list of changes in alpha 23 is found here: https://trac.wildfiregames.com/query?status=closed&component=Maps&milestone=Alpha+23&group=resolution&col=id&col=summary&col=owner&col=type&col=priority&col=component&col=time&order=priority. Using what we currently have in rmgen is a necessity. I like maps inventing their own thing, but it should be so universal that every other map can be combined with this new feature. That the Placer, Painter and Constraint interfaces were implemented is a very good improvement. About the player territory border being harsh, you could use a ChainPlacer, that covers up bordes pretty well. Yes, we need those paths and I have converted FeXoRs path placement method from Caledonian Meadows to be a bit more reusable thinking about this and other maps. That mountain looks like it could use a second texture for higher slopes by using the SlopeConstraint once this is migrated to alpha 23. The latter has to be done sooner or later by one of us (https://trac.wildfiregames.com/wiki/BuildInstructions). The code of the oasis map looks much better now that the library code was removed. In alpha 23 we have a playerbase function, so you can replace those 100 lines with one function call and some values. The textures and template names should be constants at the top of the file. I'm not particularly fond of the TileObjectMap prototype as it reinvents what is covered by the library for a great part, as it has a very confined use case and is a global that needs to be initialized, kept in sync and used throughout the map generation. But Placers, Painters and Constraints should not rely on globals other than g_Map, receive all other data in the constructor. This way the the function becomes deterministic given the arguments. The heightmap is saved already in g_Map.height. The slope is currently only computed on demand since recomputing it upon each elevation change costs too much performance. If it must be cached, then it would better fit in the g_Map object so it can be reused. The paintMap method should not be part of the library as it's the meaning of the map if there can be such a thing as cliffs or something that only one map uses. findPlayersBases is playerPlacementRandom in the alpha 23 library. putRandEntities sounds a lot like createObjectGroups. putLargeEntity: the map should define what is large, small or very large, in numbers. putForestChunks should be Terrain painting or createObjectGroups. AvoidSlopeConstraint - there is a SlopeConstraint in alpha 23, AvoidAltConstraint - HeightConstraint. paintPointsArray -> createArea + MapBoundsPlacer + TerrainPainter. buildRoads -> this looks like the RandomPathPlacer We should aim at getting those 1700 library lines down to 400-600. But one step after another. I believe migrating to alpha 23 is the most urgent thing, because every line that is added now to the map has to be rewritten. So one can save time writing the lines only once. Since many functions were renamed, deleted, replaced and received different arguments, you can ask me on IRC what has changed for specific functions (https://webchat.quakenet.org/?channels=0ad-dev), or here if you want to. I assume this process won't be finished before april, but it would yield a high quality addition if done properly and will be reused by many maps. The new library should be part of the main library. rmgen2/ and heightmap/ are only temporary workarounds, put aside because they are some experiments. It shouldn't become three but one consistent library to rule them all :-) The randombiome library is the only one so far that is legitimately split IMO.

I fully agree (that's also true for the random maps, most of them are mediocre too). @niektb do you want to do the review of this map and commit sometime it in the next 3 weeks?

There is the problem that the night version is a duplicate of the daytime version. This means if there is one thing to fix in one map, the other one has to be kept in sync. So if the terrain is off and that requires manual brushing, that will be hard to keep in sync. The PMP file can be the same for both maps. But the XML file containing all entities would have to remain. I'm not sure what we can do there. Changing the environment settings from a JS trigger script would be great, but we don't have that code (yet). I guess we can just use both maps and if there is something to fix, trash the XML file, copy the original one and copy over the night-environment settings.

I didn't manage to read the thread or test the map yet, but the screenshot looks amazing. Please tell us your realname if you want that mentioned in the credits, otherwise we will only add your nickname. Scheduled at #5032

Clearly didn't see the milestone :-/

See alpha 23 milestone.

I read through the mapfile now. Two organizational things: At this point we might want to start using our code review platform instead, then I can post inline comments right in the code, might make things easier. http://code.wildfiregames.com/ A copy of the WIP library code in the map is not going to be committed by me. The library file counts 430 lines, the mapfile 1136 lines. The library must be removed from the map. A random map script should consist of a buch of texture/entity/height constants + 20-50 function calls. Lops should almost always be library functions. I suspect your demo map will be that short too if the code is sorted. I didn't test nor comprehend the basic idea of the algorithm yet. But here things I discovered when reading the file for the first time: About your HeightArray, we pass u16 arrays to the engine, so that should be the same limit here rather than u32. That can be more easily created using new Array(g_Map.getSize() + 1).fill(0).map(zero => new Uint8Array(g_Map.getSize() + 1).fill(false)); (for example). Changing this.mSize before an operation and reverting this change afterwards is bad practice, just create a helper variable or repeat this sum. Magic numbers like 10000 should be avoided. At least a global constant, but better letting the random map scripts determine the best numbers themselves. Is that histogram thing only debug code and can be removed anyhow? The duplication in HeightArray.prototype.createAltitudes should be removed using a loop, possibly a function. Whenever there are x and z, those should be in a vector. Most often one create the vectors in advance. Sometimes it improves performance, othertimes it doesn't. I haven't an inacceptable occurence yet and I don't want anybody to read ugly code to reduce the loading screen time from 15 to 12 seconds in the best case (some maps need 1-2 min). "tObjMap.gCells[j][Symbol.iterator] = function* () {" never seen such code, probably avoidable. I have some reading to do. https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/function* "var snowLimit = 32000;" that's a height right? In a23 I have moved most height constants to the top of the file and uniformly called them height*, i.e. `const heightFooBar = 3;`. They are grouped, so one can quickly compare their values and see which heights are used by the map immediately. for (let i = 0; i < mapSize; i++) for (let j = 0; j < mapSize; j++) Whenever we see that, we should think about transforming that into a createArea call on a MapBoundsPlacer. The effect on that area should be moved to a new painter in case it doesn't match an existing painter. This way it can be reused on arbitrary areas. In places where we only need to collect the points, we can save the result of a createArea call. if(test < idx) test = idx; Each statement on a separate line. if (g_MapSettings.CircularMap) { newline before the { while( space after while warn, log -> those are g_Map.log calls which also result in that thing being timed. let cent1 = (patches[dist.b1].barx - centPos) * (patches[dist.b1].barx - centPos) + (patches[dist.b1].bary - centPos) * (patches[dist.b1].bary - centPos); let cent2 = (patches[dist.b2].barx - centPos) * (patches[dist.b2].barx - centPos) + (patches[dist.b2].bary - centPos) * (patches[dist.b2].bary - centPos); That's exactly where the vector operations halve the width and height of these 2 lines and reveal geometric intent. (Isn't that a cross, product and perpendicular vector somwehere? I would have to interpret first) log("Creating base for player " + id + "..."); That entire loop is gone using rP20815 "crocodiles and palms on the shore" don't. That loop implements a custom coordinate randomization, but it should leave that up to createObjectGroups or createObjectGroupsByArea. One could implement a constraint for this g_TOMap.gCells[zx][zy].done check, though I'm not sure what that does and if it isn't redundant with tileclasses. I will test now.

Gimme gimme gimme! Everything is a vector now, especially the points to be placed at. The first random map script commit had introduced both the Vector2D prototype and the Point prototype, but I really don't know why the latter one was done when both objects don't store anything besides the two coordinates. The only difference is that z is now y and we can simplify equations by using the vector operations. If it contains functions that ought to be in the library, then we'll put it in the library. Otherwise we're just adding work for later. But that's not too much work for now. I can transfer it. Agree, luckily that only means doing map generations on different sizes, playercounts and looking unreachable entities or blatantly unfairly placed players. Indeed. FeXoR runs into that problem on Caledonian Meadows too, it often fails on tiny mapsizes. It's just more stable to first place players and then adapt the terrain accordingly. But I understand it's not always possible to achieve. (For instance on the geographic maps like Red Sea too). That's the case with all maps unless resources are distributed very homogenously. On your screenshot that guy surrounded by mountains and 2 lakes has a really bad map compared to the others. We could try to do something with forest density, but those are details. The saver of all boring flat maps: createBumps. Also createPatches / createLayeredPatches to randomize the textures a bit. The mountains should be painted according to Slope with the SlopeConstraint, I can look into it when adapting to a23. Another huge improvement are paths (consider the one on danubius for instance). Lorraine Plaine also shows how paths (here: rivers) can have a treeline parallel to them. It's just hard to try to find a path that doesn't break the terrain, so might need lots of retry loops which in turn can consume too much time. But there are remedies for that too (first computing placeable areas, then finding coordinates within that area, rather than picking random coordinates and testing against constraint that are highly likely to fail). Tiny maps with many players are a gimmick anyway. Most maps just place CCs and 10 trees. That's more problematic. Eventually we will need some reachability test. I also ran into this problem bigtime when reducing the radius of the playerbase flattening on Ambush and had to add a ramp so that the players can reach a nearby bluff (so that they can't be surrounded by an impassable bluff) #4993. A nice solution would be to somehow detect the unreachable case and use createPassage (a23 function) or a PathPlacer + elevation setter to force a way to somewhere else. But tricky to achieve and likely messy (typically paths should be placed first too and terrain only placed around it). Whut? Let me see. (I'm really missing a new centered placer, we only have the two ones, ClumpPlacer and ChainPlacer, which were iirc present when rmgen code was in C++ 12 years ago). Thanks for the update!