Radagast.

This project is declared as cancelled. The concept may have been useful if using the web interface and only the webinterface. We will switch to Java Server Pages which will allow us to reuse my day-before-yesterday terminated 2-year-project. That means we can parse the Documents into XML, though this makes only sense in a one-directional way. I.e. never may anyone alter the civilisation XML/JSON for as long as the design document isn't finished. Or rather: For as long as the document shall be automatically turned into XML/JSON. It will also allow us to upload in DOCX/ODT and have a PDF as well as a preview image generated automatically from it. The files will be handled as follows: Github repository. (simply the quicker and cheaper solution than setting up a system ourselves, and we don't really have secrets in that matter - in contrary, we live from public discussion.) Github repository checked out to server filesystem. Filesystem directly being parsed and altered without the intermezzo of a database. In the process of parsing we keep track of each civilisation's structure in the same way as currently in the PHP web civ editor (i.e. using kind of XPath for both JSON and XML).This most elaborate markup willl be stored and each civilisation will show that fields are missing or 'could' at least be put into service. The last point will ease maintenance and gives a clear overview of what tags/elements/attributes are possible, without losing time by having to look it up.All the other features remain. I.e. the web UI and sorting, filtering and grouping and highlighting and image linking per node ... Later we can think of direct integration into Pyrogenesis, but I fear: It would never make it into the main version. (also because it had to go into the main game and not into Atlas to allow ingame edit, which furthermore had to be togglable and might not be adapted because of being clutter and maybe lessening performance.) Researchers might not be aware of how to commit their changes upstream. We had to start the game when doing research. Something I dislike. It's better to have a web UI and be able to research and get read out aloud by your telecommunication apparatus the historical texts. Allowing you to just put it into the central Web data with ease.I'm not yet sure as to when the repository - which was checked out to the server from github - should be committed. Either put a button there (as we also need a commit message, or perhaps even generate the commit message automatically out of the files which were changed. In the latter case we could even commit on each Save procedure of the researcher. Though I don't know if that's a good idea if many researchers are working and saving simultaneously.)Don't worry, we are getting to a real solution slowly. All before was simply not covering the usecases we have to expect and thus was a dead end.

Which code do we have to update? The XML actors? Just commit it all to our Mesoamerican Repository on Github and I'll check it out (after I created space on my hard disk).

Can't handle binary very well. Github is for versioning and versioning binary is difficult for every such system. But Github handles binary a bit inefficiently. For a design document we either choose XML format or better just not version it at all (if that's not a requirement, this might depend on the amount of researchers working on the same civilization which is not the case for us I think).

It's looking nice. Mesoamericans are growing.

Good work Zophim! That's looking pretty complete to me. Excuse our fuzzy github organisation in terms of research. It's really pretty unclear where to put it. Btw. the combination PDF & Github will not make sense, as PDF is a binary format and Github can't handle binary. If you had docx or odt this would be preferable. (only if version control looks important for you, otherwise just upload it here and it's fine)

iNcog, nice elaboration, though I think the countering fun remains, no matter if a hard or realistically modelled counter system is used. Each unit as you said has its advantages and if you manage to get your long-range, low attack archers positioned wisely then the short-range, high attack skirmishes will have no chance. Or if you put them in front of your battalions first for greater impact (attack depending on distance) and then pull them back quick enough, then it's a victory of strategy and it should be the same for any counter system (as no matter how we model it, finally we have unit types which are better against others in both models: hard & realism/soft). But perhaps I'm missing something. True points this could be both too much data to maintain (and per unit type makes not much sense) and too much micro (the latter only if we wanted to have an order like 'sleep now' for units to recover instead of FeXoR's steady recovering when idle which looks like the way to go.) We could, I just was not sure if the natural decay wasn't the quicker the less power you've left. I thought at first you could maintain power for a long time, the end then came pretty suddenly. (even to death which is the natural result of complete exhaustion by e.g. not sleeping for a week) Hence I figured this'd be the function to use for the stamina factor. (http://www.wolframalpha.com/input/?i=sqrt%28x%29) Though yours gave the modifier less impact and perhaps that's desirable? Also I could be wrong in my initial assumption. Interesting, I think that's the way to go. The fixed-amount per action should probably be directly specified as an attack value (e.g. damage enemy + subtract own stamina). This leads to a problem though as we don't have defensive manoeuvres. i.e. we had to derive a certain amount to subtract depending on if the attack came through or could be blocked. Ok, we don't have block/defensive manoeuvres anyway, though at least we need to make the maximum stamina value depend on the unit health and apply the modifier after that, i.e. we needed to recouple it, doubling the effect of health. See these formulas: %hp_n * (%stamina-hp-modifier_n+1 * %hp_n) / (100 * 100) = %hp_n+1Or if real speed impact (animation has speed attribute as have attacks which makes it possible): %movefrequency_n * (%stamina-hp-modifier_n+1 * %hp_n) / (100 * 100) = %attackfrequency_n+1

That's the short term alternative until I get the long-term solution ready. Btw. it was essentially your idea, not mine.

Interesting that they used caves as store-caves. A storehouse we not yet have or is the corral used as that one?

Do you know which UV maps are broken? If you only repaint textures (not shifting transition lines and not moving parts of the texture) and best also always look at what it looks like in blender, then we should not have to remap the UV coordinates. <-- only guarantueed when using Blender External Paint Autorefresh (as programs) There must be a tutorial about how to edit a texture with Photoshop and see the changes in blender in realtime (I know it's possible when using GIMP). <-- see below Alternatively use Blender's texture painting tools, you can sketch directly onto the 3D model and also on the texture itself. Though I guess you're interested in a realtime Photoshop-GIMP interaction (which I'm not sure exists sure it exists here). External Autorefresh works for both GIMP and Photoshop and not saves the internal UV mappings and such. Thus no more probs like you described. It should give you a boost for future work. (not sure if you could repeat your tweaks using this mode,... it's not yet clear to me how the textures are messed up, but if it's too time-consuming then we'll try to fix the UV maps. For the future then you know your ultra boost External Autorefresh functionality. )

Thx for Dojo + Castle, very usable and nice to look at. (we'd need a way to turn your 2D sketches directly into 3D model. Currently our only way is Via Stanislas ) We have a Chinese faction in Rise of The East and as we took over the development we will probably rearrange the different projects in a more reasonable way, i.e. have the Rise of The East project as a container for all the eastern civilisations we develop. This means, the Chinese will probably get their place from the beginning to the end. While currently, we only have the Ancient variant (which has been evolved far already by Scion Development). The Chinese will have their place in this timeframe (Millennium) too, as the Tang dynasty if I'm not mistaken by Niek's plan.

You are genious! Not only your sketches which we could indeed just use as they are as the corrals. No, you also sparked an important idea: Why not, additionally to time- and civlisation-tagging of art assets, also assign it a global area (position in longitude and latitude and a radius) for making known to the engine where it occurred. This way we could use both your buildings. If we had a chance to use e.g. land / sea / desert / ... / coastline as location-tag too, then we could make the ship appear if built at the coast, while your Swedish variant appears in the Southern viking's areas and the other one in the Northern area. (To allow this to be applicable on every map we could also either merely specify direction, e.g. North/East/South/West. Or we could use geographic characteristics like 'desert', 'marshland', 'coastal', 'mainland', 'river', .. ) The choice of religion looks like a tech or even a phase-up-tech to me. (or depending on the hero/leader you choose to sail under/recruit.)

We are happy about every help, but take your time and don't worry if it takes longer than expected. It's normal that plans get at an angle quite easily.

I think it's pretty fine, the mongols will come into the game at 1100, so that's the second part where we add another bunch of civs (I don't really know if there are enough left other than the Indians / Americans, .. the Rus probably will come into action in the second part too as the British will with their fight against the vikings/Normans/French). The Polish and the Teutonic Knights and The Hungarian could be an option for Part too as they are highly affected by the mongol/tartar/thurk invasion (just like the Rus, the Chinese and the Japanese are, also the remnants of the crusaders). Essentially we can't leave out any faction of Part 1 in Part 2. We have plenty of action in the second part and for that part we will have the time tagging inplace to make civilisations evolve over time (e.g. the Eastern Romans could then be kept as one tribe instead of two). Generally I would even try to abolish the hard-coded civilisation<->art-asset relationship. We should instead use civilisation tagging, i.e. each asset not only has a time-period tag but also a civilisation tag (which can be combined just like the classes now already are, e.g. one asset,e.g. kind of sword can be shared between civilisations, for example if they were in that close contact that it's just obvious they used the same kind of 'thing').

The variety that evolves is very welcome. I read about "level up" where you choose between several options instead of a hard phase-up in another topic. The kind of decision outlined in the OP as to choose between two or more state-forms/caliphates can be done via technologies (phase-ups are techs too). The leadership spawning would need some coding, something like a inline Javascript function in the tech. I think that's doable, but might be difficult to maintain, though I think we should give it a try if we don't find a way to use the current XML modifications of the schemas which are defined in the component/*.js for the same effect (I think creation of unit on tech-research is pretty impossible curently though I don't know if the <modification> element could somehow be reused for this purpose other than in a hacky way.). If we find a consense about whether it should be an Aura or a new Attack type then we can speak about it. The Attack type means that we have to give the attack order explicitely and the strenght of individual enemies will be lessened, one by one. (as we don't have area attack) The aura apparently is a steady effect without deactivation (though this might be possible somehow) - and has an effect in a certain area. Don't you want to give access to all the generals at once, or only the choice between two at a time (as of phase-up)?

GoGood point, I had forgotten that this was posted within Millennium and not Rise of The East. In my opinion and in harmony with our future plan of real flow of time, I would not bother too much as long as the art/religion/et al. is properly tagged with a time range (on base of historical/philosophical research). We could ask MuteLovestone for his opinion ... (the Hannibal AI should be pretty easy to adapt and I would target it, at least we will distribute the Hannibal AI as soon as possible within our mod-pack/project releases.) True, though I think this time we could live with visual bridges (as was noted in the OP: "only ships can surpass"). We can place bridges with MuteLovestone's mod already, so this should not be an obstacle. Of course having people walk across it will not work (especially if also ships should be able to pass underneath). A conversation with Ykkrosh resulted in postboning it until we have found proper solutions for pathfinder et al.. I like the Tea houses. We could introduce a food subtype tea (food.tea) if desired. Though I like the metal production idea too. And it's probably easier that way (let's see). If we start based on the Chinese faction, might this be of advantage? Sounds good to me. We can still add content for other time periods later.

Awesome, do you think it's possible performancewise to plot it ingame as 'realtime' statistics somewhere in the GUI?

No problem. It's great progress colleague. Niekt has fixed some errors which Sander reported. My old beardiness has added a new tech which makes the normal temple a precondition for the large temple being built. The tech is quite expensive and takes a long time to research. Also females will refuse to gather meat because of spiritual enlightenment. All civil gatherers will have a reduced gather rate of 90% (instead of 100% of the current value). That's because all those monks and priests and healers which research the tech need to be fed. Thus there is not much time left to gather for the citiy state. It's an effort to balance the incredible strength of the converting priest which is trainable in the Large Temple.

You even added a hero .

Wow. This is impressive progress. one note: Could you go into more detail please in the commit messages? It should describe as much as to what you changed. e.g. instead of better use: Then people would immediately see how much new awesomeness you added instead of only "fix". You are no longer only our 2D rocket. Awesome!!

Great post. We have to think of a formula for how stamina would go into attack and armour values. Probably just make the units attack frequency slower:attackFrequency = maxAttackFrequency * sqrt(stamina / 100) [attackFrequency] = 1/s Example values: stamina = 100 (fully fresh unit)maxAttackFrequency = 6/min = 6/60 /s = 1/10 /sattackFrequency = 6 * sqrt(100 / 100) /min = 6 * 1 /min = 6 /minstamina = 50 (half power)attackFrequency = 6 * sqrt(50/100) /min = 6 * 0.71 /min = 4.26 /minstamina = 10 (nearly dead of exhaustion)attackFrequency = 6 * sqrt(10/100) /min = 6 * 0.32 /min = 1.92 /minstamina = 0 (total exhaustion, falling to ground, no movement possible)attackFrequency = 6 * sqrt(0/100) /min = 6 * 0 /min = 0 /min

We're working on a workaround. But the proper NavMeshes by shrinkwrapping aka Recast is probably overkill. Discussed it with Tanksy recently and thought of a layered approach but it's pretty obvious now that there would be too much intersection calculations (so this approach is no option). Or we use physics for this (Tanksy already investigated a bit) .. We then had to detect collisions with buildings but needed the ability to climb vertically or jump to get above the object (only then the collision detection will keep the object on height). The problem might be the pathfinder (that's why NavMeshes are required). MattFox had a NavMesh generation working within our pathfinder. He seemed like an expert, but he's gone and has never shared his code (in his opinion it was too slow). (though it was only too slow in comparison to our pathfinder and he did not pay attention to if obstacles/entities are walkable or not.) We could thus try this approach for all buildings only. And then it might work. Until we get this going we should stick to very low roads so that units don't look awkward because they sink through the bottom of the roads. (we could use textures only too, just like Random Maps does it.) But having roads constructable is the first step. And it's a pretty cool one already.

Don't worry, this functionality already exists. So if you place the roads properly next to each other then it's fine.To be able to build roads like walls would indeed be awesome. I have no idea though how it's done currently. But once I have the chance I'll read the files. The bridge model as street is okay for you as a start? binaries/data/mods/public/simulation/templates/other/bridge_wooden.xmlbinaries/data/mods/public/simulation/templates/other/bridge_hele.xmlThe hellenes' bridge has the edge prop: <Actor>props/special/eyecandy/bridge_edge_hele.xml</Actor>And the edge obstruction too.But we should probably cut a bit of the lower part. Also we have build in small pieces to make the road adapt better to the environment (though it will not adapt to the slope as is currently ... looks like engine work to toggle between slope-adaption and always vertical building).

The parent XML is where the file inherits from. That's pretty powerful. e.g. animal.xml contains all general data (plus default values for e.g. speed, ...) and horse.xml then overrides e.g. the speed element, the obstruction size and whatever. You probably noticed that the advanced infantry soldier inherits from the base infantry soldier. And the elite one from the advanced one. That makes it pretty simple to keep the data integrity (as all values which are not defined will fall back to value in the parent file, and if there it's also not defined then to the next parent. and so on. If we reach the root template and there's still no element defined then we probably get an error (if the element is required).

We could rework the bridge to a road. I had many ideas how to do it, but I'm in a somewhat time-troublesome situation because of my job projects need at least one week more heavy care. Perhaps I find time inbetween as I did the last weeks. Thx that you start that early on the roads, Mute. Will think of how to handle the obstructions then. My current plan is to use Edge obstructions (just like for bridges). This way units could not leave the road. Not really realistic, but I'll work on jumping over obstructions anyway.

Updated. Finally webkit is supported now too (google chrome et al. support). Sorting, Grouping, Live Filtering finally working. New site, too. Now we need a save functionality and it's ready to use. But I think of storing all data in the XML + JSON instead of the Database. This way we could still manually edit files locally and commit to the server. (or logon to the server and edit there) I have to think about it a bit more.