wowgetoffyourcellphone

No, please no. Do not listen to this. The solution is to fix the movement behavior. Instead of endless fixing balance of an unfinished game the team should be fixing and tweak behavior like unit and group movement and adding all the promised missing feature. The instinct is to throw out the difficuult things, instead of making them great. This game have too much greatness in its potential for small vision.

wratti I try something like this with modding.

LOL Too many opinion.

Howe do you want the Chinese to play?

Graffic style like these would be great:

I think AOEO followed that "painterly" style, but the design work was too cartoony. I can see the AOEO engine being retrofit with the art styleof your link and would work well.

I am sorry Loki, but urban design upon grid pattern was pioneer by Greeks in Hellenistic time, then taken further by Romans as seen here: There are many examples. Even Piraeus in Athens of 5th and 4th century BC was laid in grid pattern. Miletus of Ionia is other example.

you do not know what you are talking about

Could do square citiies for Successors and Romans.

The civ info panels need much new designing anyway.

I agree that there are mamny separate cases that must be judiciously decided upon. And then all bets can be off when a hotkey (Tab is my choice) is pressed. Tab can be the one-stop-shopping that gives the player as much UI-related informations as possible. In Battle for Middle Earth 2, the humans can only build walls within a distance from the castle (0 A.D.'s CC). When you select to build walls, the ring shows up around the castle to show you this range. I think this would be good for 0 A.D.

Yeah, it because selection are rendered with quads instead of with decals. For units this make sense, but with large things like building selection or aura or other things is make more sense to use more vertice like decal.

I would think that visualization would be for important things, like hero (you can only have 1) and static building (there are only a few of these). The female aura is quite inconsequential.

1. Auras are relatively rare. 2. modern graphics cards can handle thousands of instance of alpha blending. The game will not run very well on integrated graphics anyway. If a couple of more alpha blends are a problem for a rig the game can have option to tyrn them off (default: on, of course).

I thinbk firing range is unnecessary, but showing splash damage range or smething like this might be good.

Why not tabs?

I think it better to have a very deep foundation and make it not hug the ground like normal farms, so then these farms will stick out of the side of a hill unlike other farm field. But when placed on flat ground it would be flat like other field.

I have only messaed around with the code as it exists now. I have only added a new selection ring with the <Selectable> element. This right here is only my suggestion of how it could or should be done instead of in Selectable. Reasons for keeping it within <Auras> Helps keep the visual aura concept together with the aura codeGives flexibility because the visual aura does not necessarily have to have the same visual behavior of the selection ringGives flexibility for each aura visualization to be different if deemed necessaryPrevents the need for a custom texture for each building or unit with an aura. If the game combines the selection ring and the aura ring into 1 texture (like I have done above as a test), then you can't keep the selection footprint sizes separate from the aura ring sizes. It has to be one texture.Can give Aura ring the behavior of showing up with preview entity. Footprint/Selectable does not do this for good reason.So, you could have Aura1 and Aura2 and Aura3 each weith different textures and stuff. There might be bad reasons to do this, but I don't know them. <Auras> <Aura1> <Type>range</Type> <Radius>60</Radius> <AlwaysVisible>False</AlwaysVisible> <Texture> <MainTexture>auras/test/1024x1024_aura.png</MainTexture> <MainTextureMask>auras/test/1024x1024_aura_mask.png</MainTextureMask> </Texture> <Affects>Structure</Affects> <Modifications> <Health.Max> <Multiply>1.25</Multiply> </Health.Max> </Modifications> <AuraName>"Eternal Fire of Rome"</AuraName> <AuraDescription>Structures +25% Health within 60 meters of the Temple of Vesta.</AuraDescription> </Aura1> </Auras>

yep did this. \ Now that I mess around more, I think it should go like this: <Auras> <Aura1> <Type>range</Type> <Radius>60</Radius> <AlwaysVisible>False</AlwaysVisible> <Texture> <MainTexture>auras/test/1024x1024_aura.png</MainTexture> <MainTextureMask>auras/test/1024x1024_aura_mask.png</MainTextureMask> </Texture> <Affects>Structure</Affects> <Modifications> <Health.Max> <Multiply>1.25</Multiply> </Health.Max> </Modifications> <AuraName>"Eternal Fire of Rome"</AuraName> <AuraDescription>Structures +25% Health within 60 meters of the Temple of Vesta.</AuraDescription> </Aura1> </Auras>This way you can have different aura decals for multiple aura in same unit or building (so, imagine Temple Vesta here having a healing aura of 40 meters and a Loyalty aura of 100 meters or something). This also keeop all aura graphic separate from selection ring graphic.

thnx! After some play I think it best to not always have AlwaysVisible. And I think the aura ring should be separate like this: <Selectable> <AuraOverlay> <Radius>60</Radius> <Texture> <MainTexture>auras/test/1024x1024_aura.png</MainTexture> <MainTextureMask>auras/test/1024x1024_aura_mask.png</MainTextureMask> </Texture> </AuraOverlay> </Selectable>separate from regular overlay with a radius element (so you can reuse the aura texture with different kinds and sizes of overlays which use footprint size). Mein gott, ther are many ways to do this. lol Because what if there are twoi aura?

Okay, so I try test. Looks like I was wrong and footprint code no long make selections, so intricate selection rings can be created! Here is a test I just did for temple Vesta: <Selectable> <Overlay replace=""> <AlwaysVisible/> <Texture> <MainTexture>auras/test/1024x1024_aura.png</MainTexture> <MainTextureMask>auras/test/1024x1024_aura_mask.png</MainTextureMask> </Texture> </Overlay> </Selectable>

Can be like this: <Auras> <AuraFood> <Type>range</Type> <Radius>60</Radius> <AuraDecal>auras/celts/circle_60.xml</AuraDecal> <Affects>Gatherer</Affects> <Modifications> <ResourceGatherer.Rates.food..grain> <Multiply>1.2</Multiply> </ResourceGatherer.Rates.food..grain> </Modifications> <AuraName>"Rotary Mill" Aura</AuraName> <AuraDescription>Gatherers +20% Food Gather Rate within 60 meters.</AuraDescription> </AuraFood> </Auras>assumes it is in art/actors/decals folder of course. Or done in the <Selectable> element of the etntity with some diplicate of the footprint stuff. Only issue would be to descide if aura decal should only show up when selected, or like with hero star, be 50% see through and then full coloor when selected (best option in my opinion), or show up all the time full color. Or even better, make it option (or maybe this be confuse). EDIT: Changed it from a texture to a decal call.I think would be better to just call a decal than to add a bunch more width, depth, etc.code to this element.

Can be done with selection ring or decal. Right now game is bugged so that footprint create selection area and selection ring is base on footprint size. Instead obstruction should create selection area or something else done like selection ring size put in selection ring code insread of footprint. Maybe extend aura entitycode for input of "aura ring" size and texture.

Confirmed fixed.