historic_bruno

I think this would help, not yet for random maps because the algorithms assume 1-tile footprints when placing clumps. It would need to access templates for that, maybe, or else have it hardcoded. At least it would make forests-as-obstacles slightly more practical. I'm about to commit a change to Cantabrian Highlands that will show some progress made. At least I can generate even a giant map with only 5k entities total, and it doesn't look too bad. Having a river or two will help even more since they form a natural barrier without the high cost of trees.

Thanks for the feedback! This is exactly what's needed to improve them I think it should be possible to have a map filled with trees with no adverse affects. That's just my opinion, but right now there's memory and performance issues It's hard because the maps have to scale over several sizes with between 2-8 players, but if there's a tiny forest on a huge map, the players might not even find it. I guess more scattered trees would help, and maybe some less circular clumps of forests. I'll start tweaking them.

Great video, Pureon! It really shows some of the graphics improvements we'll have for Alpha 5. Ah, that's useful information. I can change the random map scripts to use single mines if we prefer those. Actually I had to guess about what assets to use, since most had been renamed or deleted, and I'm not really a map designer.

I like this, it helps the mines stand out more. I don't see the sparkle on the mines in the random maps, they must be using a different template (the wrong one? gaia/geology_metal_greek )

Unfortunately we'll need crash logs to make any sense out of it. If you're in Windows the logs should be in %appdata%\0ad\logs or in Linux ~/.config/0ad/logs.

Also, you can open the console with ` key, and type in Engine.SetSimRate() and pass it a value like 20.0 or 100.0 or something I find that works a bit more reliably than time warp and also it doesn't eat memory.

I like it

Right

Random maps integrated with Atlas now in SVN trunk. Also some additional modifications to the UI, as seen here:

Cool, I gave it a try. It would be awesome if you could make some siege equipment to go after enemy buildings Possibly attack more often and different players. Also who is constructing towers? Females shouldn't be able to build towers by themselves (only a soldier can do that). Not sure if that is an AI behavior issue, or more like a failure of a lower level component.

Hope that will be scripted so we don't have to hard code all these different scenarios in the engine

A few suggestions for improving TestBot and the AI system generally (including UnitAI): Resource collectors will walk all the way across the map to find the nearest resource of the type they want, even if that's in an enemy base! I can't think of many situations where this is a good idea: It takes a long time to reach the destination and by that time the target resource is often gone anyway. Some resources just aren't important enough to risk losing villagers, for example berry bushes. It's quite simple to acquire food by other means. How does the AI know there are resources far away? I think we want to restrict their "knowledge" of the world to what they've actually explored. So the AI will need to "scout". [*]If resources are far away from the base, build a drop site (mill or farmstead). [*]Soldiers can work too, so if they're not otherwise employed, they should collect resources and construct military buildings. [*]Units are able to become "deadlocked" in a few ways I've noticed: If many workers are assigned to construct a new building, others that are passing by may end up stuck while standing on top of the foundation, possibly being told to clear off by the UnitAI but refusing because they have other orders. Maybe we need to prioritize the orders. There should be a timeout so that if a unit can't accomplish an order in a certain time, they give up or wait for a while. If there's a narrow pass and units are going to and fro in opposite directions, they might by chance block each other and constantly try to move in avoidance, but they seem to mirror each other. This is oddly similar to RL behavior but we should probably be smarter than this

No Only using 1 PCIe slot for the graphics I think.

Log attached. system_info.txt

Suggesting a few more: Blood (nothing too excessive) Weather effects (rain, snow, hail, sandstorms) Large projectiles (maybe more exciting to look at if they leave some sort of trail or blurriness?) Dust/debris from large projectile hits

Ah, good thing I didn't start working on this, too I'm using Visual C++ 2010, and with our current version of premake I have to convert 2008 projects every time a source file is added or removed (requires several steps and 2008 projects seem to be broken anyway). That was enough for me to at least look at the new premake, but as the structure is totally different I didn't pursue it. It's great that someone else has! This will make a huge difference in ease of development on different platforms.

That would look nice, but I wonder how it would affect performance?

Great suggestions, thanks! That's what it needs to improve OK, I can change the setting to circular easily. The map scripts will need a bit of tweaking. Definitely agree with this. And the resource generation is funky, sometimes it's based on map size, others it's the number of players. This should be fixed before they are truly "playable".

Random maps now in SVN trunk

Here's what I'm toying with now for the skeleton of a random map script: 1. Written in JavaScript (same as simulation, GUI, and AI scripts) 2. Optionally calls LoadLibrary(), which will load scripts for map generator implementations. It loads a whole directory, e.g. "/maps/lib/rmgen/*.js" This lets us switch easily from one implementation to another and test new ideas. 3. Calls InitMapGen() to create the map data structures. 4. Does stuff specific to the random map, like placing mountains, forests, civic centres, etc. 5. Calls ExportMap() to send the results to the engine. Here's a simple RMS which would generate a blank map with 1 civil centre and 3 female citizens per player. It uses an rmgen-like API: ////////////////////////////////////////////////////////////////////////////// RMS.LoadLibrary("rmgen"); ////////////////////////////////////////////////////////////////////////////// // initialize map log("Initializing map..."); InitMapGen(); ////////////////////////////////////////////////////////////////////////////// var numPlayers = getNumPlayers(); var mapSize = getMapSize(); // place players in a circle var playerX = new Array(numPlayers); var playerY = new Array(numPlayers); var playerAngle = new Array(numPlayers); var startAngle = randFloat() * 2 * PI; for (var i=0; i < numPlayers; i++) { playerAngle[i] = startAngle + i*2*PI/numPlayers; playerX[i] = 0.5 + 0.39*cos(playerAngle[i]); playerY[i] = 0.5 + 0.39*sin(playerAngle[i]); } for (var i=0; i < numPlayers; i++) { log("Creating base for player " + (i + 1) + "..."); // get the x and y in tiles var fx = fractionToTiles(playerX[i]); var fy = fractionToTiles(playerY[i]); var ix = round(fx); var iy = round(fy); // create the TC and citizens var civ = getCivCode(i); var group = new SimpleGroup( [ // elements (type, count, distance) new SimpleObject("structures/"+civ+"_civil_centre", 1,1, 0,0), new SimpleObject("units/"+civ+"_support_female_citizen", 3,3, 5,5) ], true, null, ix, iy ); createObjectGroup(group, i+1); } ////////////////////////////////////////////////////////////////////////////// // Export map data RMS.ExportMap(SaveMap()); In order for the RMS to be recognized by the game setup, there is an accompanying raw JSON file: { "settings" : { "Name" : "Simple test", "Script" : "test.js", "Description" : "Simple test of an RMS", "BaseTerrain" : "grass1_spring", "BaseHeight" : 10, "RevealMap": true, "GameType": "endless", "XXXXXX" : "Optionally define other things here, like we would for a scenario" } } This is analogous to the ScriptSettings element of a scenario XML file.

Yes! Either of those are a great improvement IMO. But I agree having this at all is fantastic

I don't know what impact this has on reflections or rendering cost, but it seems like the best long-term strategy for water. Assuming you mean where the water heightmap intersects the land heightmap, water gets rendered. It could be forced parallel to the surface of the land, actually just below ground level, so we don't have "peaks" of water sticking up in a field by accident. Then we could have features like rivers that flow downhill, for instance I imagine in Atlas you would do something like select a water brush, optionally change depth and appearance (color/reflectivity/etc), and then paint it right across existing terrain. Atlas would deform the land slightly and raise the water heightmap appropriately.

wxWidgets should only be required for compiling Atlas, which is optional. Running update-workspaces.sh should configure everything by default so that Atlas is not built (unless you pass it the --atlas parameter).

Some warnings from a clean build in VS2008. They may be nothing to worry about but I'm going to post them here anyway because they: 1. annoy me, 2. may be useful in the future if bugs are found, or 3. may remind us of things that need to be done. LINK : warning LNK4199: /DELAYLOAD:zlib1.dll ignored; no imports found from zlib1.dll c:\devel\0ad\ps\source\ps\KeyName.h(37) : warning C4067: unexpected tokens following preprocessor directive - expected a newline ..\..\..\source\ps\Hotkey.cpp(181) : warning C4067: unexpected tokens following preprocessor directive - expected a newline ..\..\..\source\simulation2\components\CCmpObstructionManager.cpp(748) : warning C4100: 'r' : unreferenced formal parameter ..\..\..\source\lib\sysdep\os\win\wprintf.cpp(110) : warning C4265: 'FormatString' : class has virtual functions, but destructor is not virtual instances of this class may not be destructed correctly ..\..\..\source\lib\sysdep\os\win\wdll_delay_load.cpp(463) : warning C4946: reinterpret_cast used between related classes: 'UnloadInfo' and 'ULI' ..\..\..\source\lib\sysdep\os\win\wdll_delay_load.cpp(181) : see declaration of 'UnloadInfo' ..\..\..\source\lib\sysdep\os\win\wdll_delay_load.cpp(201) : see declaration of 'ULI' vfs_path.obj : warning LNK4221: no public symbols found; archive member will be inaccessible ..\..\..\source\network\NetSession.cpp(143) : warning C4062: enumerator 'ENET_EVENT_TYPE_NONE' in switch of enum 'ENetEventType' is not handled c:\devel\0ad\ps\libraries\enet\include\enet/enet.h(322) : see declaration of 'ENetEventType' ..\..\..\source\network\NetServer.cpp(335) : warning C4062: enumerator 'ENET_EVENT_TYPE_NONE' in switch of enum 'ENetEventType' is not handled c:\devel\0ad\ps\libraries\enet\include\enet/enet.h(322) : see declaration of 'ENetEventType' The last two can probably be fixed with a default case, which I think is a pretty good practice in general. Also I've fixed some warnings in other files that I haven't committed yet.

http://portforward.com/ Usually, your ISP will give you a router as well as your modem, sometimes they are combined. The instructions to forward a port differ from one model to the next. Most of the time it involves you opening a web browser, typing in an address like "192.168.0.1", then logging into your router, and changing the appropriate setting.