Radagast.

Embassy is no bad idea, but too much art work for our team of only 2..4 artists. If you can reinforce the team e.g. by recruiting, then it might be different. I think allowing to build more buildings in allied territory is better. And you always can send gatherers as those can already use the allied storehouses if I'm not wrong. Please tell me if I miss the point and that is not enough for team play. Sending soldiers to the ally, the ally then can control as mercenaries is also helpful?

Not only the map, that guy also created all the pony avatars and other drawing himself. Miraculous! Look at that:

For severly damaged ships, they could be sinking very slowly and only once completely destroyed, they leave the game. by the very nature of obstructions (which remain until the ship is fully destroyed or recovered from the ground) no other ship could pass over it (not depending on ship's size for now to simplify a bi).

Capturing will be added by a mod. Conversion of Units via loyalty influence and conversion of buildings via besieging will be added by the main 0AD team. Boarding will also be added at some time. It's just too important in my opinion or how should your melee units garrisoned in the ship involve in a battle? 1) Pull the enemy ship next to yours. (needs pulling animations but could go without for the beginning) 2) Once the ships are close enough, i.e. e.g. obstructions are next to each other then the units should be able to move / walk / jump from one ship to the other. If we simplify: 1) If ships close enough to each other: 2) Then play jumping animation for your garrisoned units and they walk ontop of the other ship using our walking height workaround (which you see has quite some applications ).

Filter by mod type: Reset filters:

Fixed the filter by type. Next adding dependency checking, already begun. Also the mod-info-files (json) for Millennium (Medieval), Aristeia (Bronze Age), Han China (Iron Age), Lustanians (Iron Age) have been added. leper has done a good job.

Nothing important, just a semiofficial project that modders tackle if it's not adapted by the main team. Just like 0AD extended which is 0AD +-2000 years instead of 0AD +-500 years (Iron Age) as it is currently. The council has essentially 2 game projects: 1 Historical project (0AD extended) + 1 secret project. 2 misc projects: Creating Addons for 0AD Iron Age (Han China/Rise of The East + Lusitanians) + Organizing Modders/Contests. At least that's my picture of the situation. Others' may differ.

true, to avoid the system getting busy and fully unresponsive I chose -j1 as default. also true that it's not complicated, but my script can be called from anywhere, no matter in which folder you are. It's arguable if it's useful, but as I already created it, I also wanted to share it.

I would even go farther and make a ship that lost all garrisoned units be unmanoevrable no matter if it's still fully intact or not. (basically the people 'resource' requirement when constructing a ship as it is currently would then become immediately garrisoned units i.e. added as attackable props to the ship). Possible thanks to sander's amazing prop works lately.

Extraordinary post. Increasing vision range by altitude was partly outruled by our lead programmer lately. Increased range by altitude is what we already have and is already quite nice + realistic. Technically it's possible, essentially it's only setting the boat's velocity to 0, such that it's unmanoevrable. It fits nicely with stamina + health: The lower health + stamina are the less quick a unit (soldier, ship, ..) can move. In my opinion soldiers + ships even get unmanoevrable when severely wounded (less than 10% health). Soldiers would sink to ground, for ships the same could happen. It's then up to you to take a prisoner / lift the wrack at some point and repair the ship or to finish off the poor soldier or ship. This would also mean that past battle fields would be fought for as you might save your wounded soldiers / recover your + enemy's damaged ships. Later we could even add more loot like weapons + armour (for resources as loot this basically already exists but is not visible). Great idea for a formation for ships. The vulnerability to be rammed + sinked instantly by other ships (because of the flanks of a ship being very vulnerable) makes it a very interesting formation with a certain risk.

If I were to play 0AD, then only SVN the version. (when I looked into the svn-lobby there were 10 people around or even more, I was quite surprised) In general I see the releases as an unimportant side-action without real significance for the game. Compiling is too easy on Linux (download my shell script for compiling with 1 single command). Wildfire should get paid for packaging releases in my opinion. That 'd help development + be legal. (There is no need for more 0AD players as Philip once said as it would only make his feedback database explode. ) In the current stage of course. Later it may change and of course the releases are a catalysator too. So don't take me too serious, I love those releases.

Didn't think of that flaps-issue yet. Perhaps we should shorten the flaps' length? I'm not sure a separation in crown- and body texture will look better than flaps going through the torso? Thank you for pointing out the benefits of the proper method. I admire the helmet's you create with this method. this image tells it all: Nevertheless I fear that going this way via high poly models and then rendering the details is too much work for our small team and the goal of creating the whole timeline. That's why I prefer using the high poly model directly with as much decimated geometry as possible but not low-poly. This way, fake shadows don't need to be painted (which is tremendous work as can be seen in your tutorials). Instead we use the geometry directly. Those helmets (especially of heroes) don't occur often enough to be worth the trouble (only 1 hero at a time allowed) and therefore I prefer letting the engine do the shading according to the geometry (which implies less redundant textures and thus less RAM used which compensates for the extra polies). I wish I were up to your skills, then I could go the way you outlined. We want to create all art assets for all epochs soon and will be generous with the texture space for the different epoch's materials. If all ropes break, then we can still add more individual textures, but there is the problem that we can only have 1 UV map and thus only 1 texture: <textures> <texture file="bronze_age_materials.png" name="baseTex" /></textures>If we were able to use multiple UV maps and define more textures (which the <textures> element somehow implies and perhaps it was even planned) then splitting it all in individual textures would be great (but I think it's not worth the programming trouble). Or was the <textures> tag meant for blending textures?

I know it's not ideal. Imagine the black being player colour (what it were if it were looked at ingame). capable of using 1x8 pixel texture for the stripes. (currently using 1x64 but it's still redundant) The gold texture size is 64x64 and reusing an existing egyptian texture. It's definitely too low-res. I will create a bronze_age_materials.png texture which will hold all typical bronze age materials. Such a texture will be created for each epoch but Iron Age (where Enrique is going the proper way, see his awesomely detailed tutorials, though we modders neither have enough skill nor enough 3D modelers to go his proper way.).

For drawbridges 2 walking height prop points would be inserted on either side parented to bones of the drawbridge (the wings' bones). Then if we have a max-angle for steepness of walking height prop interpolation, then we'd know there is no passway anymore (because of 90° or let's say >60° steepness as not all drawbridges might draw their segments/wings up such that they point up fully vertical, i.e. 90° degree). This would then interrupt the interpolation and the obstruction would be freed, allowing ships to pass. For that tiles in rivers must be marked as "no obstruction" by the scripting side (javascript). The engine marks some regions as unpassable which could make troubles. If this is ruled out, then removing the obstructions when constructing the bridge-segments (from one side until the other is left, giving the enemy time to interfere as not all segments may be built at once other than when using ships if that'd not be overkill) is all what is needed for the pathfinder to be aware of bridges .

Prop points called walking height have to be inserted in the 3D model. If more than 1 is added then it's interpolated, which will allow for ramps up to the walls. The units then know a height to travel. The pathfinder should be aware of it too which could be troublesome. All credit for the idea to stanislas.

If this is feasible, it should also prevent units from crossing the bridge. I like the similarity to walls you pointed out. In fact drawbridges are possible, even with the workaround, which is somewhat like walkable meshes but one-linear. (and thus working for walkable bridges). It's an idea of stanislas and I think it's the way to go (as walkable meshes will be in 10 years or such and we only want to wait one to two years at max ). The construction of eye-candy (like bridges) is already possible in a mod. Though I think to make bridge models tilable / segments would involve some art work. (i.e. splitting the bridge models into segments) The workaround using prop points 1-dimensional would even allow for units walking on walls in theory.

As Sander said: building size = 2/3 unit size<=> unit size = 1.5 building sizeA 2m unit would be 3m tall then.

2 interesting things I see here: size variation per unit + realistic scale. without experimenting with the latter no idea, but why not.

Celtic hood as size comparison. May it be that I have to rescale the Pharao Ramesses II's crown? Variations: Reference:

Ah yes I remember, via the variant name attribute it's possible to change the variant on the fly. Thanks for making me remember. It brought us flow of epochs one step closer.

ok, as a variant for the pharao. I thought of player color instead of the blue (also instead of red -white and blue-white stripes better let's use playercolor-white stripes as it was mentioned in the art department that all color should be playercolor).

awesome, pretty good example to later test the engine capability of exchanging props on timetag (each linear line). All forks should be added as tech. As I foresee the tech system (and I have a pseudo code draft) one should be able to switch techs for each unit type or even for single units back and forth. i.e. if there's not enough resources for the most advanced helmet, then go back a bit in the tech tree to recruit units with simpler + cheaper items. This means you could provide your modern times tank grenadiers with farmer's sickle if you are really low on resources. The good thing with the back and forth in the tech tree is also that more equal techs are possible which can be chosen from. Switching back and forth in a tech tree is pretty clear to everyone. What I also wished we had is switching in parallel which is also possible via the back and forth! I have highlighted two examples as of where this selection of equal / parallel contemporary techs via switching back and forth in the tech tree can be seen:

why this sentence fascinates me? Will door be destroyable soon? We can use animations to switch props? That means we can switch the Actor with an animation state. Different actor at the beginning and at the last animation frame? I could create the rigs, this kind of rigging is not too difficult. It's rather if there's enough information as of how the walls should look + how the doors should look.

When to get the Reward: Rewards are only payable once more than 5€ are reached. Then you can always ask us to pay via paypal or what ever.

Same for the art team: - if in team + any of the below, then 1€ extra (to motivate people to try to get into the team). submit - 3D model (properly UV unwrapped) 1€ - complete new texture for a 3D model 1€ - animation 1€ (as there are many different required animations this is where most reward can be earned) Anybody must take the reward but me, I will exclude myself from the reward system as I plan to create plenty of 3D models and it would be unfair if I proposed this reward system with my knowledge of me creating many 3d models. Modders + community won't be paid out of the kickstarter as long as they are not in the team. Once they are in the team their recent efforts to get in the team might be rewarded, i.e. get the reward from the kickstarter income. If 0AD wants to go this way and only pay team members or pay once the contributors eventually become team members, then it's fine to me and I would then use my 5€/month to create such a system for modders. To make people desire to learn the whole process: 3D modeling + UV unwrapping + texturing + committing I would propose to only pay half the reward unless the artists (modders in this case) complete the whole cycle of 3D modeling + UV + texturing + git committing. (of course they will be guided. the advantage is that the next time the artists know it all themselves and our output + effectivity increases)