historic_bruno

What's the result of running "file /usr/local/lib/libpng.dylib"?

Which compiler are you using? (gcc --version) Do you have Xcode's command line tools installed, which version of Xcode? Apple has made this extra confusing recently, so it's quite possibly a compiler issue.

/usr/local/lib/libpng.dylib is not the OS X version of libpng, that's one provided by Mac Ports, and it's what is trying to be linked by NVTT. Also you didn't mention your version of OS X, but at least on Mountain Lion libpng is no longer included (since it was only included as part of X11).

That shouldn't be a major concern. I mean cheating is always somewhat of a concern but nothing that can't be done already by modding the UI and engine (specifically the non-synced parts to view LOS, etc.) In fact it would be better if people did make cheating UIs, it would bring those cheats to our attention so we could fix them, if serious enough

OK, I've committed a new build to SVN with some added debug output. Previously the OpenAL init may have failed silently. For those who don't know, you can use DebugView on Windows to view the debug output, just run that utility followed by the game, DebugView will log the output. The relevant line to look for is "Sound: AlcInit ..." which should tell us if it failed and possibly why.

Hmm sounds like a difference in hardware or drivers, since it's working for some people in Windows but not others. The question is why it worked before. Unfortunately for Vista or later, our system info detection fails to detect sound driver versions So I'd suggest opening up Control Panel and go to Device Manager > Sound, video and game controllers and view properties of the sound devices listed in system_info.txt, then list the Driver info here. AMD High Definition Audio Device Advanced Micro Devices 2/23/2012 7.12.0.7706 Realtek High Definition Audio Realtek Semiconductor Corp. 6/14/2011 6.0.1.6392

Did you see this link? http://trac.wildfiregames.com/wiki/GameplayFeatureStatus

Yes, I think AIs should be able to receive chat messages, they can already send them. It could be useful for instructing the AI, even if it's something simple like AoK's "31 (attack an enemy now)" command, though I'm sure our AI devs could improve upon that

Why not use selection state to debug the orders? That should make it very clear what's happening. Alt+D > Display selection state, then select the unit in question. You can check the target ID to see if it's really going to the house or not. For shuttling, it should only use entities with a ResourceDropsite component, assuming everything is working as designed.

By the way, if anyone is tempted to work on this, I would point out the list of planned gameplay features, which should be higher priority http://trac.wildfiregames.com/wiki/GameplayFeatureStatus

The most obvious requirement is JavaScript integration and in particular, behaving nicely with Spidermonkey, since I don't think anyone wants to change our script engine at this point, nor transition to a different language. Well irrespective of whether someone wants to do that, I don't know if anyone is willing to put the effort in designing and troubleshooting such a massive change So whatever the system, UI events should pass down to JS via Spidermonkey. It should integrate well with SDL and OpenGL too. I wouldn't call this a requirement per se but a "nice to have" feature is the ability to design a modular UI, so that for instance the minimap is one module, the unit details panel is another, the command panel is another, etc. We could then leave the exact configuration (position, style) of these modules to the user. People who like corner layouts get that, people who like center layout get that instead. Currently our GUI pages are very monolithic, which makes modding and style changes difficult and as for different layouts and code reuse - forget about it. Imagine if all that was required to radically change the UI layout and appearance was loading a different CSS? Also, the current GUI engine is all static objects, created at load time (the lone exception I know of is sprite textures which can be scripted, but of course the object itself must support the "sprite" property). It would be nice to have the ability to dynamically create UI elements and not have to define everything in advance in XML or even HTML/CSS. More radical idea: could we ditch wxWidgets and integrate the Atlas scenario editor UI into the engine itself? This would have an added bonus, possibly, we could make a web-based scenario editor (I've dreamed about a web-based random map design tool for some time, why not go all out?) We'd lose the benefit of platform specific appearance and behavior - not sure if styles would fully solve that, but we'd ditch a massive library that's only needed for Atlas. More tickets: http://trac.wildfiregames.com/ticket/114 http://trac.wildfiregames.com/ticket/116 http://trac.wildfiregames.com/ticket/850 http://trac.wildfiregames.com/ticket/885 http://trac.wildfiregames.com/ticket/1386 http://trac.wildfiregames.com/ticket/1532

Example of libRocket in action (the flickering is apparently due to the recording process): Note the nice feature of being able to drag UI elements around.

I ninja fixed that in r12428 There's a few others related to Mikktspace that I haven't gotten around to yet. The link warnings have been around for a long time, they are annoying but seemingly harmless.

Finally solved this problem It was due to an ancient Spidermonkey lib that had been installed with Mac Ports. The game will include that version of SM by mistake due to include path precedence. So if you encounter this error and use Mac Ports, just use "sudo port uninstall Spidermonkey" to get rid of the old conflicting Spidermonkey.

You know what I just realized, that would make it incredibly easy to try new fonts. Not only that, if it has any decent level of Unicode support at all, we could support translations to languages like Chinese, Arabic, Hebrew, without much trouble. I think? This isn't possible currently with our GUI engine, as far as I know.

Great suggestion! That's pretty exciting Looks like it only has one dependency, FreeType, unlike WebKit. It supports the platforms we want and then some (iOS / Android anyone?) The build process looks painless. We could continue using SDL and our custom render engine. The thing to note though is it's not a web browser, but just an interface between input and display components which happens to support HTML/CSS. I have no idea how JavaScript would interact with it (likely through a custom interface we have to write ourselves which isn't terrible, that's what we do currently).

I would definitely like an auto-updater for 0 A.D. No idea how it would work for Macs though, you can't really change an app bundle, or shouldn't anyway especially if we start signing the bundle. Maybe mod data would go in Library/Application Settings, the first time you run the app it could download the latest data, future updates would be incremental. If the engine changes, it would need to download a new app bundle. This would require a significant change in how we distribute the game. Of course if we do auto-updating, the bigger problem is getting it to work with multiplayer.

OK folks, the new sound system has been committed, now time for testing. Go go go

Thanks for reporting I encountered that error as well, it's just because the "defeat cue" music file was removed from SVN, so I've fixed that and left a comment. I don't really understand the purpose of the defeat cue.

What's the status of this? If there are no changes anticipated in the patch this week, let's move forward with committing it.

Wow, beautiful rocks Except for the AO artifacts but overall nice work Metal mines can definitely benefit from the new effects too. Eventually it would be nice to get rid of the "sparkle" particles but we should make sure everyone can see the specular mapping first (currently requires GLSL).

Word of caution here: even if you seem to be able to import a rigged/skeletal/armature model, you shouldn't, because the Blender importer will mess up the bone transforms which won't be noticed until they are imported back into the game. Unless the importer problem has been solved in a new version of Blender but I haven't heard that it is yet. They should be excluded from the conversion process. This would include animated siege units and ships.

How would it compare with this simple concept? Basically applying animated textures to a cone, centered on the player's camera, with some calculations for camera movement.

Assuming you mean simulation component scripts, they should implement a message handling method like "OnMessageType" and are automatically subscribed to messages for that entity. There is also "OnGlobalMessageType" which subscribes globally (messages for any entity). This is a relevant document if you haven't seen it yet: http://svn.wildfiregames.com/docs/writing-components.html

There are actually a few problems in the unit AI, it doesn't handle min and max range very well. We should solve that, which should prevent the endless chasing behavior, but there are cases were a second attack type would help, like killing domestic animals - there's no reason to stand around throwing javelins at a chicken when a knife would do it This is planned, assuming we have resources to work on the animations.