historic_bruno

Bugs like this have been around for a while, because Atlas has a strange way of updating player data. If there's no Trac ticket for this yet, I'll create one.

I like the idea of ambient emitters, they could be tied to existing entities or placed specially in Atlas. The sound manager should definitely support this, it's common in many types of games. Currently I believe there is a single ambient sound of birds that is hardcoded somewhere and looped endlessly (in the GUI?). More advanced would be adding terrain specific ambient sounds, like you hear different sounds when mostly desert is visible, compared to forest, sea, or grassland. Special sound for a killed hero? That's a serious gameplay event. (we have audio\interface\alarmherodead_1.ogg and alarmherojoin_1.ogg - these are no good IMO, but we could add the code and use them as placeholders) Notification sound for defeated/resigned player. Sound for chat messages? Sound for diplomatic changes and tribute. For UI effects, a variety of sounds would be nice, clicks, buzzes, whistles, different controls could have different sounds. We may have some of these recorded already but not implemented in the code. Other UI sounds: Error messages and windows Invalid / unallowed actions, like clicking a disabled button or trying to place a building in an invalid location Sound for minimap flares

The patch was reviewed: http://trac.wildfiregames.com/ticket/1719#comment:7 It looks pretty good, just those issues to sort through, it will be great to have in the game

Can they be loaded in single player? If so there may be some debugging value to allowing it, but I agree it would be cleaner if it was disabled (with a message explaining it's not implemented). Also there's a ticket: http://trac.wildfiregames.com/ticket/1088

The problem is that it needs to apply to currently moving units, not only newly created or stationary units. Last time I looked, running was sort of a hack and nothing in the simulation actually stored whether units were in the running or walking state, so it required some changes to UnitAI and possibly how run/walk animations are selected. That's my vague recollection of it anyway, applying the stats mod is trivial

I think it's much harder than it sounds. Even if we had very realistic terrain simulation, and even if it could be scaled properly to the game world, would it necessarily make a more fun, more challenging 0 A.D.? In an RTS, the terrain is part of the strategy, so if it's random without any thought to strategy and balance, then I would say it's not going to be very fun in that context. However, it's not easy to formulate constraints on the terrain generation that preserve strategic elements. This is probably why many or most(?) RTS games don't have random maps. Any experienced map designer is going to be able to create a better map than the best random map generator, because they are not doing it only for aesthetics or realism, but for gameplay too. Needless to say I'm very skeptical about any map generation modeled on real world processes and their applicability to 0 A.D. (otherwise it's a very fascinating concept). I think it's well suited to eye candy demos and academic research, but has anyone ever seen it done successfully in a 3D game let alone an RTS?

You mean like http://trac.wildfiregames.com/ticket/1504

That's strange, it's reporting your graphics drivers are only OpenGL 1.4. Maybe try reinstalling them?

Thanks, can you attach your system_info.txt from the game's log directory? Is that the full synaptic history or only changes while trying to build 0 A.D.?

Similar report: http://trac.wildfiregames.com/ticket/1570 Which missing dependencies did you install? It seems one of those may be the culprit, unless there were updates installed in the meantime. My first guess would be issues with SDL or graphics drivers.

Should we? Sounds like something that needs to be argued for. What does it offer that we don't have otherwise? Is it a good fit for an RTS like 0 A.D.? Would it improve performance, is it scalable? Would paths be reasonable and what players expect when they order units to move? Would it integrate well with the long pathfinder? Would it work well with formations? Because we don't really need to simulation human crowd behavior (that has its applications, of course), we need predictable, fast, smooth pathfinding that complements 0 A.D. gameplay. If it does that, it will look and feel good and it needn't be realistic crowding behavior IMO.

That would be nice to have, in fact building most of the libraries on Windows is a pain We've discussed a few times setting up VC++ projects for them and having the source code in an SVN repo somewhere (part of the ongoing Git migration), so it would be simple[r] to build them with new compilers. Does this help? https://developer.mozilla.org/en-US/docs/SpiderMonkey/Build_Documentation#Specifying_compilers_and_compiler_flags (assuming it applies to 1.8.5)

Why only walls? Then people will say, "My units can't see through walls, but they can see through civil centers, fortresses, houses, etc." I'm not sure if that's a direction we want to go in, but it would definitely change the feel of the game, maybe it's worth experimenting with restricted vision like that. On the other hand, would it be enough to assess an accuracy penalty when attacking targets behind structures? That makes sense to me, there's no way accuracy would be unaffected by not having a clear LOS to the target.

Need more info, like error messages you receive or output from the terminal. Running the game windowed instead of fullscreen might help with finding the error. If it's really a crash, you should be able to break into GDB and then use the "t a a bt full" command to get the call stack (the most useful info for us).

You might be interested in the discussions here: http://www.wildfiregames.com/forum/index.php?showforum=18 or if you're interested in Ptolemaic Egyptians, see below Yeah that's a known bug, the UnitAI isn't smart enough to handle that case and the fauna just walk randomly around the map. As others said, there are other hotkeys for this, but you can also change the hotkeys to anything you want, see: http://trac.wildfiregames.com/wiki/Manual_Settings I don't think palisades are meant to be upgraded, since they are made of completely different materials than stone walls. This is something that gets suggested from time to time, but basically, we might consider it if we had the artists available with nothing higher priority to work on, but there's almost always something higher priority to work on... can't rule it out completely for the future though. Maybe you could contribute to the next civ which is being developed, the Ptolemaic Egyptians, see the Art Development forum. As far as I know, structures are still being worked out.

I think for herd animals this will be implemented as part of herding/corralling, see comments on http://trac.wildfiregames.com/ticket/1907 Not for all animals, it wouldn't make any sense for skittish animals like deer, aggressive ones like lions, etc.

I still say it's a driver issue (either wrong driver or a very basic one), do any other decent OpenGL games work on your system? I would ask on the Linux Mint forums, if nobody here is familiar with that distro.

If you can, open a terminal and use the command "glxinfo", and paste the results here.

Would like to get some input on attack icons in tooltips, see #1785 and this. Maybe the tooltips should be (re)designed first? They've been an info dumping ground for a while

The last I saw, Philip is working on the update scripts for *nix/Windows (that will pull in any precompiled binaries / autobuilds / bundled libraries required for developers). You can occasionally find updates in the IRC logs.

You could try an older version of Boost, though I don't think c++11 is a requirement for any Boost. Also if you weren't aware, the game has been built for Android before: http://trac.wildfiregames.com/wiki/AndroidPort#Otherdependencies

Great post, Yves! RedFox: I know the GUI example was just for demonstration but like Philip I get about 800-900 fps on the main menu with a 2 year old GPU, so I can't believe it's worth doing anything about the UI for performance reasons (there may be other good reasons, but then they need to be discussed in a different topic/context). Even a significantly slower system should have acceptable performance there. On an ancient c. 2004 single-core laptop with Intel GM915 graphics, I'm still getting 70+ fps in the UI, even considering that GPU is unusable with the game, but I don't think we should fret too much about that right now (especially since there was discussion recently and more or less everyone agreed dropping the fixed function pipeline would be no loss). My advice for anyone wanting to optimize the game would be to actually play it. Play it in single player with AIs, but know they are very stupid and inefficient currently, so also play it in multiplayer with no AIs. By playing I mean finish a game Huge combat demo is not really playing the game, loading one of the few maps with a excessive trees isn't really playing the game. You'll notice real world issues playing real world maps in a real world way. The last staff match I played was 8 players: 4 humans and 4 AIs, we all commented how smooth the game was, though the map was chosen to be lag-free as possible, I think it illustrates the point. The game runs remarkably smoothly for me in multiplayer games, though I'm not quite on a 2007 laptop, but many of the issues affecting my experience should be the ones affecting your experience and others in an even bigger way. It would be nice to focus on those first, rather than considering rewriting the renderer, or major simulation architecture rewrites. It might take more time before you understand what's going on and what needs to be done, but there are others around (like Philip) who have looked at these problems before, so you can use that knowledge and not be completely in the dark. No one is working on the short range pathfinder as far as I know, that's a major concern in battles, of which the huge combat demo is an extreme example. I would be interested if someone tried that map and then claimed GUI engine, renderer, or even fixed point math is the most serious concern or even a logical place to begin. Formations need redeisgning but they bring out the worst sorts of pathfinding issues, especially with large formations moving around static obstacles (the current long range pathfinder scans the entire map to find a tile is unreachable, and it might do this dozens of times per turn - a problem mostly solved with Philip's WIP patch). I ask what the benefit of a 20% gain really is in code that may take several seconds per turn because it doesn't scale? AIs aren't careful about memory usage so GC becomes a problem (significant intermittent delays), and the AI API doesn't expose all the functionality they need, so they have to do things like terrain analysis in JS, doing MBs of allocations - instead we should have a better C++ interface for AIs and move performance critical logic there. AIs should be multithreaded, pathfinding should be multithreaded - in both cases I think there are blocking issues before we get to that point, like upgrading JS or completing the pathfinder design. We should be more careful about how we schedule GC. Having a thorough benchmark mode would be great, so we could more reliably measure and report performance data. Having a better way to collect and analyze performance data from our users would be a boon - currently it does something like report data at the start of a match, if they enable user reports, it goes into a massive database that is never actually used There are a lot of tasks for an able C++ programmer that don't involve squeezing out small gains here or there because a profiler might indicate it's an issue, need to keep the big picture in mind as well.

I would suggest using an editor like Notepad++, because Notepad is truly awful. Make sure you save the file as UTF-8 encoding, supported by the game. The character you want isn't available in the game fonts yet (see binaries\data\mods\public\fonts), the available characters are defined in source\tools\fontbuilder2\charset.txt, which is used by the fontbuilder scripts to create the game fonts. When you press F2, you don't get the correct screenshot?

It appears that if you start a game, and then return to main menu, any more games will play the music from the first one, regardless of civilization.

Hmm, it would be nice to know what is causing that