Ykkrosh

...and now I feel justified in spending so much effort on it, since it found an actual bug (in the ancient version of glibc used by Debian) (admittedly only triggered by code that we don't actually run in the game since it's been disabled for years). Anyway, looks like everything's back to building properly on all the platforms (except Fedora 12 for a reason I have no clue about), so that's nice.

Hmm, so I almost got the tests to work. The only apparent problem is it randomly fails half the time due to some issues in our CPU-detection code (presumably interacting badly with the build VM). I like having tests so I'll try to get that fixed soonish.

That probably comes from AtlasMessage::Position::GetWorldSpace calling CCamera::GetWorldCoordinates calling CCamera::BuildCameraRay. That tries to compute the 3D line that's underneath the mouse cursor, and it assumes the line is always starting at the camera's location and its direction is spreading outwards to hit a point on the far plane. With the orthographic camera, that's not right - it needs to compute a line which is always parallel to the camera direction, with the origin moved depending on the target point. I don't know exactly what maths is needed, but I think that's where the problem is.

Hmm, so they would overwrite their normal standard openal-soft (etc) with the newer version from OBS? It seems kind of rude to do that - the users just want to install a game, they don't want to unnecessarily upgrade some library packages used by other applications too. Also I don't want us to have the responsibility of checking for compatibility problems in those new packages, updating when there's security bugs, etc, so I don't think we should replace packages that are already being maintained by other people (even if all we're doing is copying their code and recompiling). Will do so. The original reason was that you could change the game into a whole new game just by modifying data files, so the binary executable is the generic engine (Pyrogenesis) and not the game (0 A.D.). But making one game is already way too much work, so I don't think we'll start a second any time soon . But it seems like we currently need a shell script anyway to avoid PATH problems (at least until the engine's fixed), so I'm not sure if there's a better approach than using "0ad" for the script and "pyrogenesis" for the executable. Thanks! I've added some instructions here pointing to the new repository - just need to test them all to make sure they actually work

(Changes here (it looks like I don't have permission to edit the original, only the :Ubuntu subproject, so I had to branch it again) - now it works in VMware which makes it much easier to test.)

The meshes and animations are in the standard COLLADA format (except for some old ones which are PMD/PSA). The file binaries/data/mods/public/art/skeletons/skeletons.xml defines the skeletons that the game can load, and the mapping from the bone names in the COLLADA file onto those skeletons. You can add any new skeleton shapes into that file - the game just requires that when you use an animation with a mesh, they came from the same skeleton.

...but I can run their Live CDs in a VM easily enough. Tried the Debian one and found a few issues:* Gamin (or FAM) needs to be added as a runtime dependency. * Running pyrogenesis_dbg from $PATH doesn't work - our code wants to find the absolute path to the executable but isn't smart/crazy enough to search through $PATH. Running "/usr/bin/pyrogenesis_dbg" works better. (At least it works as far as failing to set up OpenGL; r7791 may help there.) * It'd be better to run the game from a "0ad" command, since that's the name of the game. That could be a script that calls /usr/bin/pyrogenesis_dbg, perhaps. (Also adding icons into the Programs menu would be good.) I'll see if I can fix some of these myself tonight, and test the other packages too.

I don't have any of the systems to test on - is anyone else around here able to try them out and report (hopefully) success? I'm not sure that's true - e.g. this says i.e. binary compatibility is only guaranteed in one direction, not in the direction that these packages would make us rely on.

Welcome That might be an interesting thing to do - you'd be able to hunt some animals easily without chasing them all across the map, but it would effectively limit the rate at which you could hunt a group in a small area (since once you kill one all the others will be hard to catch for a while). We probably shouldn't put too much work into the animal AI, since this isn't a farm simulation game, but if we can do interesting things with the dynamics of hunting and make it slightly more fun than harvesting trees then it may be worthwhile

Added #516 for the terrain smoothing. Also added #517 to track suggestions from here and (when I find them again) elsewhere.

It'll need changes to the camera controls before it'd work properly - keep the height constant and adjust the view size when zooming (instead of moving the camera's position), and then I think it might be okay. If someone implements the controls and the mode switching, I wouldn't object to adding it into the game in some form

It looks like the camera's basically just pointing the wrong way. Also w and h are going to be measured in world-units (quarters of a tile), not pixels, so they ought to be smaller. Also need to call m_ProjMat.SetZero. This seems to work for me: float w = 64; float h = 64; float r = w/2; float b = h/2; float n = nearp; float f = farp; // orthographic matrix m_ProjMat.SetZero(); m_ProjMat._11 = 1/r; m_ProjMat._22 = 1/b; m_ProjMat._33 = 2/(f-n); m_ProjMat._34 = -((f+n)/(f-n)); m_ProjMat._44 = 1.0f;

Thanks! Comments are definitely helpful - I'd like to make the editor as non-painful as possible for its users Hmm, it's not obvious how to implement this. Maybe what it should do is keep the terrain at the edges of the brush unchanged, and only modify the terrain in the middle, to tend towards a smoothly-interpolated curve. Probably need to experiment with this to work out what behaviour is intuitive and useful. Yeah, needs to be fixed, but it's confusing You can use shift/ctrl/shift+ctrl keys to adjust the speed, but adjusting it automatically based on zoom sounds like a good idea. Terrain panel -> Visualise -> Passability -> default. Does that do what you want?

I rewrote the unit AI to use the new system now, which I think makes more manageable (it's still slightly more complex than I'd like but it's easier to control how it responds to the various events in every possible state). The user-visible changes are: * You can queue up orders by holding shift when clicking, and the unit will do them after it's finished what it's currently doing. * If a unit is attacked (and isn't already in combat), it will attack back and then return to its original task. * If a unit is building a farm, and has no other orders, it will start gathering from the farm once it's complete. There's still more that should be added (particularly automatically attacking visible enemies, and automatically moving to new resources after the current one is exhausted) which I'll try to do soon, but I think this works okay as a basic AI framework for now.

I think that's the case - it probably needs to implement a matrix like shown here (near the bottom). It's possible GetCameraPlanePoints needs to be updated too (it depends on FOV, which is meaningless with an orthographic camera). I'm afraid I don't know enough about graphics to know if this will really work, though.

My current understanding is: In here you imported openal-soft 1.12.854. A typical Ubuntu user will have already installed the universe package based on openal-soft 1.11.753. That means either the game will be compiled against 1.12 but dynamically linked against 1.11 (which is bad since libraries are often not compatible in that direction); or the user will have to install both 1.12 and 1.11 versions of the same package (which is bad since they'll duplicate code and fight over the same config files etc). If you imported 1.11 into OBS instead, it would break for Karmic users with 1.8, so that wouldn't fix the problems.It seems like the proper solution is that the 0ad package for Ubuntu version N should be compiled against exactly the same library package versions supplied by the normal (universe) repositories for version N, and anything else is liable to cause trouble, but OBS doesn't provide a good way to do that. Am I mistaken somewhere here?

I noticed another bug with under-construction buildings starting with full HP, and it turns out it's the same as this. When an entity template first gets used by a script, the engine caches the result of converting the template to a JS object, and it assumed templates were never modified so it was safe to cache that forever. It's true that templates aren't modified directly, but with inheritance they are copied and then modified (adding the child's data to the parent's) and it was copying and reusing the old cached JS object. So if an entity inherited from another entity which was loaded earlier, it would get the old entity's stats. Fixed locally; I'll commit soonish.

Do you mean something like resetting the camera to its initial position, or changing it to an orthographic non-perspective camera? Neither is supported at the moment, though I guess they wouldn't be too hard to add. (source/tools/atlas/GameInterface/Handlers/CameraCtrlHandlers.cpp implements the interface between Atlas and the camera, and it could have more functions to provide more camera control. Orthographic views would probably need changes to CCamera to compute non-perspective matrices.)

Atlas isn't compiled by default on Windows, since the wxWidgets dependency is a bit of a pain. See libraries/wxwidgets/README.txt and download and compile wx, then run "update-workspaces.bat --atlas" and build. (If you just want to run the editor and not necessarily compile it, you can either use the precompiled pyrogenesis.exe in SVN (which uses AtlasUI.dll), or manually copy AtlasUI.dll to AtlasUI_dbg.dll so self-compiled Debug builds will find it, or wait for #456 (hopefully I'll have time to check it later today).)

Yeah, currently the chickens easily outsmart the soldiers - you have to surround them with half a dozen men to stop them getting away. But it's not surprising the chickens want to run, given that you're trying to extract meat from them while they're still alive. It'll be more humane when we get people to kill the animals first, which ought to be pretty easy (just treat the chicken like a normal attackable unit, then have it turn into a corpse almost (though not quite) like any other unit and let people gather resources from its corpse). In the meantime, we can just advertise catch-the-chicken as a fun minigame.

Ah - and if you unring the bell while the units are still heading towards safety (but haven't reached it yet) then they should turn around and go back to their tasks, whereas units carrying out a normal garrison order shouldn't act like that, so it sounds like we do need a separate order and separate states for units that are running for cover vs garrisoning normally (even we didn't need a separate animation for them).I've started trying to implement some of this, though I thought it was best to start small so I just wrote a chicken brain. Try the Latium map and watch the chickens, and try sending some spearmen to gather from them.

Scout sounds like one to add to the list. Hmm, delete probably wouldn't need to involve the AI so it wouldn't be an order here (it would just force health to 0 or something). Town bell is interesting - maybe it's equivalent to simply selecting each unit and telling them to garrison in the town centre, so it would be the same as the normal Garrison order as far as the AI is concerned, or does it need to act slightly differently?

Some thinking-out-loud about how the unit behaviour should be designed and implemented: As the most fundamental feature, players should able to give orders to units (usually by clicking on targets or on buttons): * Stop * Move (to a target point, generally ignoring enemies) * AttackMove (to a target point, generally attacking enemies) * PatrolMove (move to point then repeat the patrol route) * Attack (either a target entity or a target point) * Gather * Build * Repair * Garrison (in a building or ship) * FetchGarrison (ships may need to move towards shore in order to let units on board) * Unload (let garrisoned units off) * Pack (siege equipment transforming between modes; can't respond to other orders while changing) * Unpack * Are there others that I'm forgetting? (Most of the stuff here doesn't need to be implemented now, but the design ought to allow it to be added without having to rewrite the whole thing.) Players should be able to give a series of orders (typically by shift-clicking) - after the first order is completed (or found to be impossible), the unit will start the second order. Behaviour can be changed by assigning stances: * Defend (attack nearby enemies, then return to original location/task) * Attack (attack and chase nearby enemies) * Avoid (run away from enemies) * Stand ground (attack enemies in range but don't move) * Hold fire (don't attack anyone or move at all) Units can therefore choose to attack an enemy automatically, but the player's orders should usually take priority. (For simplicity, let's say they always take priority. If I tell a unit to attack a particular enemy, he will head towards that enemy no matter what tries to distract him or kill him. Units will only attack automatically if they have no remaining orders.) State machines are the obvious thing to use. Orders usually involve multiple states, e.g. an attack order requires an 'approach target' state then perhaps a 'charge at target' state (when close enough), then a 'hit target' state and perhaps a 'chase after fleeing target' state. I think there will often be common behaviour for all the states associated with a particular order - e.g. when executing an attack command, regardless of which particular state has been reached, if the target dies and there are no more orders then the unit should pick a new target to attack; but when executing a gather-resources command, if the target dies then the unit should pick a new one to gather resources from. I'm not entirely convinced but I think it's probably worth using a hierarchical state machine to allow sharing behaviour between sub-states: define a TargetDied handler for the 'attack' state, and it will be used for all the sub-states (attack.approaching, attack.charging, attack.hitting, attack.chasing) unless they override it. Each unit would have a queue of orders, and the one at the top is what they're currently executing. When they finish, they pop it off the queue and process the next one. If it's a patrol order, they'll add it to the end of the queue so they'll repeat it. If there's no remaining orders, the behaviour depends on the current state and defaults to switching to the 'idle' state. Some of these orders might be automatically generated (when automatically attacking or gathering etc). Units can be in a few different modes: the standard individual mode; garrisoned (they can respond to attack orders but can't move); in-formation (their movement and attacks are very constrained). Those modes would probably be states in the top level of the hierarchy. Wild animals should probably use the same basic AI system, but with a completely different (and much simpler) set of states. I think this ought to be flexible enough to handle adequately intelligent behaviours, and structured enough to be implemented in a relatively-easy-to-edit form (not a tangled mess of code), so I probably just need to try implementing it and see how it breaks...

There's a combination of missing sound effects, missing sound effect triggers (we need to fix all the actor XML files to play sounds at the right time in the animation), and engine bugs (it doesn't cope properly with large numbers of the same effect). At least the first two are being actively worked on, so it should be much improved in the next release

It's fun to play with and it provides a helpful distraction from the writing that I'm meant to be doing Hmm... Won't this potentially cause dependency problems for users? They might already have the default Boost but the game might be compiled with a different version (since there's more than one available, at least if you include Universe), so they'd need two versions of Boost installed (or it'll link against an incorrect version). Then again, I suppose it should be okay when Universe versions of Boost are excluded, at least with Ubuntu's current arrangement of packages, but that doesn't seem like much of a guarantee.Hmm... In any case, won't the importing of other Universe packages into OBS cause problems? It's only importing a single version of the package, so it can't possibly match all the packages provided by multiple versions of Ubuntu, so there's going to be conflicts. Unless I'm missing something, this seems like a very dodgy way to generate Ubuntu packages. Maybe we should stick with OBS for non-Ubuntu distros (where it works without these hacks) but use something else (PPA?) for Ubuntu? Hopefully then we wouldn't have to be fighting against the system A few random questions: Is it conventional to run automated tests as part of the build process? (We have some if you run "./test_dbg" from binaries/system/ after compiling, though I'm not sure how it'll react with --libdir/--datadir builds.) Presumably we should add an architecture-independent "0ad-data" package (and mark it as a runtime dependency of the architecture-dependent packages). Is there a good way to do that? (I guess OBS shouldn't be necessary since we aren't actually compiling anything?) If we want to distribute the packages to users, should we (and can we) host the package files ourselves, rather than relying on download.opensuse.org? particularly when it includes ~100MB 0ad-data packages (it's probably not fair to stress openSUSE's mirrors with that)?