historic_bruno

We need a version of the "torpedo#" cheat from AoK, so you can instantly wipe out an enemy player

Hello and I guess you'll be extra delighted then, since we just split the generic Celts into Gauls and Britons

Let's get some of these patches cleaned up, tested, and integrated with the engine I suppose #1493 and #1497 are a good place to start even though they have no visible effects. I think we can get them in A11 if the changes are validated. Indeed, there was a discussion about that here.

Should be fixed in r11974

Maybe we just need to rebuild premake4.exe to match the changes introduced by r11970.

Agreed, this is a great demonstration (better than the Roman CC in my opinion): http://i.imgur.com/moHjah.jpg

Interesting, probably something for the art team to keep in mind when they focus on revamping the gaia assets, I wouldn't mind more varied tree models Thanks for the example! Maybe it's just me, but I hardly notice the subtle swaying of trees in that video? I mean when you focus on the tree and the camera isn't moving, you see it clearly, but most of the time during a game I'd be oblivious to such a minor effect. The fields were more apparent but only from being so ugly... What really stood out to me in that video were the effects surrounding naval combat, which are much lacking for 0 A.D.

True, but it was pretty ugly... and they only had one generic attack stat, two armor types (normal/pierce), one attack type per unit, no XP or stamina, and no concept of citizen soldiers, so generally there wouldn't be more than 2-3 icon rows for their stats - which is in the reasonable category for UI design. I have no problem with that as an extension, as long as our latest-greatest mockup is the default view Some applications and even games have multiple UI modes like basic/advanced, I imagine a basic mode is closer to the latest mockup with less information seen, it's better for noobs and those who like clean minimal layouts. Advanced mode could be packed with stats, either a completely different UI design or several slide-out panels, toggled by a hotkey and as a permanent config option.

That kind of thing has been around for a long time. What I wonder is how easy is it to find "good" parameters? I've always seen mentioned that it's quite difficult. And more practically, can it generate trees that work well with alpha testing rather than alpha blending, which I think will be our preferred method of rendering trees (lots of little leaves/branches would look ugly)? About animated trees: can people link or make some videos showing animated trees in other games? I tried looking up AoE3, BFME2, and only saw very slight tree animation and not clearly on every map, understandably most people show off gameplay in their videos rather than graphic effects I don't own any such games.

Hmm, I disagree, wouldn't it be a bit melodramatic if one of your scouts ran into 10 enemy soldiers and this epic battle music started? I mean it's something you want to know about, yes, but I wouldn't say a battle was impending. I'm leaning toward Pureon or quantumstate's ideas of using damage or unit death rates to trigger a battle. Once we have that implemented, it should be easy to playtest and find reasonable thresholds. We could also make them configurable, so players choose how severe a situation is before they get notified. Whereas with some of the more complicated solutions, you don't have that simple means of tweaking the behavior.

We have finite space to show information, we have to be very careful with how we use it. Actually last night it occurred to me that even the two-row attack/armor stats are insufficient, because some units have multiple attack types (e.g. melee and charge), so it gets even more difficult to squeeze in everything. Others might disagree, but here's the crux of my argument: attack/armor stats are static data, they are fixed for every unit with the exception of applying technologies and maybe auras. They are also only a part of the combat stats for a given unit, which includes attack range, timings, speed, bonuses, priorities, accuracy, splash damage and such. Why should we cherry pick one subset of that static data and devote a large chunk of the UI to it, when it's not useful for most players and can be presented in better ways (tooltip, tech tree, stats table)? By comparison, we have to expliclty show dynamic stats - the user can't guess HP, XP, stamina or resource count, and they are as important or more for new and casual players than experienced ones. The new mockup does show more information than the old design. It shows the generic and specific names, ties XP more visually into the rank insignia, shows the player's name/civ/color (legibly!) at a glance, and labels the stats bars. Even if it didn't, there's nothing wrong with revamping the old style

Just want to point out backslash is on a separate row on my keyboard (US), and so may not be the best for a default:

Ticket created to track this issue: http://trac.wildfiregames.com/ticket/1496

My original assumption was incorrect, but I created a ticket to track this issue: http://trac.wildfiregames.com/ticket/1496

Ok, that did it, it needed towers with garrisoned units being under attack. I looked and a few units had died. My guess is it needs to handle dead units properly (trickier than it sounds given splash damage and how we create corpses).

Let's try getting closer to this, which had a pretty good consensus a few days ago. Showing the armor/attack stats just doesn't seem feasible without throwing it all out of balance. Basically, allocating a space just for rows of attack/armor stats gives them precedence over something else in the UI (and in a prominent location as the eye will travel from the top edge down), but they're static, precedence should be given to dynamic data like resource count, HP, XP, etc. where the user actually needs to look at the UI to see what's going on.

I reaaally like that emblem under the player name. Otherwise the only way we have to find a unit's civ is a tooltip on the player name. It's perfectly feasible if we get the sprites made (perhaps in monochrome with high contrast so they look OK under different player colors?)

Construction, training and research completion are in the same class really, being "private" sounds The way it's implemented now, those sounds originate from a certain entity in the simulation, which has no knowledge of which player is viewing the game. It calls the sound manager directly. We could add another layer but at some point it boils down to the simulation triggering a sound for a certain player, and our needing to filter out messages/events/sounds for other players. There will also be UI sounds that several players should hear: minimap flares, taunts, and so on.

Ugh, no. That means in wide screen layouts you're constantly moving from the far left to the far right sides, with your eyes to see what you selected and with the mouse. If we want to use corners, related controls should be on one side or the other. But personally I would rather focus on the center layout for now, and once it's solidified, consider the corner layouts as options.

That overlap is not a big deal though, unless it's ugly like it is now. What I mean is it's not critical to see the full specific name at all times and most of them are short. It might be acceptable for resource counters to partly obscure long specific names since that will only occur during gathering. We could add a darkened background to the resource counter so it hides text underneath. I like the spacing of the latest design and sacrificing that by squeezing pixels would ruin it

I keep trying to reproduce that error but haven't even seen it once. That might be part of the obstacle to fixing it. Any exact steps to replicate the bug (or an Atlas sandbox map) would be welcome.

Think of it as being roughly the same as actor animations. We don't hardcode every possible animation name (<IdleAnimation>, <WalkAnimation>, etc.) , instead they are an attribute of the animation tag so that adding a new animation is very easy. It makes sense to handle textures the same way if only for consistency: <animations> <animation file="biped/animation.dae" name="Idle" speed="50"/> ... </animations> ... <textures> <texture file="skeletal/texture.png" name="base"/> ... </textures>

Very easy for sed to handle or even Notepad++

Why deprecate it, why not replace it now? It's not like we have hundreds of people working on actors, maybe a handful of artists and if they get a parse error while testing it, they'll complain to us, then we can tell them how to fix it (We don't have to worry about third party mods either, they should expect breakages of old data files as the engine and gameplay progress, and there's not many around yet anyway.) We should use whatever structure and names makes the most sense. I think <sampler> sounds more obscure and weird than <texture> and has more to do with the internal implementation than what defines an actor, so it wouldn't be my preference.

Very nice idea I think it might be the best layout so far: I like how the portrait has a player color shading around the border (it unifies the whole panel) and the way combat stats are fit in is pretty clever - legible but not distracting. The thing I worry about is the resource counter possibly overlapping a long name. Somehow it doesn't seem a major concern looking at how slick the rest is. Minor bug: buildings and treasures show the stamina bar.