historic_bruno

Are you using build-osx-libs.sh? It passes --without-libtiff to wxWidgets configure so that shouldn't be a problem, and also sets builtin libjpeg (the one bundled with wxWidgets). So unless those flags aren't working or there's a bug in the configure script, neither of those problems make sense.

That and other command line options are explained in binaries/system/readme.txt.

What exactly are we referring to, extremely detailed graphics, or the painted aspect of those graphics? I imagine some artsy effects could be produced by shaders though I have no examples in mind. Drawings and voice overs aren't really technically challenging, the only thing there is needing artists to do the work (oh, and we would need campaigns implemented ) Do you mean background images derived from gameplay scenes? In fact, I would like to see something similar in at least one case: an actual rendered scene of the game for the graphics settings menu (to see how adjusting things affects quality) For that it might be handy to have a way to "export" a scene in 0 A.D. for later viewing with all the correct meshes, textures, materials, etc. Considering that series started in the 90s, it's not fair to expect "modern" level of graphics in those games, is it? By the way, you can get most of the changes in the HD edition for free, but by no means did they rewrite the whole game for modern hardware which would be required to even reach 0 A.D.'s level.

It does, and should be fixed (efficiently). Punjab has always been a good map for reproducing this, because there are big clumps of grass that "pop" into view as you explore what looks like open terrain.

I've gone ahead and split this off into the Game Development & Technical Discussion subforum, which is a good place for this You could also use IRC as niektb suggested if you're impatient for answers (Philip could go into quite a bit of detail on this subject), but more people participate on the forum and it's better organized.

To be clear, 0 A.D. the game is the combination of an engine (Pyrogenesis) and one or more mods. Many of the things you are asking about could actually be handled by modifying existing scripts or writing new ones, with a simple text editor if you know or learn JavaScript (distinct from modifying the engine which is written in C++, although they are rather closely coupled at this point) Loose guideline is that things like rendering and gameplay components where performance is critical are implemented in the engine; the rest of the gameplay logic is scripted in the mod(s). GUI engine is in C++, the GUI pages you see are defined in scripts/XML. Here's where I have to point those who are curious about modding 0 A.D. for the first time 0 A.D. Modding Guide It can lead you to answers for a lot of other questions. I would say yes, with caveats. Most units in game rotate instantly, appearing to turn is only a graphical interpolation (it has no effect on gameplay) and they really just point toward their target all the time. We do have a special unit motion for flying things, I suppose could be adapted to ground units as well, but it has no pathfinding per se. It's implemented as a mod script, overriding the default movement. However, I would really like these parameters to become part of the basic low-level unit motion. As you say, things like siege weapons, ships, and even charging cavalry can't instantly turn or stop. All things to consider in the pathfinder design. This is definitely possible, with the right modifications to UnitAI and the Attack component. It should be possible to have units that enter the Attacking state and remain there until ordered to stop or e.g. fuel runs out. Damage could be determined by having a range that is the length of the beam, find entities that enter that range, then filter them out if they're not in the actual path of the beam - no idea how severe an impact this would have on performance though. If there are a bunch of these proposed units, then you might want engine modifications to handle it more efficiently. Control might be tricky, there is no way to just point a unit in some direction without ordering them, unless we add some kind of "turn" control, this all depends on how you envision it behaving. Visually, I think the particle system may already be adequate for this, especially for flamethrowers (the flame would be a prop, selected by the attack state in UnitAI, nothing to do with existing ranged attacks that function quite differently), I'm not as sure about e.g. laser beams. That sounds like mostly a GUI change, though building without workers would require some script modding (if you do require workers, it's easier, just need to search for some to assign the task). Nothing special needed from the engine though, AFAIK. They already do, notice the dirt, mud, or stone that appears where buildings are placed? You would have to be more precise about what you want, it will always be "possible", but maybe not easily or efficiently without some other changes. agentx's work on AI building placement could be relevant there, see Urban Development

Yeah, turn lengths are hard coded right now, 500ms in multiplayer games and 200ms in single player games. The reason for the longer multiplayer time is simple, network latency It's not a correct solution though, because latency will typically be much less than 500ms and sometimes more, so the game should adjust to the actual conditions (this feature request is buried here) Also, please start a new topic next time, this isn't a general discussion topic but a specific (invalid) bug report.

Committed a fix for this in r16380. To enable SDL's right-click emulation on Macs, add this line to your local.cfg file: macmouse = trueThen you will need to reassign other hotkeys that use Ctrl+Click, I would suggest using the Command key (Super): [hotkey.selection]remove = Super[hotkey.session]attackmove = Supergarrison = Superautorallypoint = Superdeselectgroup = SuperBut of course, you can use whatever you prefer.

I think ranges should be shown in several cases, but not at all times to prevent clutter: * When placing buildings: ranges that affect building placement e.g. minimum/maximum distance constraints Here's an example from Rise of Nations, farms have to be placed near a city (thin red circle shows the range): * Units with auras: always visible for heroes by default, for other units with hotkey or when selected * Buildings with auras: visible with hotkey or when selected * Other: attack range, healer range with hotkey I also like the idea of highlighting entities currently being affected by auras (not simply when they're in range, as effects could be timed or have other limits).

This if fixed in r16372.

Did you install libsdl2-dev?

Are you using the default hotkeys to rotate buildings?

I also noticed this during the staff multiplayer games, very glad it's not a "feature"

Did you build the game? If not, you need an autobuild after r16315 to get the fix (r16325 for instance). It only fixes window resize or fullscreen toggling issues, if you're reporting an issue just by moving the camera, then it's a separate bug.

These civs have been proposed before and so have many others, that's the easy part, in fact a lot of people want to see their region/ancestry represented. It's up to someone putting in the work to research and design them, and most importantly take the lead and follow through with the project long-term I guess what I can add from an 'inside' perspective: we're not looking for new civs to implement, it will be more than enough work to finish what we have already (some have been of the opinion we have too many civs - when I joined the project, we were only planning 6 civs for part 1! Former designer/lead decided to bump that number over time, but we're not in the position to continue that trend now) Adding a civ is definitely a lot of work, not like a week long project but months/years. That shouldn't dissuade anyone but rather challenge them if it's something they want, but it does need a leader. Check out all the work that went into making the Mauryan crowd-sourced civ a success. One thing is the topics seem to be forgotten, maybe someone should organize proposed civs with links to the topics, for reference and to prevent them being forgotten if they aren't bumped for a few weeks?

There is a patch currently under review: http://trac.wildfiregames.com/ticket/2692 In the meantime, don't resize the window or switch between fullscreen and windowed?

That's a cool story, thanks for spreading the word about 0 A.D. Testing and bug reports are always welcome contributions (see our Trac page as a portal for bug reports and other contributions).

I wonder how well the game would run on one of these Android mini pcs? I've had it barely run on a Raspberry Pi (not practical), but recent Android PCs-on-sticks appear to have much better specs like multicore CPUs and more RAM.

A lot of places still have slow internet, whether rural areas in countries like the US or developing nations, and in some places bandwidth is still relatively expensive. Even if 95% of our users (an example, I have no idea what the actual stat is) have faster than 56k bandwidth, it's no excuse to not consider network efficiency of the game. After all, if it's playable on slow connections, it should be even better on high speed broadband, while minimally impacting other things like streaming and file downloads. It's just like there's no excuse for memory leaks even if many users have 64-bit OSes and memory to spare, or badly inefficient code even if it's not as noticeable on the latest CPUs. I haven't seen evidence that bandwidth is a cause of lag in 0 A.D. mmultiplayer games (there was a report of building walls causing a disconnect in one case), but our multiplayer implementation could certainly be improved, by adapting to the players' actual network latency for a more responsive and less jerky feel. That has been discussed, but it's not trivial, and as Nicolas says, it's not the most critical issue right now.

Hi, when reporting a crash, please attach the crashlogs, see ReportingErrors. Also mention what version of the game you are playing. On Windows, the game is a 32-bit build, so it can (and does) run out of memory at much less than 8GB, closer to 2GB in fact.

We already have a game manual that anyone can modify, on Trac http://trac.wildfiregames.com/wiki/0adManual It may not be the prettiest site, but wikis do seem to work fairly well for community generated documents (we could certainly adjust the theme to make it more aesthetically pleasing). The other ideas seem related to the lobby, I think an account management site for that would be very convenient. Right now, only mods/admins have access to that, as far as I know. There's no password change or recovery interface for users. Profile pages would also be useful, you should talk with the lobby devs and bounce some of the ideas off of them, to see what's feasible or not with the current system.

It only happens when switching between fullscreen and windowed mode? There's not a lot of information to work with in this ticket, not even an attached system_info.txt.

If you can learn C++ or JavaScript, you could write patches for 0 A.D. We don't have any C# code, and I don't think this "port" ever got very far.

I haven't tested this, but does .AI work instead of .Name? At least in game setup, the AI property contains the AI name.