Yves

Philip is working on improvements for the pathfinding code which is currently the main reason for laag, especially with qbot. As a workaround you could try playing without qbot or/and try different maps which have less problems with pathfinding performance. It's still an alpha version and therefore still has some problems which will be fixed in the future.

Please post the error-messages. Maybe it's not even related to the gcc-version.

We are currently using premake 4.3 with a lot of customizations. Premake 4.4 is in Beta-state and as far as I've seen, they have changed quite a lot of the internal structure. When I began working on the upgrade from premake3.x to premake4.3, I thought it would be much easier to upgrade to newer versions once it's finished. It will be easier, but unfortunately there was no way around making changes to premake itself which will make an upgrade harder than initially expected. Hopefully some of the errors I had to fix in 4.3 will be already fixed in 4.4 and all the assembler stuff isn't needed anymore, but maybe there will be new bugs or changes that require adaptation. I will probably have another look a it after premake4.4 is stable. This time it's probably better to take the time and try to get as much of our changes back into premake so that the next upgrade will be easier. In regard of xcode support, we can't expect the upgrade to happen in the next few months and I don't even know if premake4.4 supports it much better. On the other hand, XCode support isn't directly connected to supporting .app bundles in our build-process. We could already do it now if there was someone with a Mac and enough knowledge and time. I used a VM for the Premake development, but that's not sufficient for this task and current I'm not willing to pay hundreds of dollars just for this purpose. Maybe I could buy a Macbook and set up a dualboot with linux... so I could also use it for other purposes.

I fully agree that we should have two separate modes as you described. First, movement of single units and groups of units and second, units grouped to formations and movement of formations. The tricky thing about gameplay will be how we present these differences, limitations and benefits to the player in a self-explanatory way. Some basic thoughts about this: * No single units can be selected in a formation * Every formation has a leader who is visually identifiable (by carrying a flag, having some decoration on his helmet or whatever...) * When forming up, there's some kind of progress-bar (on top of the leader?) and units won't attack or defend themselves until the progress is completed or aborted. This could also be a button like for training units that monitors the progress... * When a formation of units is selected, the cursor already indicates whether you can move the formation to a certain location or not. * There's some sort of "glow" below the units for all the bonuses they get (like in BFME). The tricky things are always the details and I think we need a clear design document about how this is intended to work. Depending on the details, this could have other effects on gameplay. One example (if there's a leader of formations): Should the leader of a formation be chosen randomly? Should a hero or a unit of a certain rank be required for commanding the formation? Can the player choose which unit is the leader? Does the leader give any special bonuses to his formation? Such questions need to be answered and clear before any changes to the system take place, or there will be time wasted for changing things afterwards.

There's another thread about this topic here: Click

It's a bit weird. It does not find pkg-config because /opt/local/bin is not in the PATH of the shell used to execute commands inside C::B. There are some setting for the environment under Settings>Environment... but they don't seem to have any effect on that. It finally worked after starting C::B from the terminal. Somehow it got the right PATH that way. The question is how I could solve this with premake. I don't think I should use a full path to pkg-config because it could be installed elsewhere. The only other solution I see would be executing pkg-config from premake and inserting the output directly. That's how I had to do it for Xcode. EDIT: Committed - http://trac.wildfiregames.com/changeset/10521

If someone would like to test it or has any feedback, here's a patch for Code::Blocks support on Linux. As yet I've only done some quick tests. premake_codeblocks.patch

Does anyone remember how garrisoning was solved in Age of Kings. As far as I remember, it was just right-clicking... but how did it work if you had citizens with resources and wanted to garrison them in the towncenter?

You could also use MinGW. If we tried to support it we would have to decide if the options in Code::Blocks should be for MinGW (GCC) or Visual Studio compiler. I don't think there's a way to support both. Maybe I'll do some tests on Windows, but I won't finish it if It's too much work and if there's no one who actually uses it.

Yes, I didn't check it on Windows yet. I guess this will be more difficult and for me it does not have priority because most Windows developers use Visual Studio anyway.

http://www.youtube.com/watch?v=IMIlP4zB0EM One of my favourite songs.

Good news: I was able to successfully build using the Code::Blocks IDE. Some manual tweaks were required, but it looks like it won't be hard to integrate them into the premake scripts. From what I see until now, Code::Blocks looks promising and I'm going to give it a try.

That could work, but we had to make some changes to premake to get the other environments working and it's likely that there will be some gliches for Code::Blocks too. If you test it, please tell us if it works.

Ohh that's bad news . We will have to wait until premake supports xcode4. They have a seperate brach in their repository for xcode4 support... but I didn't yet check how far they are (currently it's offline). https://bitbucket.org/liamdevine/premake-dev-xcode4/

A patch is ready for review.

Thank you! I can probably check this next week. I won't be at home and it's difficult to tell how much time I will have. I hope I can also give feedback to Ticket #850. Thank you for the feedback there!

What do you think about making premake4 the default now? I think we should do it now to get enough feedback until the release of alpha 8. Edit: I probably won't be online the next two weeks...

What's wrong with the xcode projects generated by premake?

Thank you for those links, I didn't know there's a swiss german version (by "Des Königs Halunken"). Even though the quality on youtube is quite bad, it's very funny if you understand what they are singing.

The link "Read the whole thing" in the latest news on the mainpage is broken. I wanted to leave a comment in the news, but this didn't work either because the login-button led me to a blank page.

I don't quite understand the problem. We currently use the same xcode-target for debug and release builds, and the output filename and other settings are defined in the configuration. If you switch the configuration to debug, you can right-click on Executables>pyrogenesis and select "Get info" to verify that it actually points to pyrogenesis_dbg. The only things that don't change are the names of the target and executable displayed in xcode on the left side in the "Groups & Files" panel, which is fine in my opinion. I've verified that it actually runs the debug executable in the debug configuration and the release-executable in release configuration via "Build and Run" / "Run". Could you elaborate on this please?

Thank you for committing the patch and for the feedback! I currently don't have access to my computer, but I should have time to check it this weekend.

It looks like an installname issue... I hope I get this right from my memory: Each library (dylib) defines an installname which is a patch where programs expect to find it. otool -L pyrogenesis_dbg shows you where pyrogenesis_dbg looks for libnvcore.dylib (and other libraries). otool -D libnvcore.dylib shows you the installname of libnvcore.dylib, which is written into pyrogenesis_dbg when it's linked. install_name_tool allows you to change the installname of a library. You could try checking where these paths don't match. As far as I remember I copied libnvcore.dylib to binaries/system, but I don't remember exactly if that's all I did and if that's still needed.

Please check 0ad/binaries/system/ if there's a pyrogenesis.app created after building. There should be a binary called pyrogenesis inside this app package. Try copying it to 0ad/binaries/system and running it directly.