historic_bruno

Isn't there something like that already in qBot? I thought it used the data in the obstruction map for randomizing its attack routes. However, since it's such a common task for AIs to want random paths (instead of always the optimal one), maybe it should be part of the pathfinder API. I've lost track of whether Philip's current pathfinder design is uniform cost or not, but changing the cost of certain tiles would be one way of changing the path. His optimizations might require uniform cost.

Should be fixed in r11292, please test

That image is too low quality to see the error. Can you paste the error from the log? (interestinglog.html)

You can download the "Command Line Tools for Xcode" either in Xcode preferences, or separately as mentioned above, but it's the exact same package. As far as I know the scripts will continue working since the errors and most of the deprecation warnings have been fixed.

As far as implementing this game mode, I was thinking we could load the map similar to how MapReader works now for scenarios, then pass the map data (terrain, heightmap, entities) to the random map generator, using a special script to replace the "player start" entities with the starting structures and units for each player+civ, and finally return the modified data as we normally do. The harder part would be designing the GUI as described in the OP. I wonder if it wouldn't be easier to just assign players to open locations randomly or on a first come, first served basis? The new trig functions should be consistent on all platforms, it's not a question of rounding, it's a matter of SpiderMonkey not guaranteeing that identical trig approximations would be used on different platforms (there are CPU instructions for some of the trig functions). So Math.cos, Math.sin, Math.atan, and Math.atan2 are fine now and provide more accuracy than we need, unless someone can prove otherwise (Of course you don't have to use them, and they are slightly less efficient than before so don't overuse them)

It needs this.

One solution for that might be allowing map entities to conform to the terrain slope and/or specify their height. The map format doesn't support either yet Walls will probably need those changes to look good on hills, though your examples don't look bad really.

That might be a good idea

I "upgraded" to Xcode 4.3, it's nice because unlike earlier versions (I was using 4.1) there's no need to install it, you just run the app bundle directly. Apparently updates are deltas now instead of requiring massive 2GB+ downloads. Want to uninstall? Drag the app to the trash. This means that all the Xcode required files are bundled, including SDKs. Unfortunately this causes problems if scripts are looking for SDKs in the old /Developer/SDKs location. Prime example: Boost build scripts. They try to be clever and provide a simple "macosx-version" option that automatically searches directories in /Developer/SDKs for a match. So it works great with Xcode 4.2 and earlier, but suddenly breaks on Xcode 4.3 with an unintuitive error: error: "10.6" is not a known value of feature <macosx-version> error: legal values: See any mention of /Developer/SDKs or anything else remotely useful? I was shocked that a package like Boost misbehaved this way. Hope they've fixed it for 1.49, but either way my script has to set CFLAGS and LDFLAGS manually for Boost. I also had to update my build scripts, SDKs are now located in... wait for it... /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs. After that it works fine. Xcode detected that I had installed the "Command Line Tools for Xcode" package and didn't ask me to download them again. I did have to fix one Premake-related build error (11259) that only occurred with the new command line tools.

Did you change your graphics drivers recently? What's the output of running glxinfo in a terminal window?

Is the error like this? Sounds related, I'm not sure why it happens so quickly in Atlas, but takes hours in game.

I don't think pathfinding will have any impact on this, the new pathfinder is being designed to behave more or less identically to the old, except more precise and consistent. You can view the bounds discrepancy in Atlas, by going to the Terrain tab and choosing passability class "default". The way the pathfinder works currently, a unit can't cross from one passability class to another (from red tiles to clear, or vice versa), even if it started in an invalid class. Remember land ships? Same thing. So it's currently working as designed, but the exact definition of the passability class on round maps may be in error (perhaps a rounding error?) or the overlap may be intentional. Philip would probably know In short: if you place an entity in the unpassable area for "default" passability, it won't be able to move anywhere but in that area, and units outside the area won't be able to reach it, because it would violate the passability constraint.

That changes requires a rebuild (or you can use the autobuild).

Yeah, the existing checks in rmgen don't exactly match up with the passability criteria. Atlas has similar problems, you can place entities within the circle but not reachable.

Thanks for the report This bug has been located and we're working on a solution.

We've got replacements for sin, cos, atan, and atan2 now, see Math.js. They automatically replace the originals in simulation, random maps, etc.

Did you use the instructions here: http://trac.wildfiregames.com/wiki/LatestReleaseLinux#Ubuntu

Well yes, they've been updated. It's not easy to share though, since it involves moving and renaming things (maybe easier if I used Git?) Anyway that stuff will have to wait until after Alpha 9, I'll probably be helping review existing patches in the meantime. I would like to upload an official OS X bundle for Alpha 9 on LatestReleaseMac.

By "next" do you mean Alpha 9 or 10? I would say if a saved game is an old version not supported by the engine, then it shouldn't even be displayed in the GUI or else it should be clearly shown as an invalid choice. That seems better than explicitly complaining because it's not as if the player has done anything wrong.

Build errors and crashes are very bad, so we try to fix those as soon as possible

Plus there are loads of "out of memory" errors even on a Normal-sized map with 2 players, because there are simply too many entities. Larger maps won't even generate. I'd love a forest map though, someday Performance is another problem entirely. There are lots of ways of making this work from a technical perspective.

I don't know of any function for that, but we could add them to rmgen: getTerrainTexture(x, z) getTerrainObjects(x, z). In the meantime, you can access the data directly with g_Map.texture[x][z] and g_Map.terrainObjects[x][z]

Thanks for reporting this Fixed in r11207

That was just a choice made long ago and unlikely to change I've seen either Y or Z used as height equally in different applications (X could be used, too but that would be weird).

It's just the convention to have all the buildings facing in the same direction for aesthetic reasons, in other words facing towards the starting camera which is the same for all players (Mythos_Ruler was very insistent on that ). That constant might be defined in each separate file, but it should be moved to the rmgen library instead. Edit: Also AIs, I believe they layout their buildings in the same direction.