(Egyptians)==TASK== Hero: Pharao (New Kingdom Era)

[Stan`]

Okay then do it. Seems like we misunderstood again (I didn't thought you were waiting for me... ))

[Radagast.]

- Fixed proportions.

- Exchanged m_dress_cuffs with m_tunic_short body meshes. Lion, are you sure you created the texture for the tunic? There are some glitches, though they are minor.

@Stan: Oh don't worry, comrade, I'll try to fix it now.

[Radagast.]

Atlas view: short tunic with misproportions + prop misalignment:

Atlas view: short tunic fixed:

Player colour still not showing up for the Pharao's crown cloth. :/

[Stan`]

Fix the Ai Js stuff and I'll fix your crown

[Stan`]

Fixed. There are some issues left with healer and attack.js.

Also rada follow the conventions heads go into heads etc.

[Radagast.]

hehe, I like our Pharao in colour. How did you fix the Alpha channel not being rendered player color. Was it somehow black underneath the Alpha channel? I'm sure I checked that and it was white for me.

Those conventions are inconsistent and redundant as I have called the file "egyptian/head_pharao.*".

Also a props subfolder is misleading as not only those can be props. This subdivision is nonsense. Instead of "props/units/heads/" 0AD had better used "units/heads/" or "heads/" directly.

Furthermore sometimes they call their subfolder "biped", sometimes "skeletal", sometimes they use abbreviations, sometimes the long form. In total the subfolders all are pretty random. The only requirement the engine has are:

art/actors/

art/meshes/

art/animations/

art/textures/skins/

art/textures/ui/

...

All deeper subfolders are inconsitent in 0AD. That's why I got rid of that props folder.

To make splitting civs easier it's now pretty simple:

- generic meshes go directly into art/meshes/

- civilization specific meshes go into art/meshes/egyptian/

The same for all aforementioned categories (animations, meshes, textures/skins/ ...).

Didn't your template changes show a "template not valid" error for the Pharao for you too?

[Radagast.]

There are some issues left with healer and attack.js.

When I committed my fixes today morning, I realized the arising conflicts. Well done nevertheless as you found the correct places and fixed it accordingly (as now each component is registered as global automatically since Sander's r15150 commit!).

I then accidentally pushed without pull ... Radagast sometimes is pretty confused, one of them is forgetting to pull possible changes by other people (This was not very likely so far as noone ever bothered until you did today night .).

Now the issues are fixed.

We can start experimenting with the Capturing algorithm now. Slowly our list gets less depressing, thanks to Stanislas incredible new momentum that makes me accelerate too.

[niektb]

Even though a props subfolder might be inconsistent, I think it is more confusing if you break the coherence with the public mod.

[Radagast.]

There is a valid point in there but sticking to broken conventions has also its downside: it will never change + less new contributors (as the thousands of subfolders make it pretty errorprone and dare you want to move a file, then you have to update all the other files that contain that path too. something that seams to be too complicated).

That only very few people edit xml and even less dare to create new xml in the proper places, shows that the props/ folder can only be misleading (as units also are defined as props on cavalry e.g.).

As there are not many people helping anyway (1 ?) I'll change it as of how it best fits with my future coding plans. e.g. flow of time and a blender addon is planned that generates the prop points + the xml of props + exports the mesh & prop points automatically if it not alredy exists.

Currently it's a lot of work and as Enrique told me, artists go the easy route and instead of creating prop points include the props in the model mesh which is pretty much a nogo in my opinion (it breaks the single source principle, e.g. all props texture space has to be redefined for each civilization).

[Stan`]

Rada : I agree we can do that to gain cleaness. But folders were a mess already. So using default until everything is done reviewed and fixed seems better. I may be wrong though.

I fixed your texture by adding a white layer beneath with 2% transparency.

Edited July 11, 2014 by stanislas69

[Radagast.]

Stan, your clean up is good school and very much appreciated.

It's not too much a difference between props/units/heads/ and simply heads/. So I think it will rather make life easier, but I agree we should clean up the rest.

=> I'll fix the egypt_ vs. egyptian vs. egyptians inconsistency asap.

[Radagast.]

great also that we get rid of that temp folder slowly. Great work, Stan.

If something doesn't fit a category, then we simply put it in the highest level folder.

[Stan`]

There is also a big issue with models using

<variant>

<textures><....></textures>

</variant>

While there is only one model and one texture, which make it look like it's big. We should fix those. I'm wondering if we could have a strict Xml Parser (Just to check we are following the conventions)

In some cases, this can help to have more props for units (ie : mix of axes and swords) but if something is not in the good order everything goes wrong. Also TABS should be used, and Indent correct.

We should define those coding conventions.

I fixed the last bug with Aristeia coming from utility function that screwed up the gui, making the game unplayable for the player no matter what civ was used. I also suggest we avoid as much as possible to overidde game's file.

To prevent this I add -mod=public in the command line. That cleans up my interface, which conflicts with mods. Could we have a manager for that ?

[Radagast.]

There is also a big issue with models using

<variant>

<textures><....></textures>

</variant>

While there is only one model and one texture, which make it look like it's big. We should fix those.

Oh, indeed. They might have missed the concept of inheritance. (e.g. all variants inherit the name="Base" variant).

I'm wondering if we could have a strict Xml Parser (Just to check we are following the conventions)

Historic bruno has something related, at least he often checks the validity of XML and has put in the XML checks in the engine (GUI + templates xml only?).

Also TABS should be used, and Indent correct.

I wondered about this too. Of course 2 spaces as tab stop make the XML less bulky but it's a bit inconvenient if you have to switch your editor back and forth between 2 spaces as tab stop for the XML convention and 4 spaces as tab stop for fitting the programming convention.

I fixed the last bug with Aristeia coming from utility function that screwed up the gui, making the game unplayable for the player no matter what civ was used. I also suggest we avoid as much as possible to overidde game's file.

I think modders + team share this point jointly. That's why Sander & Co improved moddability so much lately by defining components global, splitting files, avoiding file-scoped (and later non-accessible) file-global variables and all the other improvements I forgot (e.g. in config).

The general goal always is to override as few as possible files. We try to extend the existing JavaScript objects/components instead.

I wonder why we had to override the utility functions.

---

Another example:

skeletal vs biped, structural vs structures, props vs miscellaneous, civ vs. civilization.

Sometimes in 0AD we use structural/civ_building.dae and at other times structures/civilization/building.xml .

---

To prevent this I add -mod=public in the command line. That cleans up my interface, which conflicts with mods. Could we have a manager for that ?

If we add this as last parameter, then it resets the state and you can always do this in the mod configurator, though that's not the point of it. Mods might require to override a 0ad/ file or the mod will throw heaps of errors. (see our RegisterGlobal workaround before sander changed it globally in r15150)

[Stan`]

skeletal vs biped, structural vs structures, props vs miscellaneous, civ vs. civilization.

Sometimes in 0AD we use structural/civ_building.dae and at other times structures/civilization/building.xml .

For those, If we want to be cleaner than the original public folder, when we will have the new meshes we should unify the names in our folders, or ask Enrique to do it.

If we add this as last parameter, then it resets the state and you can always do this in the mod configurator, though that's not the point of it. Mods might require to override a 0ad/ file or the mod will throw heaps of errors. (see our RegisterGlobal workaround before sander changed it globally in r15150)

Well If I don't I have a Pony Millenium Chinese Aristeian UI + the default mixed randomly which is bad

[Radagast.]

Another example:

Why shouldn't a siege unit have a props/structural/decals/dirt_4x4.xml attached if it exactly spans 4x4 tiles?

I now renamed it to decals/dirt_4x4.xml which is shorter and less confusing when reusing it for e.g. 4x4 units despite it being intended for 4x4 buildings.

Or what if a mod is created where structures take the role of units ? Where would you look for your models then? In structures/ or structural/ or in the units/ subfolder ?

That's why I prefer skeletal/ et alia over units/ and structural/ over structures/ and having flora + fauna + nature (water et alia) all in gaia/ instead of some water in props/structural/civ_building_water.xml and some plants spread somewhere else.

The building should furthermore not be part of the filename as a water well might as well be reused for other buildings. Instead we should define the well's origin properly and place a prop-well prop point in the building that features a well. This way we can reuse one nad the same prop (in this case a water well) in several buildings without redundancy.

Remember that redundancy only really hurts when you want to change something. e.g. imagine you wanted to change the props texture space ... oO .. have to copy it into all the civilization's struct textures then.

Or imagine you want to change the well to look a bit better. If you have included the well with each building that needs it, then you have a great mess as you have to update each of those redundant wells to make it consistent.

Using single source principle you don't have to bother with that.

Edited July 11, 2014 by Radagast.

[Radagast.]

I furthermore think the props/ folder once was created to hold prop-sets / conglomerates or custom props with shifted origin.

That's what it may be useful for but then it should be called propsets/ or customprops/ (e.g. with a mesh's origin somewhere near to nothing) instead of props/.

Because props makes one think that only those props exclusively can be used with the <prop> XML element.

Anyway, it might be nitpicky and props/ is fine too.

The rest of the subfolders we have to make consistent.

[Radagast.]

prop="props/structures/persians/barracks.xml"

is another example of inconsistency as most of the times the props are split into several individual ones.

I would simply put it next to the structure itself instead:

i.e.

prop="structures/persians/barracks_props.xml"

or something? What do you think Stan?

[Stan`]

prop="props/structures/persians/barracks.xml"

is another example of inconsistency as most of the times the props are split into several individual ones.

I would simply put it next to the structure itself instead:

i.e.

prop="structures/persians/barracks_props.xml"

or something? What do you think Stan?

For this I have an easy idea.

1. If it's only for this building (e.g separated mesh because of the textures) → Same Folder
2. If it's a common prop (e.g barrel, box pile ← Those are not commited and are part of my foundations) → It will be in the props folders
3. Special case : if the prop can be reused as Eyecandy (e.g Egyptian Sitting dogs) they should be in props/eyecandy.

Cons : If everybuilding has a lot of props might become messy.

Edited July 11, 2014 by stanislas69

[Radagast.]

Not bad. Though I would even drop the "props/" as it's completely random. Like "units/" which should also be dropped. It will only make things clearer as pathnames become much shorter.

Why not simply actors/heads/ instead of actors/props/units/heads/ ? Of course a barrel is a prop, but isn't it simply a barrel too and should go into barrels/ and if we don't have enough barrels then simply put it into misc/ or the highest level folder? Remember that structures also can be props (e.g. a tower that could exist both as standalone and as art of a fortress) and yet they are not in folder "actors/props/structures/" but simply in "actors/structures/".

props/ + units/ are conflicting with the other categories (namely structural/ + skeletal/ + gaia/ and so on). It's no good to order things into categories that overlap and are categories from a different aspect (namely units/ + props/ are gameplay categories while the other categories all are thing-real-world-categories).

Another example for severe inconsistency:

For some subfolders helmet/ is used

while for others helmets/ is used.

In 0AD we mix plural and singular for folder names at several places.

I have a wip commit where I try to clean all this up for Aristeia.

Of course it might be a bit confusing if 0AD keeps its mindbending, conflicting/overlapping subfolder structure but well, better fix it now for our mods than later when there are even more files that have to be renamed.

I don't think Enrique should bear this burden to rename all the filepaths. It's no good to do all this manually file per file.

Without command line batch rename and replace that's not possible.

[Stan`]

How did you think I did Hand is long but the way. BTW you broke my forteress (Aristeia) I think we should fix prefix too. All props should be like

misc_type(fauna,prop,embelishment)_name.xml

[Radagast.]

Did I? I beg your pardon, comrade. Please don't fix it yourself yet. I have a giant local commit with almost all files changed. If you commit now, then we surely have a conflict.

I now realized you didn't break the pharao (you didn't even change something in the template). Instead something with Relax XML check criteria seems to be wrong. I can't even load a ptolemian actor in the Atlas editor.

[Stan`]

What is relax XML ?

[Radagast.]

It's some xml validity check or similar.

I think we should fix prefix too. All props should be like

misc_type(fauna,prop,embelishment)_name.xml

hm.. I think you think of props like the real props, not the 0AD gameplay props. Those terms get mixed up quickly.

I think fauna should go with flora + nature into a gaia/ folder.

Special case : if the prop can be reused as Eyecandy (e.g Egyptian Sitting dogs) they should be in props/eyecandy.

Collegue, that's a problematic statement. In 0AD eyecandy are all objects that have not corresponding simulation template. They are only visual, that's why they are called eyecandy.

Not only every mesh object can be a prop, every object can also be eyecandy if the simulation template is removed. Eyecandy subfolders should be dropped too. All the files contained should be sorted into the correct category. If it's a helmet then it should go into helmets/, if it's a structural element, then it should go into structural/ and so on.

If it's eyecandy or not thus not depends on the folder it is in: it's rather if a simulation template exists or not.

[Stan`]

Okay rada, could you make this new organisation on paper (with ALL empty subfolders) using the /tree /a /f CMD command don't know the equivalent on linux, so we could apply it to our mods, and before that discuss it more ?