Ykkrosh

Okay, all sounds sensible Current primitive implementation: the game checks about 32 equally-spaced points around the building's footprint, starting from the front and spreading outwards, until it finds a free space, and if it doesn't find any space then it places the unit in the middle of the building where they'll probably be stuck forever (since they're not allowed to walk over tiles that are occupied by buildings). Still need to add batch support to the GUI - I guess I'll stick with the simple approach for now of not displaying any discount information, and just silently apply some time discount to batches, and it'll be straightforward to change later. Should have this working tomorrow, I hope.

Technically it's http://creativecommons.org/licenses/by-sa/3.0/ (Google annoyingly seems to point to the older version instead). Doesn't make a substantial difference, though - it's fine as long as you make it reasonably clear that the images originally came from us and include a link to our site (as mentioned here).

Probably. But it might not be hard to implement something that's sort of like a bridge, which gets built during the game and which looks like a real bridge over water but acts like a flat raised piece of terrain (so ships can't go underneath it etc). It's okay as long as you don't have units that are directly above or below each other.

No. The gameplay is basically 2D (e.g. units only have X and Y coordinates and their height is automatically calculated from the terrain whenever they move), and adding multiple levels would add quite a lot of implementation complexity (more position information to keep track of and to update) for not much benefit.

Hmm, I hadn't thought of it that way - I was assuming it'd be more incremental, but that sounds a much better idea.(One technical difficulty is that when the player wants to add something to the queue, it actually has to send a network message and wait maybe 300ms before the simulation responds to the player's input (so that all the players in multiplayer games respond simultaneously to the same input) and then it might discover that the player no longer has sufficient resources. That means there's ~300ms where the simulation and the GUI might be inconsistent, which makes it hard to do fast sequences of gameplay-altering actions - it's best if we can, uh, batch the user inputs into a single 'create a batch of size 25' command to minimise those problems.) Aren't box and line formations likely to be wider than the barracks? I just can't visualise how they would "emerge" from it.I guess this is a partially similar situation to ungarrisoning lots of units at the same time, where there needs to be a way to make them come out of the building in a relatively orderly fashion without trampling each other or getting stuck inside other nearby buildings. How do other games handle that? If they file out gradually, what happens if the building is destroyed while there's still a dozen units waiting to file out of it? (Do the units get destroyed, or perhaps dumped onto the ground in the area where the building was, or something else?) I'm happy with not telling the player any numbers about time (since I think it's not a scarce resource for most of the game for most players, and I don't remember any other games showing numbers for that). But resource numbers seem much more important - usually I'll have used up all my spare resources so I'll have approximately 0 wood, and then I really care about the difference between spending 300 wood and 225 wood. If the game doesn't tell me, I expect I'd want to look it up in a strategy guide or try to measure it myself by watching the resource counter carefully and doing some mental arithmetic, which turns it into more complex spreadsheet balancing and I'd never quite trust the answers. Saying something like "20% discount" tells the player the rough scale of the benefit, and enough information to reliably compute the precise benefit if they want, but only adds one extra number to the UI. (I definitely don't want to display e.g. a 4-column 6-row table of resource costs vs batch size, since that would be too spreadsheety . A single number seems a better balance to me.)

I was looking a bit at training queues, particularly the batch training concept, and it'd be useful to get some ideas or clarifications. We don't need to make final decisions now, and it'll probably change when we do gameplay testing, but it'd be useful to have answers to direct an initial implementation. Question: How should players be made aware of the resource costs and the batch discounts? It needs to be clear to players that batching is significantly useful, not simply a shortcut that's equivalent to creating five units individually. Perhaps it could be done with a tooltip on the training button which initially says: | Hoplite | 75 wood, 5 metal | Shift-click to train 5 with 20% discount i.e. it costs 75*5*0.8=300 wood, 5*5*0.8=20 metal for a batch of 5, and when you shift-click the tooltip changes to say | Hoplite | 75 wood, 5 metal | Shift-click to train 5 with 40% discount i.e. it costs an extra 75*5*0.6=225 wood etc to add an extra 5 to the existing batch. If you start a new batch then it'll fall back to the original 20% discount for the new batch. I hope that would be obvious enough for players, so they discover and understand that there's an advantage to making large batches. Are there better ways of doing this? Is it necessary to tell the player how much time the training will take? Seems like possible information overload, and not really required, so hopefully we don't need to add it into these tooltips. Question: If it's meant to take 20 seconds to train a batch of 5, and 30 seconds to train a batch of 10, and you start a batch of 5 then wait 19 seconds then increase it to a batch of 10, how long should it take? Should it finish 30 seconds after you first started the batch (the same as if you made a batch of 10 right at the start), or should you be penalised for changing it later? (If there's no penalty, micromanaging the production queue would give you an advantage by letting you use the extra 225 wood for 19 seconds for free - I don't know if that's something we want to encourage or discourage or not care about.) Question: If you train a batch of 30 units, what exactly happens when the batch finishes? Should they all spawn instantaneously spread around the building, or should they all trickle out of the front of the building at a rate of e.g. one per second to avoid a giant pileup? Question: Are all units going to use this same system? I can imagine things like ships and siege weapons might be unbatchable, because you'll rarely want lots and it'd be a big mess if 30 of them spring into existence at the same time. Should batching be disabled for them, or for other units, or never disabled? Question: What happens when you remove an item from the queue? I presume the resource cost gets taken away as soon as you add an item to the queue, and if you remove it before it's reached the front of the queue then you get those resources back. Do you also get the full resources back if it's reached the front of the queue and 99% training progress before you cancel it? I think it's good to let players freely undo their actions when possible, so if they accidentally start training a unit and (at some point before it's finished) realise it was the wrong one and cancel it then they ought to get all their resources back. Are there any reasons not to allow that? Question: What happens when the building is destroyed? Do you lose all the resources that were put into its training queue? Or is it equivalent to manually removing everything from the queue so you get all your resources back? That's probably enough for now

I think it should be pretty easy to implement support for transferring data between scenarios in a campaign - the game will already have to remember information like what map you've reached and I guess a score or something, and scenarios should be able to run arbitrary JavaScript code, so the scenario scripts could give the engine some data when finishing and the engine could save it and pass it to the initialisation code of the next scenario. You'd have to write a bit of your own script code to make that work (it wouldn't all be a point-and-click GUI) but you can just copy from examples so it should be fairly straightforward. I'd agree with the probable gameplay balance problems, though - it makes everything much harder to test (you can't just test a scenario by itself, you've got to test it in all the different starting modes), and it's not nice if an inexperienced player who loses a lot of units in one battle starts the next battle at a significant disadvantage and finds it even more difficult. And people will decide they have to exploit the system, e.g. defeat the enemy but leave one unit alive for half an hour while gathering as many resources as possible to take into the next level, which harms the enjoyability of the game. So you need to be very careful with this kind of thing

I assumed it's when you select a unit, select the "build house" button, then shift-click several times to place several houses, and the unit queues them up and builds them all in that order. If it's not that then I have no idea what it is, so it'd be good if someone could explain . If it is that, then I think it's just a special case of a generic task queue (e.g. shift-click to walk to several points, or to repair several buildings, or some sequence of multiple actions), which isn't implemented yet but should be eventually. (You can't at the moment since that's not implemented in the new simulation system, but it should be added very soon.)

Hmm, apparently macho64 is only supported since 2.07. It sounds like Xcode ships with a version of nasm, which is presumably too old, but MacPorts currently has 2.07 which should work.

Hmm, the old code tried looking at HOSTTYPE but it would never work (since it's a bash variable, not an environment variable). I've changed it so if /bin/sh is bash (which I think is the case on OS X?) then it should pick it up properly now. Yeah, that's the one where NASM is trying to assemble in 32-bit mode instead of 64-bit, or something like that, and I don't know where to look for a solution

Uploaded, thanks

Filed as #489. (Thanks for your work on these packaging issues! I think I'd probably like to update the pre-alpha release in a few weeks to pick up some newer fixes, so I'll try to include these improvements then.)

I'm afraid I don't have any further ideas . Has anybody else run the game on Ubuntu 10.04, and had success or failure? I don't think the game is doing anything unusual (it's just using OpenAL for all the audio) and it works for most people so it seems most likely to be a problem with the audio-related services/drivers that you're running, but I don't know anything about the details or how to debug it.

I think that's just a problem with Ubuntu 9.10's versions of OpenAL and PulseAudio, which quite a few people have experienced (and which affects other games that use OpenAL). I heard a while ago that it should be fixed in newer Ubuntus, so hopefully that's the case.

Hmph, beat me again . There should be music in the menu screen (though sound effects were broken until a few days ago). I think Ubuntu has problems with OpenAL and PulseAudio - this particular issue might be fixed like this.

Oh, didn't see your edit . You ought to just use the standard libsdl/libsdl-dev packages from Ubuntu, not compile your own versions. (Reinstalling the packages in Ubuntu may replace the files with the proper version). I know nothing about Wesnoth, but 0 A.D. doesn't use SDL for audio and I believe it's impossible for it to fail to recognise its own music format (since the game engine knows how to read .oggs), so that error doesn't make sense.

Hmm, the glxinfo output looks roughly sensible so it probably ought to work. The error message "X11 driver not configured with OpenGL" makes it sound like you may need to reconfigure your X11 driver with OpenGL . I don't think that issue is specific to the game - it'll be something to do with Xorg and fglrx and Ubuntu's packages, but I'm afraid I don't know any details of how they work.

Could you paste the output of running "glxinfo"?

The resolutions I currently use are 1280x800, 1440x900, 1680x1050 and 2560x1600. Widescreen seems quite ubiquitous . I run 0 A.D. at 1024x768 (windowed), but that's just for development so I can have editors and console windows visible at the same time - is everyone likely to play the game fullscreen instead?

Might be good to add options for 1280x800 and 1920x1080, judging by Steam's survey.

I get that quite frequently. Looks like it's just a bug in VC++, so I don't expect we can do anything about it - it fails during the final linking stage, and if I tell it to build again then it finishes and links correctly. (Maybe it could be fixed by telling VS not to build multiple projects in parallel, if that's what's confusing it, but I've never tested that.)

Sounds like #484. The previous reports were on Win7, but if you get it on Vista then presumably it's a 64-bit issue.

Yes - they're loaded at runtime with dlopen. (libAtlasUI is the editing tools, libCollada is the .dae converter (used when loading a new model/animation file that hasn't already been cached).)

Modifying the code like that would require compiling it manually and it wouldn't be run from the read-only system directory, so it's probably not the best way to debug it. It'd be better to run strace /usr/share/games/0ad/system/pyrogenesis_dbg -editor 2>&1|grep openwhich will almost certainly give you output like open("/usr/share/games/0ad/data/mods/public/maps/scenarios/test.pmp", O_WRONLY|O_CREAT|O_TRUNC, 0777) = -1 EACCES (Permission denied) The problem is that the game uses the VFS mod-file system for loading and saving maps, so it always tries to put it in the shared data/mods/public/ directory, which is read-only in these installed packages. (It'd work fine with a version compiled by hand and running within your home directory). The scenario editor pretends to let you save in any location, but it's lying and always saves in data/mods/public/etc instead. I think the right solution is to add a per-user mod (in ~/.local/share/0ad/data/mods/user/ or something) and make it the default for all file saving, and then make the Atlas UI be VFS-aware so it lets you select which mod to save files into (ignoring read-only ones) and see what files from the 'public' mod you're overriding. I expect it'll take quite a bit of effort to get a reasonable UI design for that (so that it makes sense, works for core game developers, works for mod developers, works for serious scenario designers, works for end users who are just playing with the tools, etc), and I haven't thought about it much - does anyone happen to have ideas for it?

Ah, that's good to know. (Maybe I should play SC some time ). But is it useful in games where zoom isn't critical to gameplay, and the difference between maximum and minimum zoom might be something small like 4x?