Darkcity

I remembered my password when checking next alpha updates on SVN xd. Folder name was the hint :p

Please share my password too @Sevda. I have forgot it :P. Account name darkcity.

I think there are so many edge cases and event tracking that will be needed. Example: It is a 2v2, P1 & P2 Vs P3 & P4. P1 is building house H1(cost 100 wood) that is 50% completed, and P3 &P4 comes to P1 base. Following scenarions are possible. P3 destroys the H1. In that case he should get the 25% loot (50% of 50%) i.e., 25 wood. P3 destroys 30% progress of the building, hence house is 20% complete. if P1 destroys it, then what is the loot distribution? Ideally no loot to P3 and 50% (50 wood) to P1. P3 destroys 30% progress and P4 destroy 20%. Who gets how much resouces? If we do split between P3 & P4 then extra caculations are added. To simplify we can give all to last player who destroyed it but the even of last time building (50% completion) need to tracked. P3 attacking the house but P1 keep on building. In such cases what is referece event for the loot? Last build % like 5%? P1 resigns while before p3 could desrtoy the building. Ideally no loot in this case. Loot applied for 0% completed buildings? Does building destroy by watch tower's arrow applicable for loot? P3 & P4 attacking together then how the loot is shared? based on damage dealt? What if condition 4 and condition 8 is happening together? There are many edge cases which will require handling. Which will make it complex. I think we can live with current loot system, this will only add complexities. @Stan` @borg- thoughts?

Kicking out feature is already there Capture was removed this alpha but i think it should be added back. We can add that to changes as well to make them more interesting. As @faction02 pointed our capturing empty siege should be easy, and if we make them immovable with garrsion then this will make things interesting. Think of case where, empty siege is laying at enemy base or inside arsenal. You capture the empty siege garrsion your units and start attacking.

Yeah, they can left alone for a while. We can use 3 (which is the current pop taken by siege by the tower). If siege training takes 1 pop, then default speed will be current speed/3 (no pop taken then no speed). Once you garrsion 2 more then its speed becomes same as of now. If you fullly garrsion then 20% speed bonus (We can or can't do this). The idea is to not bind 3 pop to siege forever. That 3 pop should be utilized other place also. Example - battle. But at the same time interaction with siege should also increase.

We already have a feature where you can request attack against a player. I think this should also be the same. When you click on flare, multiple standard standrd command will pop up as mentioned by @Lion.Kanzen. The player will select the command. If don't select any of these and use flare on map, then the popup will close and flare will act as normal present flare, you can mentione the reason in comment. Attaching wireframe for the same. @Stan` Do you think this a small task or big task?

Current boat fighting i think can be improved a lot. Right now it works same as siege tower in water. 2 features which I think are feasible can be added. Option 1: Visible garrsion: It should be visible how many units are there on boat: Some one has already developed this mod of visible garrsion. Attackable units: Units should be attackable. This is work same as walls. The unit can attack other in unit in their range that means boats with archers will have higher range compared to skirmish. The defualt boat firing range will reamin as it is. Unit position: Since max 10 units can add arrow to the boat. 5 units will be 1 side of the boat while 5 will be other side of the boat rest in center. Only side units can attack or can be attacked. Unit Shuffling: In case units on side (attaking unit dies) then unit in center unit (no attacking unit) will occupy his space. This way all units in the boat are useful unlike present where 30 units in the boat are same as 10 on water. Option2: Treat the boat area as a normal surface where garrsioned units are standing and they will attack anything in range and can be attacked. To attack the boat player has to mention sepcifically just like walls. Advanced options Reduce pop taken to 1. First 2 unit will add to boat speed. Speed logic will be current speed*x/3, where x<=2 , and is the number of units garriosned in the boat. Rest units will add to attack. So, we will have less player roaming aroung with empty boat with fast speed. This will make archers as an interetsing units on water as range will important role. The unit damage and boat speed can be balanced accordigly. @borg- you must have had this idea before :p? @Lion.Kanzen interesting enough?

This can be initiated as seprate thread as well. But to add. Splash damange was broken imo in a23, all you needed was just catas and few units to slaughter everything. But yeag some amount of splash damange can be added for exmple elephant attack damage that @borg- was suggesting. It has to be minor so it doesn't become nuisance like a23. For example hit damage to a units should be like bolt shooter but and rest units take 1 damage in lets say 1 meter redius. Point is it shouldn't be op. Back to making siege tower intersting. I have another idea to it. Following can be done. Make siege tower units attackable. In this case units will be garriosned on 2 layers of siege tower 10 on bottom and 10 on top. ground units can attack the units. Point is siege tower units armor will be increased just like wall garriosned units. So, they will behave like moving wall (only for analogy). This logic can be applied to boats also, which I'm in high favor. Allow capturing from siege tower. This will be like giving option to siege tower to both either attack or capture a building. The capture strength will be equal to number of units garriosned in the tower. Point is, Siege units will take less damage compared to ground units as they are garrsioned in siege tower. Movement speed variation as units increased or decreaed in siege tower. I think these conversation can be initiated on separate threads as well. Including improvements for boats.

My thinking was also same @Grapjas. We maybe leave other values like damange & armors but modify movement and attack speed. Also, give bonus for extra garrion so people prefer garrsioning them instead of treating them like normal units which cost more pop but comes with high damage.

Ok, so following changes can be done. Siege will cost 1 pop, and by default values of movement and attack rate and damage will be 1/current pop cost. For example ram will cost 1 pop with 50 cursh, 4.5 second of interval with movement speed of 2.4. As you garrsion more units till 3 (which is the pop cap) stats will increase. Garrsion limit will still be the same as before. Idea is to promote garrisoning using hence people start using them as tactically. We might not stop at just current stats but also allow stats boost by like 20% if fully garrsioned. something like that.

Hello 0.A.D community, I think currently siege engines in general are not interesting to play as they are handled as simple as any unit. I was thinking of introducing following changes to make them more interesting to play. Top level idea: A siege engine shouldn't take popluation to produce but it will not move or attack untill units are garriosned. The attack and movement will depend on unit garriosned. Siege engine popupulation utlization: A siege engine shouldn't take any population or train, that means from current population of 3 to 0. Movement, attack & armor: Movement & attack will varies with respect to the number of units garriosned in the siege engine. While other statics will remian the same. The current and expected values can be seen in following table. Current Expected Inputs Siege type Attack Speed Attack Speed (current*x/pop utlized) Currently pop utilized Unit Garrisioned Crush Pierce Interval Crush Pierce Interval Battering Ram 150 1.5 7.2 50 0 4.5 2.4 3 1 Siege Tower 2.5 12 1 6.3 NA NA NA 2.1 3 1 Bolt shooter 160 4 8.1 0 80 8 4.05 2 1 Catapult 210 7 7.2 0 105 14 3.6 2 1 *Siege tower has impact only on speed and not other stats, as attacks depends on indivudual unit and not on siege iteself. Lets take an exmple of battering ram. With 0 unit garriosned ram will not move or attack. With 1 unit garriosed, its attack damage, speed and interval will be 1/3rd of what is currently there. With 2 unit garriosed, its attack damage, speed and interval will be 2/3rd of what is currently there. With 3 unit garriosned, it will behave as it behave currently. More than 3 will not have attack on stats but you can garriosn in it as per current state. Gameplay cases You can train as many siege as you want but in order to use them, you will need units inside. Depends on your requirement you can garrsion 1/2/3 or more. You are not pop constrained here but at same time you are, but tactically. You can park the siege out of fight and after fight when you wants to kill buildings garrsion units and start. This will also insure to use garriosing units in siege. There are many use cases I can go about. But i hope you got the idea. @borg-, @Stan`, @ValihrAnt, @Lion.Kanzen, what do you guys think? Open for suggestion if you find it interesting.!!

You can do few things till Devs are busy with other tasks. Don't allow late specs. If you don't want your game to ddosed then allow the people whom you can trust to spec and kick rest of them. If still getting ddosed then keep a suspect list and don't allow them next time forward. Or Don't allow spec at all if you want. Still getting ddosed then you know whom to blame :p.

This a core problem that 0ad should address, which is being ignored for long time. Here what we can do. Ask for a email id as optional parameter while user logs into the 0ad (We will show him the text tag that it will be used to reset his password). When he click on forgot password on login panel, we will ask for registered mail and send a mail to reset password. Once reset he can login with new password. @Stan`Please check this.

Hmm, I see. So the only possibility is to totally block the attacks from either side of the wall untill wall is destroyed, but attack from garrisoned units can be allowed and they can also be attacked. It can be tested in a mode if this is a good game play or not. (Prone to many bugs)

Its understandable. But I think there are few possible solution which can be configured and probably will help with this issue. Reducing the range of the unit based on the height of the wall. Example: Archers with range 60 meters. Wall height : 15 meters. Follwoing use cases are possible Archer is standing near the wall, in that case his range on horizontal will be 45. That means he can attach a unit stabding <=45 meter other side of the wall. Archer standing x (<=45) meters away from the wall. In that case he can attack any units standing 45-x meters away from the wall. Archer standing x (>45) meters away from the wall can't attack unit inside the wall. These are the core features that can be implemented. Enhancement feature: The archers visibiity range will also be modified accordingly. Example, Current scenario: any archer standing x (<=60) meters can see inside the wall. Expected Scenario: Any archer standing x (<=45) can only see inside the wall. Note: all ranges here are vision ranges, the deducation of 15 is applied to see accross the wall. Exiciting feature: The projectile to go above the wall. This is somehwat exist already. For example units attacking enemy units garsioned on wall. Similar fashion the projetiles for all ranged units will go above the wall. @Stan` @LordStark, and @Grapjas Let me know what do you think about feasibility of the solution with current supported mechanism we have in place.

There are 2 similar use cases where it can be implemented in main game as well. UC01: Bribing units Current scenario: We can bribe opponent's 1 unit but only to share vision. Expected: Select whether you want to share vision/become your unit. The resource cost for becoming unit will double of share vision. for example lets say, sharing vision cost is 100 metal, then becoming your unit will be 200, and if you bribe with 1000 metal and select become your unit, then 5 ranodm units of opponenet will become your unit. Where should it work? for initial testing purpose it can be done in diplomcay game mode. It will be very intresting to play. UC02: conquering units Game settings: Regicide & word population enabled. Exmple settings, 3 player game, word pop 450, regicide. If a player1 kills player 2 hero. All his buildings and units will be of player1, and his pop cap will rise to 300. It will intensify game play. There are other settings i have in mind but i think for starter this should be enough. Let me know your thoughts @Stan`

Context This is a fair ask. There are multiple benefits to it and a lots of players feel like this should be there. Recently i promoted coral only game play in tgs and most people are started to like it, although the one of issue with that is one mentioned above. The problem it will solve are follwoing. New players are not used to fast paced game play and they are slow in how to handle pop boom, it will help them imporve fast, hence user retention. This is an good to have feature. This will insure people will use this auto train feature more and more. It will promote coral usages It will impact user experience as whole. Like player are seeing that their batch in training progress. There are 2 solutions to above problem. First is mentioned by the @MirceaKitsune. I have some more inputs on top on how to pause the production Example Scenario: Auto queue for 5 women from civic center , currently only 150 food availble. 1. Simply don't start training the que untill you have the required resources. Here training of 5 will be 0% and wil progress only after 250 food is available. 2. or, Start the que prodution and halt at the percentage of the resource availale. Here training will be continune, as long as available resource > %training time completed * resource required. AOE like mechanism. second solution is: (Taking same example as earlier) Drop the que size to available resource. So, here the queue size will drop to 3 and that will continue, the least number it can drop to is 1. If resource available is not enough to train 1 unit then the queue will pause at 1. Why second? this is useful for continuous training of units given available resource. The player doesn't have to wait to reduce size or get resources to produce his next batch. My pick will be go for first. Extra suggestion: For new installation/new players, keep auto train by default.

This can be done by capturing in game clock time and show that time stamp along with the pause so you can capture the differece and guess how much time game is paused. But the question is, is it really needed? if so what are the use cases for it? In my opinion its not needed. Here is why. 1. most player stick around during pause untill they think they want to leave now, so they are not tracking the time limit. 2. They ususally put commnet in chat and it has time stamp in HH:MM format, through which they can guess easily. Let us know why do you think we should have pause time feature?