Radagast.

Theoretically couldn't you limit the amount of cores or at least reduce the clock frequency in the BIOS or using overclocking tools to underclock. Or switch the display update rate down or something. Perhaps even a giant fan, keeping the DVD slot open, removing the battery plastic cover might help, but I'm guessing and consider the additional electricity consumption. Instead open the task manager and terminate all processes you can get rid of. Also tune down that display brightness as far as possible. You can get used to a darker screen. No idea what else could help. Perhaps windowed mode and having a smaller 0AD window area? Or really add this FPS setting but who knows how complicated it may be. Could we jointly create a patch for the GUI files to write to the config and reload this data again? Then we could create a trac ticket and it might be adopted.

hm.. I think templates are gameplay and we talk about game content, art assets and such. The gameplay only knows of structures of units. That's why those 2 folders in simulation/templates/ make sense. While we want to organize the content in the art folders consistently. Now I think it's not necessary to choose structures/ only because of templates/structures/ as the engine also could also one day add a template/machines/ folder. But you are right, it looks like in 0AD siege structures are also structures and machines at the same time. => Perhaps structures/ is the same as structs/ and constructions/ ? (sorry, no native speaker here, am a bit lost with what is the correct expression) If structures/ really also can hold machines, then I would be glad to only use structures.

Hurray on you that has brought us tremendous progress! I have a question: EITHER - structural/ (like in art/textures/skins/) or structures/ (like in art/actors/) - machines/ (new, e.g. for flyingsaucer et alia) OR - constructions/ (or simply structs/ ?) for both machines and structures (as it might be difficult to draw a line, e.g. what if a building could walk, wouldn't it be a machine then?

The idea is to give techs and art assets an optional time tag on which it will be auto-researched. That means they still can be researched manually or even auto-researched if all technological requirements are already met earlier. The timetag therefore only serves one purpose: The time tag only guides the player through history and still keeps it flexible. A timetag for techs already might to achieve what we want (at least if no templates, i.e. generalized promotion functionality, are concerned). The problem here with the roofs can be solved via making the roofs a prop consistently for all buildings (I think Mauryans already do this). Then those props can be switched per actor change on tech research. Here each building to be changed needs such a tech. In this context I wondered if it is possible to trigger all those techs altogether and I think (e.g. a auto-research if preconditions are met) and I think that's possible and done after proceeding to e.g. city phase in 0 AD already! We see that even without flow of time exchanging all building roofs with one global tech must be possible. The flow-of-time would ease our job as props could be exchanged by giving all the different roofs its time tag, but it might well be that this is less accurate than having those roofs auto-researched on technology-dependency is met, if you e.g. researched the wood-tile-construction tech or the guild for architecture or improved timber treatment or whatever (If we knew why they only used straw until a certain period then we could figure such a tech.).

I think you simply create a cavalry template. Then you use a chariot xml as actor. (that's because the chariot speed is no more fast than cavalry velocity.)

I broke it all. Then I disappeared in a call. Now that I'm back on our wall. Fixing this is written tall.

I'll fix some glitches + get rid of some polies. Then I'll commit it. It may take a bit as the roof will be a separate mesh added as a prop. So you can simply drop in your roof (fit it in blender and set the origin to fit the current roof's origin). Then just reference your roof instead of mine in the storehouse XML I'll commit. Don't worry if you encounter two prop-points for the roof (in the storehouse .dae, you don't have to both with it, just have to know what it's used for): - One is for the roof's location in the non-upgraded storehouse. - The other is for the upgraded one. In the commit will also be a tech for upgrading as announced earlier. The tech will add a 2nd floor. To test it I need a working Atlas. I hope the SVN-Relax Validator issues are resolved. Will pull + rebuild.

Sir Stan, I wonder if it's better now.

Epic. I wonder how it looks without silhouettes. ALT +D -> silhouettes (or via Josh's new graphics options menu )

wow. you used one of Sander's garrison points?

Thx, how could I forget? Though don't we want to make it player colour? And/Or give it structure (e.g. wood)? Or did the Han dynasty simply paint it bare orange? Looking awesome from faraway. Also those watering dragons are incedible. *incredible

(And Proposal 1 is what 0AD already uses, inconsistent but it's partly used.) Of course for art/animations/ biped + skeletal subfolders et alia might be useful. Though I think this is the exception. All other main folders (art/meshes/, art/textures/skins/, simulation/templates/, ...) should use the Proposed Filestructure consistently. Did I really say that? Probably I ate too many of those later two things I listed. Of course there are many other things like rocks on this planet. I hope you got that I meant living beings on this planet. :/

hm.. doesn't this indicate once again that the current filestructure is a bit overcomplicated and misleading. Because a lake prop is in art/actors/props/special/eyecandy/ called lake.xml. Where you expected it to be of course. I always thought in 0AD gaia is the name for natura (nature). btw. sorry for my absence, had been alone with all those animals with grandma only and it was pretty funny with plenty of accidents of course. Now I'm trying to catch up with the storehouse. So you vote for Proposal 1 ? Proposal 4 + 1 are my favourites. Both have only a depth of 1. Filestructure 4 is good for keeping civilizations' files separated, thus making separating easy. But Proposal 1 is what I like most.

I'm at it. A question arose: Not all people might agree that there are only animals, plants and mushroom on this planet. Proposal 1: Note: here it is a bit strange that human/ is separated from fauna/ and human/ even is split into heads/ & bodies/ . - fauna - flora - lakes - rivers - structures (including buildings, mechanical structures, ...) - helmets - weapons - shields - particles - heads - bodies (alternatively: - egyptians, - hittite, - assyrians, .. directly as subfolders in the highest level). - ... Proposals 2 + 3: Proposal 4: (by civilization) - egyptian/ -- head_pharao.ending (alternatively: head_hero_pharao if a category is desired) -- body_pharao.ending (here the body_ can be omitted) (alternatively hero_pharao) -- spearman_specificname.end -- shield_round.ending -- helmet_noble_knightscape.xml|dae|png|... -- horse_noble_egyptian_horse_race.end -- beagle_marant.end -- ... - hittite/ -- head_ -- swordsman_speicific_name.end -- ... - assyrian/ -- ... - ... I would advice against a vehicles/ subfolder because this rather is a property (even you can be a vehicle, e.g. for ants) than a definite and clear category. "ending" can be one of xml, dae, png, ... depending on what (enginerelated) type the file is. e.g. a unit texture goes into art/textures/skins/egyptian/body_pharao.png .

You have modeled the dragon watering system. How great is that! The orange around the tower windows surely have a purpose that I don't see. Why did you have to add those?

It's some xml validity check or similar. 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. 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.

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.

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.

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?

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.

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.

Oh, indeed. They might have missed the concept of inheritance. (e.g. all variants inherit the name="Base" variant). 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?). 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 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 . 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)

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, 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.

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).