historic_bruno

About the original error, do you have any fancy graphics options turned on? Do you have the latest drivers installed for your Quadro FX 1500?

They are all from A14.

About the error, can you attach the crashlog.txt and .dmp, from the game's log folder? (see GameDataPaths). You can zip them to attach in your reply.

That data doesn't look too unusual. ComputePath is a bit high, but probably what you're experiencing is intermittent lag (maybe every few frames) and simply wasn't captured there. What you could do is run profiler2, which has a web server built into the engine that streams profiling data locally to a tool that can be run in your web browser. It's not included in releases, but it's available in SVN: http://trac.wildfiregames.com/browser/ps/trunk/source/tools/profiler2 You need those three files, start the game and press F11 to enable the profiler, and open profiler2.html. I don't know if we have a tutorial yet for how to use it, but there are some details and screenshots here. When the game lags, you should be able to identify frames in the profiler2 tool that take a relatively long period of time, much longer than 15-20 ms. Those will be the cause of your lag.

Are you placing entities, not actors? (actors will be decorative, non-interactive props) Are you testing this in Atlas or saving the map and loading in-game? You say it's a new map but existing entities are interactive, can you explain what you mean and when you're placing the new entities? Basically if you can give us exact steps to reproduce what you're seeing, that would help a lot

Dropsite placement logic causes extreme lag in certain conditions. My friend was playing A14 on a single player random map, after opening the saved game and using profiler2 I see "Build new dropsites" takes about 2 seconds, and it happens almost constantly. That really shouldn't happen, even if the algorithm is slow, I would expect it to place a dropsite or two and then be finished. Maybe it's due to loading a saved game or some other known problem, but I'm attaching the saved game in case it helps troubleshooting (rename .zip to .0adsave). savegame-0002.zip

Yeah, that's the new gatherer limits, and I fully agree that it needs to be improved. Maybe you would like to comment on this discussion: http://www.wildfiregames.com/forum/index.php?showtopic=17461 I'm not sure that #1914 is gatherer limits though, it could also be the unit gives up trying to mine due to being obstructed, as would happen if there is a lot of gatherer traffic in the area (which is a bug).

Errors aren't automatically reported, the user report thing is just some details about your system specs and a very small amount of profiling data. See ReportingErrors for what you should do when you get errors What could help in this case is not only posting the error logs, they do help, but the commands.txt belonging to that match as well (found in the game's log folder, inside sim_log and organized by process ID, sorting them by date sometimes helps find the right one). That file can be loaded in the replay, to reproduce the errors, then perhaps wraitii can look into what is causing them.

Do you build the game from SVN or only use the release bundles? I have some theories, but it's hard to test any of them without a Retina display. If someone with a Retina display is willing to help test, it can get done faster It's already one of the top issues mentioned in the Known Problems (Please read before posting) topic.

Played several A14 multiplayer games today with a friend against Aegis. I think he was impressed by how hard the AI is now even on default settings, and overall how much it has improved from last time he played But we ran into a few problems. The OOS error is still there, and at least on our setup it happens practically every game The other thing we noticed was on certain maps, ally AIs will build their expansion CCs very close to our bases, and even surround them. This has the consequence of towers, storehouses, and other things we build on the edges of our territory falling into their territory and becoming damaged. That's really a flaw in our territory logic (it should do something different with allies IMO, allies shouldn't inadvertently damage eachother), but maybe Aegis could stay a bit farther away from its allies? I mean placing 2-3 CCs near my base is a bit crazy

http://trac.wildfiregames.com/wiki/GameDataPaths#OSX

Seasons may have been planned at one time, but that's an old document and we ruled them out, at least for Part 1 due to the large number of other higher priority tasks needed to reach that point. That's not to say that someone can't come along and implement seasons, but I don't think there will be any major push from us and it certainly isn't considered an important feature (day/night cycle is the same). Maybe as other gameplay features are implemented, if it looks like we'll have time and resources, we can re-evaluate seasons and day cycling.

I suspect the problem isn't strictly the high resolution, but the difference between "points" and "pixels" introduced by Retina displays. SDL should handle that automatically, but it's hard for me to test exactly what's going wrong without a Retina display.

If it is a retina display, I was hoping to have that fixed for A14, by switching to SDL2. That would at least fix fullscreen toggling and window resizing. But it currently breaks lots of other things and will take time to fix properly. So in the meantime, any work around would be appreciated (I don't have a retina display to test).

I would say it's certainly a graphics driver problem. Please make sure you have the correct drivers installed for your system.

Territories?

I don't think the height of the target should matter, since it's only 2D range testing (unless that has recently changed). What may have changed is the obstruction size of the whale, so the fishing boat can't get close enough, or the gather range may have changed. But if it's broken, someone should definitely look into it

Yeah, there are a few buildings where terrain bumpiness like that is noticeable. However, we have someone working on terrain flattening under buildings, see this short proof of concept video for how it might look:

Keep in mind that in multiplayer games, the simulation state on every client has to be identical (for out of sync testing, we simply hash the binary state and compare them). But AIs don't only react to the current simulation state, they also store data from previous turns. This means if you don't serialize the AI state properly (I would say fully) then deserialize it, like if someone rejoins in multiplayer or you load a saved game in single player, the AI will have different internal state, which very likely means it will send different commands. That will cause the simulation state to differ and an OOS error in multiplayer. In single player games, the problem is more subtle, the AI will simply behave differently after loading a saved game. Or you may get errors when certain code paths are hit requiring data that wasn't de/serialized. I actually don't see it as that difficult of a problem. It would require substantial modification of the AIs and their API to fix correctly (Aegis, like qBot and JuBot before, is based on Testbot, which was only a prototype AI that didn't correctly implement serialization and had flaws in the design that make it more difficult now). But those modifications are fairly straightforward for someone familiar with the AI.

Yes, and it will almost certainly make a difference in AI (de)serialization, which is one of the points I've been trying to make on that topic (see this comment)

And now the probable fix is in SVN: r13736 So if you'd like to try checking out the SVN repo and building the game, you could find out even sooner if it works

Great, thanks for that! Your CPU has an L4 cache, but our cache detection was limited to 3 levels, so it's a quick fix that will be in A14 (currently in feature freeze)

That could be my fault as well, I had edited my reply with more detail right after you responded Glad you got it working!

I had forgotten all about those! That really takes me back lol

I was able to get the berry bush DAE to import into Blender 2.65 after editing the DAE, as explained above. Apparently there is another PMD format out there with scripts for Blender, but it's almost certainly not the same one we use for 0 A.D. (which is our own creation and completely specific to the engine). Also, any PMDs remaining in SVN/Git are almost certainly skeletal models, and as PMD is a lossy format, there's no good way of converting them back to DAEs. Can you post an example of a DAE that you can't import into Blender after editing it (if necessary)? You can zip it first to attach here.