Radagast.

Thank you, omg, who is it. I wonder if we just couldn't start another fundraiser. If we start often enough then we might get enough for Philip even. Then we can pay you and RedFox too. And if we have enough fundraiser to get enough aside for a huge amount of interest. Then we could lift off just directly to the moon just as we are. If it's one of the team, we will like it anyway. External developers might do it just for the unimportant thing (the money). Though there might be exceptions.

... incredible. This is complicated. They now use exact rooting, but the compiler couldn't detect it dependably. So Dynamic Stack examination is (still) done to cover those cases. And then Static Stack examination too as the Dynamic method might destroy pointers ... Then the pointers' target locations can be moved even. Ohoho. I hope this is not taking too much time all this moving. REally a giant piece of dangerous and time-consuming changes. Once we have a new computing breakthrough this will all be rendered useless. Won't the conservative method (they introduced 2010) be fine for some time into the future? Still mozilla has come up with a bearable solution by introducing templates Handle<T> (a double pointer, mostly functions use this to allow for an interlayer to allow moving memory even if more than one pointer points here.) and Rooted<T> .. Still incredible complicated as I now would tend to overly root all objects just to avoid it being removed by the garbage collector. Excuse my nooby question: isn't this philosophy of 'developer is responsible for telling which is to be garbage collected' better solved by the philosophy 'developer is responsible of trashing invalid pointers directly' ? I must be understanding this all wrong. Cool the performance update though. Still looking forward to how this turns out. Perhaps pretty useful in the end. Or our doom.

So we need a circling ball with animation. And a way to attach multiple of these props to the head, spine or neck prop point. The distance from the body will be defined by the most natural arm movement animation. So we probably have to do this first. I like it to have them as free units. Could have an aura attached - just like heroes. Can later raise morale once we have this unit attribute. We will change this thing. Should the unit always be juggling or be like a catapult, unpacking and packing? Can start with the former for ease I guess. Flame throwers .. interesting. Really that's something for a small wandering/nomadic people (mini faction). Or something like a neutral trader. We could make them escort the traders. Also the ox-supply-wagons. But this could be left to the user too (via guarding option). If one general one would be enough for all factions? Probably we could reuse the factions already created and only concentrate on the animation at first. Something like an idle animation variant. Then we can add a separate Actor file?

Ah, thx, now I get your point. Will have to dig deeper then.

Good work. Looks good. Cool that the random maps are upcoming. That's so awesome. (no idea on the different texture paint methods though)

Thanks for clarifying. Sounds good. Does it mean a DEFORM bone without influencing vertices is no deform bone anymore and not translated into the PSA file by pyrogenesis? Loosing overview myself . Sorry for the wrong forum post. Can move it? Good idea with the rotatory mill. I think we could simply attach the horse as a prop to the rotating rotary mill prop (like Enrique mentioned). Once we have a speed ratio fine-tuned for the main bone (rotatory) and the walking animation of each unit (via setting the animation speed in the xml ... oh, that might not be possible as it would change globally then? => so only change the rotary speed to fit the already existing horse, elephant, .. walking speed). If we put the building into walking state (the animation needs not necessarily exist, does it? or simply use the idle one then for walking). Then the props also play the walk animation, so the ox, horse or whatever attached to the rotatory. The center bone animation also has to be the walking animation then. Should work out of the box according to: (follow the image gate) We could then later make the run animation play instead of the walk animation for the building (perhaps per toggle button, should have some cost or only available if alarm raised). Then the rotary mill output production would be quicker .. at least visually. On toggle event then also the output had to be adapted. I think Stan will be happy about that. Anyone knows how many bones we should use?

You are right, modding is better than forking. Contributing back after forking/branching is easy in git though. At least easier if fork, development and review and corrections all happen in a short timespan. So that there not too many conflicts. I think it is possible to have an hybrid RPG-RTS; at least without the special things like key control. Though we could redirect the key control from the camera to the unit, so that the unit can be controlled like this. The problem will be the animations to play on the corresponding key pressed. The other way round is way easier: Simply send unit here and there and have the camera simply follow the unit's position (like key Focus) and rotation. That's how I do it first, then add the above paragraph and switch off unit autonomy during this period of 'control'. (Lion would call it mindcontrol .. haha)

Not sure? What do you think? As a multimesh is not allowed, we need each ball to be a separate prop. Can be attached to one and the same prop point, hence bone. Best not the moving think, so the neck or the spine would be suitable. Then each of these ball needs a in respect to circle around in the same manner. Could even use one ball and vary texture/colour via pyrogenesis random selections. Then pyrogenesis should also make the animation start in a offset, best homogenuous to make the arm movement animation of (Enrique's breakthrough) blender biped easy. Still wonder if it could be done easier and with more variation. E.g. make the biped almost let fall one ball. This might be difficult though and one ball animation might no longer be enough. Ah, yes, the animation speed should probably be uniform too unless we manage the biped arm movement in a way that it looks semirealistic in all cases, no matter when a ball comes near.

@Emerson, hopefully others are not shocked too. For me it was shocking first too. Now that we praised that realism so much. Then I thought, well a magic mod would be interesting, e.g. bringing The Lord of The Rings to life. But then I realised it was not serious. Not that pinned down. Simply allowing units to change the position of all objects. That's all. Of course the obstructions have to be moved too. That might be manageable. Will allow laying down weapons and moving them around too. Or pull that stone away from the cave's entry. Or pull that ship on land.

It would as the pathfinder already walk around all entities. So if you drop entities anywhere this might well stop the enemy storming your last hope in the valley inbetween mountains. Depending on weight, many units would be required to pull the obstacles away. Time won to reorganise yourself. Shall we call this gameplay influence?

I'm not sure about this. If you put in an extra bone for parenting the prop point (empty/object) to. Then there is nothing that speaks against animating that extra bone. Of course if the bone count still is okay for the engine.

I would give him a decent starting point in the decision tree. So that his decisions look capable. The less the unit has to build up a useful decision tree itself, the more decent will its conventional military capabilities be. That's how we could handle things wih the Hybrid AI extension. Suitable for heroes that were military leaders. Other, that were fighters, like Hercules, should get other boni. Also, the decision tree should be assigned by the engine on game/map loading. In the hero unit XML we could put a decentness scale like 0..100. There were many military commanders that would qualify as heroes. I would put in a time tag in the XML just for future features. Wraitii recently has adapted the xml actor format already so that prop and main animations (e.g. horse mane and horse) can be synchronised. Will be difficult to decide on the decentness of the heroes though. Btw. the decentness xml should have a target (list) attribute, e.g. target="intelligence stamina"target="dexterity speed"target="wisdom foresigth"target="attractivity charme tallness"I could come up with a formula to put a fitting decision tree out of all those stats listed. Then we had a lot of flexibility to give each hero (and elite units too) a decent uniqueness.

:-) just an idea. Don't even really understand how they do it. Before animating it I had to practice it alot I guess. Surely I had to ask for help from the gentle gender. Alternatively we could animate a jongleuring movement with colourful balls. Or doing weapon tricks like throwing up in air, .. perhaps even a torch? Or gathering mushroom as idle animation? My favorite. Perhaps we need an (epoch/upshowing in history) terminating point of time too. So that the engine knew when to choose the variant less often. Or simply by introducing more new clothes that those overwhelm the past technological achievments/selections/variants. Then no termination point of time had to be given. Though I think there were things that lasted a long time, like water wells or stone masonry. While others like full-armour-knights not lasted too long. So a termination point for each variant might make sense. With a variant I mean everything: Actors, textures, .. all that should have a start and end point from which on the engine chooses often from within these variants. This would ultimately give us the flow of time. Without hard epoch changes. Btw. anyone knows how to alternate between dark and day maps? Because there are night and day maps I was wondering if this couldn't be reused for creating a flow between night and day by time?

How much micro-managing does our community wish? Is it important to have control over the inventory? I would leave it to the unit AI to decide about the organisation of its inventory. (e.g. if the inventory is full it could go home - if it has a home of course- automatically and unload things in the garden there. Would be interesting to see units collect iron and stones from the sea and put it on a evergrowing heap in front of their garden ) That's always possible. To redesign the complete start screen is a lot of work though. So it's recommended to build upon the default 'public mod'. I like the modularity better, i.e. have mod packs with plenty mods that still can be combined wildly. Of course for the online lobby the mod base has to be equal. ... hmm.. otherwise .. we could just synchronise the mods prior to game start. What do you think? We need Josh's opinion here for sure.

Hmm.. I wonder if the movement weren't more like a loop. First to the side looping back upwards ... the forward and down again. Though it might depend on the weight of the hammer. Difficult.

Cool. Shall we try to remove as many files as possible to have it more modular? Just like Sander said to extend where possible. Next weekend I will give it a try. Also I will actually start the Mod manager then. Prior to that I could put up a tool for simplyfying the design docs. Or we use Google Docs? I thinks it's no bad thing. Just like the Egyptian that Lion posted. This port is for Aristeia only, is it? Will have to think about how to best make Idanwins brilliant healer converting mod available for the public mod too.

Thank you michael for this insight. I was wondering about testudo. Now I get it. It's brilliant. Thanks Enrique and all involved. I's getting better and better ... we're on our way. Edit: I would prefer having free choice where to drop it. Once our resource get a triangle or pyramid or rectangle mesh. Not sure which will turn out best in terms of both performance and visual effect.

Once tested Puppy and Slacko ... sadly worse performance and boot-up time even than ubuntu (ubuntu still being much quicker than windows for me). So it's difficult to argue for any. Of course if you have a portable storage only (only USB e.g. and no disk), then this might be the only option. Otherwise, from philosophy point of view, I strongly support ArchLinux. You can search all packages' short/long descriptions,... via pacman -SsSee here for a reference (also for other *nix OS): https://wiki.archlinux.org/index.php/Pacman_Rosetta Reasons: Using all most up to date packages, so no dependency mess.Packages (Gentoo misses that I think, packages are still a time saver: one guy deals with it. Many many profit from it and save time. => Was worth it for the one guy/gal more than if s/he had done it for him/herself only.).No polluted environment/system (start with blanko system, put in what you really need).simplicity (don't get lost in optimisations).Life update. => install once, never have to reinstall and be in danger to loose your programs, data and many wits in the process.more?

Shall we make the knot-binding the idle animation? What about introducing a point of time in the xml, from which on the Engine starts to pick selections/variants from these textures, weaponry/props, ..too. This could result in a quite fluent transient.

Ha, thanks Niek, just mixed it all up again. Knew I'm getting old but that old, no. Not even a 1000 year old would misread Hittiti and Etruscan. Well. Okay Stan, agreed with that. At first I didn't realise it. Still it is a really good start. We can improve upon this easily later. The danger rather is to get lost. To get lost means that everything was for nothing. Everything spread everywhere and nothing finished. What I mean is, having all this art work as whole visual in 0A.D. would keep it alive. People would see it, oneself would see it. Not so easy to forget about it then. And the ingame effect and appearance could be taken as a reference and for comparison of new versions. Much easier and quicker to decide. Also currently we get lost in details while we still don't know if these details are really that relevant ingame. And the versioning system would keep track of changes, so no matter the change, everyone knew, okay, we can easily go back if something goes wrong. (true for artists and developers) A danger that also drives me to dive fully into development, it has to happen ... it has to be put together.

Our units not even have a real beard or nose other than textures. Besides that, still I like your detail. Though not overly stress stan to his utmost. We should not forget that even each smith might produce different looking weapons. So if smith Stan produces a slightly different looking weapon, it's okay. Still your detailed and clear explanations are brilliant, Niek. Also, it's no wrong to go into super detail and perfection, though perfection might be is impossible.

Why, you never know how things develop. Locking is no good - at least in my opinion. If the thread is forgotten no one will use it anyway. Until it's reborn.

Isn't the final goal for 0A.D. to cover a far wider range .. just like 1500BC to 1500AD? Or even farther. So I think it would be desirable to come up with many heroes, no matter which timeframe. Perhaps the mods wil be interested too as mods that are complete and promising might get into the main simulation. So it's not wasted. We could add to the list lateron. Good idea! How could it take so long for me to find it. This is a unit we could plan. The monk or a unit that knows to talk could be used. Or a unit that is 'very convincing'. Well, you know, if a spy has to use citizens to come to information. For such things this could really be useful. Also the monk with many pamphlets could influence the nearby people's public opinion (loyalty towards on government and/or other civilisations). Interesting. Especially for the campaigns this might be crucial. Imagine a trigger making Caesar appear infront of you and he demands an army of you to help Rome. Will you help? Or a strong enemy like the huns being triggered to enter the map in a hit and run tactics. Once Attila's timeframe is reached those efforts would multiply and they would try to conquer it all. So if a heroes time is reached it would really cause trouble -- like celtic /german tribes overcoming your empire's walls. Or mongols invading. Or knights of the cross ... Though what will happen once a leader is killed earlier than reality. It should have some effect, probably it should be completely different outcome then. Still by a random seed new heroes and legends could be triggered, that replace those that now can't come anymore as, let's say, now that Caesar has died earlier in the simulation, Brutus was not born, and similar. (This has more impact if e.g. Philip The Macedonian died too early for his wife to give life to Alexander The Great. What do then? Future planned triggers might have to adapt to the new facts on the ground. Like shifted borders.)

Staying uniform within a mod pack? I'm not sure .. every timeframe uses every colours and the whole palette of variation. For me when I opened this thread I felt like blown away on a higher level .. really it impressed me alot. The first and the third are my favorites. Though the second has a good relation to Etruscan probably because of the reptile skin. Okay, might be I'm totally wrong here. Perhaps it's a silver shield. It's also not looking bad the more I look on it. Still the forth also has some interesting appearance to me, the colours are interesting, something royal, a bit antithetik. The third's colours and effects in the center are undescribable (amazing). The first ... well ... it was the first I saw and this one is really wow. It's wow and nothing less. Lion rocket now even has a sail ingame, together with Enrique. Stanislas' art also is finding its way in. Well done, councillors. You are far superior to my minor self. My bow will serve in the least and tinyiest and most dangerous part of the battle whilst your high honour will stand next to the colourful lord herself, capable men in shiny colours on horses of glory, knowing how to push the world the few inches to change it dramatically. My bow will serve you, my armour might shield you.

Thanks. Interesting. Would love to hear the smith's opininion to that. Perhaps that was a feature and not a bug. Or if they think it's common for the lesser swords. Smiths must have known a whole lot of secrets. I always wonder if they stopped giving them on to the next generations out of frustration .