historic_bruno

Hmm, you know that may be a placeholder until we get a proper translated name. Thanks for bringing it to our attention though! (It would be even more clear if we did something like: Fishing Boat [NEEDS TRANSLATION] )

This should go in the off-topic forum, since it's not 0 A.D. related (or perhaps even better, on the SDL forums),

If you have mod powers, you should notice an option at the top and bottom of the topic (Topic Moderation). If not, ask Erik for mod powers

Any chance the contributors list could make it onto the new website? I notice there is a section for this (About > Contributors) but all it says is:

Thanks for including the dates! There has been some work on siege packing but you can save that for the next report

FYI that topic is in the staff forums, should it be moved to this one?

Oops, I misunderstood how the portable build is meant to work. But there's no hardcoded paths in 0 A.D. unless you use the specific build options, otherwise custom SVN builds of the game wouldn't work with the bundled data (which is most certainly located in arbitrary relative paths)

Can't you just use the -writableRoot command line option? See readme.txt.

Hmm I'm afraid not, at least not this December We won't reach beta until the game is considered feature complete, which it's not yet. However, we should have a new alpha release out in December

Those work! It's a very nice looking map For some reason I'm seeing glitches on the farm textures, we'll need to look into that.

Oops, I forgot to simply move his name rather than adding it

According to rome.json, there are two tracks that should play for Romans: Juno_Protect_You.ogg and Elysian_Fields.ogg. Is this not what you're hearing? I assume those are the correct music files.

I got tired of looking at our woefully old contributors.txt, so I updated it with names of programmers who contributed to source/ and whose names I could find publicly listed on the forum, since I don't want to disclose anyone's name without their permission. Please add your name to the file if you want (Or we could add forum/svn usernames)

Perhaps you made shortcuts to the files, without actually copying them?

Actually, we have a new horse model and plan to use it instead, it's a big improvement over the old model. Currently it's waiting for UV mapping, texturing and rigging, as far as I know: http://trac.wildfiregames.com/browser/ps/trunk/binaries/data/mods/public/art/meshes/skeletal/horse_new.dae I'm sure the art team would appreciate help on that, if you're interested.

Yeah I've got an old laptop with a GMA 900, and I've tried to play 0 A.D. on it, and I've done development on 0 A.D. using it. It definitely isn't what I'd call "playable", it gets about 2fps max and has Intel's typical buggy drivers. On the other hand, I tested with an old GeForce4 on an Athlon XP 2000 desktop and that was more like 10 fps, but I think the CPU would struggle in a serious game. I replaced the GeForce4 with a GeForce 7600 GT card about 3 years ago, that has shader support and is very cheap these days, it's a huge improvement for like $20 - about the best AGP card you can get. It's annoying to have one less computer for playing/developing 0 A.D., but like you, I have a much better desktop. Based on comments here, it sounds like some people who have tried 0 A.D. with old computers also have at least one newer one available.

Recently, 0 A.D. developers have been making strides in improving the game's graphics quality. We have added normal maps, parallax, ambient occlusion, trees that sway gently in the wind - all of which were included in Alpha 11. For Alpha 12, we have added waterfalls (animated textures), post processing effects like bloom and distance fog, and some nice water improvements like realistic water color, waves, and foam along the coastlines. These new features have been added mostly thanks to the hard work of two new developers: myconid and wraitii. We have ideas for further improvements we want to make, both new graphics features as well as improving performance along the way. However there are some shortcomings in how the game's graphics engine is structured, which could make further improvements very difficult or impossible. We have always considered it important to support as many users as possible. For that reason, as we've added these shiny new features, we have been careful not to break old hardware that uses something called the fixed function pipeline. That was what graphics cards used before shaders, which are a much more flexible and powerful technique. Many features of the game are significantly harder or impossible to implement with fixed functions, including shadows and particles, so it has remained a relatively low quality view of the game. Even though fixed render path looks simpler, it actually has worse performance on most shader-capable hardware (2003-04's GeForce FX series being a rare exception). Since about 2003, there has been growing support for shaders in new computers and graphics cards. When 0 A.D. first started, shaders were not planned and only a few users could boast such high-end graphics cards. But over time, fewer and fewer of our users have the old pre-shader hardware, while we've added better and newer graphics features. It has gotten to the point (since 2008) where on newer computers and drivers, the old fixed function pipeline is deprecated or removed. It has been proposed that maintaining the old fixed function support is too much work going forward, for too little benefit. There has been serious discussion of heavily updating the graphics engine, which will require pulling out all the fixed function code. If we choose to continue supporting old ~2003 hardware, it means we have to add another layer which complicates the design and maintenance of the game. It has become difficult to justify this extra work, given how few of our users play the game with such old hardware. Our best estimate is only a few percent of them would find the game playable, of all users since we began collecting user report data in early 2011. Keep in mind that fixed render path has no benefit to "new" computers, while the tradeoffs of keeping it are: less progress in improving how the game looks, increased maintenance of the game going forward, and potentially less performance enhancements. The only reason to keep fixed function support is for the few users who benefit from it. The affected graphics hardware would mostly be: GeForce FX/5000 or older (including GeForce2, 3, 4 series), GeForce FX Go 5 or earlier [1] ATI Radeon R200 or older (2003's Radeon 9250 or earlier), any ATI Rage cards, Mobility Radeon 9500 or older [2] Intel GMA 900/950 or Extreme Graphics [3] Low-end cards from other vendors (SiS, S3, etc.) Possibly newer cards with buggy or missing drivers So we'd like to hear from the community. Do you play 0 A.D. with one of those old pre-shader graphics cards? Are you using fixed render path by choice? Do you feel it's important that 0 A.D. support very old (10 years) hardware, why or why not?

This doesn't seem right, both files are the same size and the XML file is not readable. Are you sure you compressed the correct files?

After applying the patches, playing against only qBot seems to work fine in most cases. The game crashes on load when playing Acropolis 4 against multiple AegisBots, and also on some other maps (it's consistent and reproducible, but I don't know why it only affects certain maps). I'm not sure the call stack is very useful but here it is: ntdll.dll!_ZwRaiseException@12() + 0x12 bytes ntdll.dll!_ZwRaiseException@12() + 0x12 bytes pyrogenesis_dbg.exe!ScriptInterface::CallFunction_(unsigned __int64 val=18446462629364795072, const char * name=0x01a388a0, unsigned int argc=1, unsigned __int64 * argv=0x0038df28, unsigned __int64 & ret=14757395258967641292) Line 737 + 0x20 bytes C++ pyrogenesis_dbg.exe!ScriptInterface::CallFunctionVoid<CScriptVal>(unsigned __int64 val=18446462629364795072, const char * name=0x01a388a0, const CScriptVal & a0={...}) Line 383 C++ pyrogenesis_dbg.exe!CAIWorker::RunGamestateInit(const boost::shared_ptr<ScriptInterface::StructuredClone> & gameState={...}, const Grid<unsigned short> & passabilityMap={...}, const Grid<unsigned char> & territoryMap={...}) Line 467 C++ pyrogenesis_dbg.exe!CCmpAIManager::RunGamestateInit() Line 872 + 0x4e bytes C++ pyrogenesis_dbg.exe!ScriptInterface_NativeMethodWrapper<void,ICmpAIManager>::call<void (__thiscall ICmpAIManager::*)(void)>(JSContext * __formal=0x0a8a2990, JSContext * __formal=0x0a8a2990, ICmpAIManager * c=0x0e1db330, void (void)* fptr=0x0114aad0) Line 70 + 0xc bytes C++ pyrogenesis_dbg.exe!ScriptInterface::callMethod<void,&class_ICmpAIManager,ICmpAIManager,&ICmpAIManager::`vcall'{40}'>(JSContext * cx=0x0a8a2990, unsigned int argc=0, unsigned __int64 * vp=0x0f400090) Line 122 + 0x1d8 bytes C++ mozjs185-ps-debug-1.0.dll!77b9e069() [Frames below may be incorrect and/or missing, no symbols loaded for mozjs185-ps-debug-1.0.dll] mozjs185-ps-debug-1.0.dll!77bb29bd() If I play against 3 AegisBots on Fast Oasis, I get the following error output with the last lines repeating endlessly after a few minutes: WARNING: JavaScript warning: simulation/ai/qbot-wc/plan-research.js line 14 anonymous function does not always return a value WARNING: JavaScript warning: simulation/ai/qbot-wc/plan-research.js line 14 anonymous function does not always return a value WARNING: watching 1 WARNING: watching 3 WARNING: watching 4 WARNING: watching 1 WARNING: watching 2 WARNING: watching 4 ERROR: JavaScript error: simulation/ai/qbot-wc/qbot.js line 100 TypeError: pathFinder.markImpassableArea is not a function ([object Object])@simulation/ai/qbot-wc/qbot.js:100 ([object Object])@simulation/ai/qbot-wc/qbot.js:129 ([object Object],[object Object])@simulation/ai/common-api-v3/base.js:124 @:0 WARNING: watching 1 WARNING: watching 2 WARNING: watching 3 WARNING: JavaScript warning: simulation/ai/qbot-wc/economy.js line 489 reference to undefined property gameState.ai.distanceFromMeMap WARNING: JavaScript warning: simulation/ai/qbot-wc/economy.js line 489 reference to undefined property gameState.ai.distanceFromMeMap ERROR: JavaScript error: simulation/ai/qbot-wc/economy.js line 489 TypeError: gameState.ai.distanceFromMeMap is undefined ([object Object],"wood")@simulation/ai/qbot-wc/economy.js:489 ([object Object],[object Object])@simulation/ai/qbot-wc/economy.js:702 ([object Object],[object Object],[object Array])@simulation/ai/qbot-wc/economy.js:753 ([object Object])@simulation/ai/qbot-wc/qbot.js:165 ([object Object],[object Object])@simulation/ai/common-api-v3/base.js:124 @:0

I can't access Trac at the moment, so I'll post this here. I get the following two warnings when compiling in VS2010: 13>c:\users\ben\devel\ps\source\renderer\renderer.cpp(1486): warning C4701: potentially uninitialized local variable 'reflectionScissor' used 13>c:\users\ben\devel\ps\source\renderer\renderer.cpp(1493): warning C4701: potentially uninitialized local variable 'refractionScissor' used Not sure if it causes a problem in practice, but there's no default constructor for SScreenRect, so it needs to be initialized somehow. Also if I'm understanding the code correctly, it seems like the logic between lines 1484-1504 could be reduced to two cases, since refractionScissor is only used if (m_Options.m_WaterRefraction && !m_Options.m_WaterReflection).

Don't forget that we now support normal mapping, so that's an option too

Really cool to see progress on this at last Keep up the good work!

We've removed the fam/gamin dependency in SVN and probably Trac instructions are reflecting that, but for older source (Alpha 11) you will need to install it as quantumstate says. Sorry for the confusion.

A rotating turret would be pretty easy (I think) if we had finer control of animations. Though I'm pretty sure we can't combine animations, so it wouldn't be able to move and rotate the turret at the same time, unless we added that capability. Another option is some kind of entity propping system. Currently all props are visual actors, attached to a parent actor, but they all belong to a single entity. With entity propping, we could attach entities to a prop point, and they would follow the parent entity, but still be able to interact separately in the game. Not sure how well that would work or how flexible it would be, but it would get us closer to units propped on ships, walls, etc. That hardest part would be handling how the propped entity interacts with the simulation, can it move around relative to the parent, can it be attacked, what happens when the parent is destroyed, etc.

On OS X, you should be able to simply right-click both scenario files (XML and PMP), and choose "Compress". It will create an Archive.zip which you can rename and attach here.