historic_bruno

I'm glad it worked for you, still it would be useful to know something about your system, so we can prevent this happening to others There's probably a better solution than forcing users to windowed mode, and if people encounter this bug, they might just decide to stop playing. If you can attach your system_info.txt, it may contain some clues.

Definitely. We have a range of options for how to implement that: require infantry units to manually pack/unpack it (nice for the eyecandy I think, but perhaps annoying in practice); automatic based on orders given (an attack order means it should unpack or if it's too far away from the target, it should pack, move, and unpack again, whereas a move order would pack and move); or have pack/unpack UI buttons which require manual control.

Indeed that's what I meant Are you on a laptop or a system where you have multiple display ports (maybe a dual-monitor setup or TV/monitor)? The blank screen with no response sounds very strange, almost like the display has been switched when the game starts which is why you see nothing happening (if you hear the game's music, I'd say this is definitely the case). Otherwise, maybe there is some error you can see by running the game in windowed mode instead of fullscreen, following the instructions here. It might help us to have a look at your %appdata%\0ad\logs\system_info.txt file, if you want to attach that here.

Yeah, the error message is different, so it would be a good idea to have a new report for this, and if it turns out to be already resolved, we'll just close it (We REALLY need more info to troubleshoot it though)

Hmm weird, I didn't get any errors like that Were there any other errors earlier in the build process? The pthread error makes me think it's not properly building against pthread, but I don't know how to test that. What version of FreeBSD are you using? Edit: it seems you're not the first to encounter this problem, even the SM port has a bug report. Hmm, is the port Spidermonkey 1.8.5? I saw a 1.7 port, which won't work because they change the API so often, it has to be the exact same version (and even then it's not guaranteed to work) :/

Hello. What OS are you using and at which point do you get the blank screen?

Hello, can you register an account on Trac and make a new ticket there? (forum posts are sometimes missed) We need as much info as possible, unfortunately the error message is quite generic and doesn't help much. If you find %appdata%\0ad\logs\crashlog.txt and crashlog.dmp, then please attach them to your ticket. Also useful would be the debug output from the game's startup, which is normally hidden but you can view it with Microsoft's DebugView utility.

Hi, on windows you'll need some version of Visual Studio/C++, and 2010 is recommended. I use the Express edition and it works fine, but the Pro editions have support for third-party plugins, included 64-bit compiler (not much use for us), and advanced debugging features, so that may be more useful if you have a choice.

Warning on Granicus River with qBot as player 2: WARNING: JavaScript warning: simulation/ai/qbot/economy.js line 290 reference to undefined property supplies[resource] (Also check out the weird unit movement of the AI on that map )

That's quite a nice benefit! Hopefully our map designers won't make a checkerboard maze of trees I would still like tree obstructions to work differently, but that's not an immediately concern. Oh and it may be assumed, but your latest changes require uniform terrain cost?

Mostly the same dependencies are needed as on Linux builds, here's what I had on my test system (only a few needed to be installed by me with "pkg_add -r packagename", because I installed X, Gnome, etc., which already added many dependencies): GCC 4.2.1 and zlib - included with FreeBSD sdl boost-libs png execinfo *FreeBSD specific libxml2 libGL openal zip libogg libvorbis curl gamin cmake wxgtk2-unicode This patch should include all the changes needed to build the game on FreeBSD (I tested on 8.2-Release/amd64), when applied to a clean copy of our SVN trunk: freebsd_support-12122011.patch Apply that patch to your working copy and then run ./clean-workspaces.sh followed by ./update-workspaces.sh --without-tests, there's some problem with tests that I didn't bother solving yet. Actually, contrary to my prior post, the game runs fairly well, though I had to use the Mesa Software Renderer because there is no recent driver available for my Radeon HD 6850 So performance was awful but there were no errors. I should also mention I'm testing this in a VM and couldn't get a sound device configured, so I ran the game with the "-nosound" option to avoid problems. Atlas worked, which is a bonus.

update-workspaces.sh builds a bundled NVTT in /libraries/nvtt, if you read the README you will see we use the latest release (2.0.8-1 from May 14, 2010), not the SVN trunk, so we do have to apply some patches for various fixes. (What I mean is apply those patches to /libraries/nvtt/, if you examine the source code you'll see the FreeBSD support is not there yet). That said, you may be able to use the NVTT port, if they're compatible, feel free to try this. Then you would just use the --with-system-nvtt flag when running update-workspaces.sh, so it doesn't try to build the bundled copy. I will try to make a complete patch of all the necessary changes for FreeBSD, because there are many others, but I did get the game to compile into a rather buggy but runnable state.

I was thinking of something like this once, still it may fall under "needless complexity". For example, what happens if you have 20 units chopping wood, then you reassign them to farming, should they each drop their collected wood resources so you end up with 20 treasures littering the map, but it doesn't sound trivial to combine them all into one either. And since treasures don't require shuttling, I could see this as a cheat to avoid needing to build dropsites (when done collecting resources, just change gather type and you get a "free" instant dropsite anywhere on the map). Instead of a treasure, it would have to be some type of resource entity that's instant gather but needs to be shuttled.

Hi, just to add on to the current discussion: ecvt() is not included in FreeBSD's stdlib.h, as it's an old deprecated POSIX function they have omitted it. So we'd either need to implement it ourselves or rewrite the relevant code with sprintf instead (ecvt() is apparently only used once by fcollada). I found this link which gives a possible implementation. Dropping that code into FUStringBuilder.hpp, at least it finishes building fcollada but I don't know if it works. Then you need two patches applied to our bundled NVTT 2.0.8-1 (r907 and r1025) which provide FreeBSD support, again I'm not sure how well it works. The ENet build needs to be told to use gmake instead of make, apparently you can do that by modifying its build script, adding the "SET_MAKE=gmake" option when invoking the configure script. The next biggest issue is getting premake to work properly. I don't think we have any checks for FreeBSD in our premake scripts (only Linux, OSX/Darwin, and Windows). It may be good enough if all the OSX-specific parts do a test for FreeBSD as well (I notice that's basically how NVTT added FreeBSD support). I did see a few minor issues that are easy to correct: there's no libdl on FreeBSD, so those lines can be removed from Premake4.make (this should be handled by the script that generates this makefile, but for a test, you can alter it by hand). And in premake4.lua, it's not detecting amd64 architecture and defaults to x86, so it needs an additional check for the "amd64" string (both HOSTTYPE and the gcc -dumpmachine hack). Maybe a Trac ticket referencing all these issues would be helpful

I think AoK AIs would only garrison females locally after they were attacked (I'm not sure if you attacked or not) and it would never garrison soldiers. qBot could be smarter by doing both but only after it weighs the enemy's (local) strength with its own, if it's even close I'd say fight it out

A minor suggestion, I notice qBot gets attacked by animals sometimes, but often the victim is a ranged unit that can never fight back because they have a minimum range and the animal is fast enough to take advantage with a melee attack. Anyway it looks very strange and always catches my eye Would it be possible to detect this and flee, or perhaps order a group attack? I guess this problem affects all ranged units really, so perhaps qBot should detect when a ranged unit has a melee unit attacking them within minimum range.

Sounds like you've summarized it well You just need to register on Trac to create a ticket.

Hello! My advice would be to start out small, there's nobody who understands the entire game (engine, scripts, art, build system, etc.) even after years of experience, though some like Philip come close Probably the best thing to do is hang out in the #0ad-dev IRC chat room on Quakenet.org because there are some interesting lively chats there throughout the day and you can get quick feedback and questions answered (I think our most successful programmers do this and post on the forums). Maybe you can also read some of the ongoing discussions in the development forum. Trac is of course a good starting point, but beware of outdated documentation, if in doubt, ask. It's hard to say what you should do if you're interested in C++ specifically, because many of the most interesting tasks require some combination of C++ and JS, and are interconnected with the rest of the engine, so you need some in depth knowledge about 0 A.D. For instance, in the extreme case, a new gameplay feature might require C++ component changes, input handling and UI modifications, a new scripted component, AI support, renderer modifications, and maybe even artwork. There are lots of simpler things but not all are documented, one good way of finding them is by playing the game and prying around What I mean to say is: if you start making contributions to 0 A.D., you are likely to find yourself applying many of the skills in your original list and then some.

What about siege units? They're bigger than human units and will have different attack behavior. How will they interact with formations? Treating them like human units taking up slots in the proposed "battle formations" doesn't sound appropriate at all.

Right, and I wouldn't consider a high priority feature, but I'm sure we could come up with a hotkey for it Edit: another thing, it should be possible to stop a formation's movement, in fact to stop any unit's current orders, to return it to the idle state, maybe with the ESC key and a UI button.

One thing I hate about formations in most games I've played, there's no retreat feature! If you want to run away from a battle, you select all the units, and move them in the opposite direction, but because of how formations are arranged, units like archers are placed in back and right in the heat of the battle, making them very easy targets. Instead there should be a way to retreat, either orderly with the formation moving away backwards (at the cost of moving slower), or disorderly with every unit just running away as fast as they can with no organization.

Hmm I think Atlas needs a "default" AI setting in the player panel, so that it doesn't always manually set the AI. It's going to be a pain to update all the maps if we want qBot as default The intent was that it would only set the AI if the map designer explicitly wanted that, and usually player_defaults.json would be used for default player settings, but that's not how it works now.

Confirmed that this works, but then it won't run the app bundle, it thinks it has never been built Also Code::Blocks seems really buggy on OS X, not only the UI, but it freezes occasionally, crashes when closing, the settings don't save, etc. So I think it's not worth spending too much effort on, probably much more important to get Xcode working properly.

Hi, thanks for the report You'll need to register on Trac to submit a new ticket, then at the bottom of that page you'll see "I have files to attach to this ticket", which will let you do so. The game will never run well on your system, but it may be you can avoid the crash by tweaking settings. The crash dump might reveal something. Also check if there's a newer video driver available from Intel (unlikely but always possible).

Mid-December is the current plan.