Extending Visible Garrisonning

[Stan`]

Related Ticket : http://trac.wildfiregames.com/ticket/3488

Related Forum Post : http://wildfiregames.com/forum/index.php?showtopic=19898&page=5#entry309635

Until now (above patch) there was no way you could restrict a unit from going visible on top of a building if it was able to garrison. In other terms that means that were you able to garrison an elephant on a wall it would automatically pop up on the wall.

Moreover let's say you wanted a wall like this: w

Currently you wouldn't be able to choose the exact position of the catapult as it would appear on the first spot available. With this patch you can do this.

 

In this case there are three archers slots, plus one for the scorpio.

 

Same here on a boat.

There are some drawbacks in each question. For now current behaviour is used, units are automatically visible, and do not get replaced when killed.
Major drawbacks by implementing the first would be

defensive (fortresses where replacing the defenders may let you vulnerable to capture).

Then, if units are automatically replaced, you could empty a garrisonned building, making it easy to capture.

Major drawbacks by implementing the last would be

attacking (ships where replacing the catapult would be better) or

 

[Lion.Kanzen]

The scale is real problem there.

[Stan`]

10 minutes ago, Lion.Kanzen said:

The scale is real problem there.

For ships, yes. For the buildings not so much.

[feneur]

1 hour ago, stanislas69 said:

Then, if units are automatically replaced, you could empty a garrisonned building, making it easy to capture.

Isn't that an advantage of that approach though? I.e. you have a chance to actually affect how easy it is to capture a building by taking down the defenders. Forcing you to think about whether your units are making the bigger difference capturing or taking out the defenders.

 

1 hour ago, stanislas69 said:

Major drawbacks by implementing the last would be

attacking (ships where replacing the catapult would be better) or

Not sure what you are trying to say here Seems to be a lot missing from that sentence

 

Scaling units should be possible I assume? Maybe it might be difficult to scale them without ruining the animations, but hopefully they should scale with them?

[Stan`]

1 minute ago, feneur said:

Isn't that an advantage of that approach though? I.e. you have a chance to actually affect how easy it is to capture a building by taking down the defenders. Forcing you to think about whether your units are making the bigger difference capturing or taking out the defenders.

Well I didn't think that way but yes it could open new strategies

1 minute ago, feneur said:

Not sure what you are trying to say here Seems to be a lot missing from that sentence

Stupid copy paste. I actually meant this would give a great advantage when attacking, since attacking with arrows vs attacking with let's say the onager, would not have the same impact.

Quote

Scaling units should be possible I assume? Maybe it might be difficult to scale them without ruining the animations, but hopefully they should scale with them?

@sanderd17 told me he tried in the past but he ran into some trouble with units materials... That would solve some issues about realism

[FeXoR]

IMO this concept is not ready to be voted on (or even beeing discussed as such) since there are several questions that come to my mind immediately that aren't mentioned at all:

- Would garrisoned units not visible still add arrows (and/or damage/attack speed) to the structure itself?

- Do the visible units help against capture?

- Can the visible units be targeted?

- Can the visible units be selected?

- Can the visible units be replaced with non-visible garrisoned units? If so how (GUI wise)?

All that questions and the chosen answer have a potentially very bad impact on gameplay, the need of micro-management, the clumsiness of the unit AI and the balance of such structures/ships.

Note that this list is quite likely not at all complete.

[Stan`]

1. No I removed the addition of arrows.

2. Yes as they are members of the building

3. Yes like units on walls.

4. See questions about being able to retreat units or add them back.

 

[FeXoR]

In that case the thing I would want to vote for is not present: Let units on buildings only be a visual thing (maybe representing the ratio of garrisoned units to garrisoning space or don't show them at all).

The main reason is that micro managing unit cycling of the units on top would be annoying (at least for me that is). And IMO defensive structures where there to protect units inside while still being able to return fire (relatively save).

Unit cycling could be automated so that, if low, units on top are replaced with fresh units (Or just deal the damage to the highest health unit). However, that way targeting a unit would likely be very ineffecient and the unit AI will feel even more stupid than it allready does.

What's wrong for you with the current concept?

[Stan`]

Quote

And IMO defensive structures where there to protect units inside while still being able to return fire (relatively save).

What's wrong for you with the current concept?

I agree but the main idea was being able to have small siege engines on top for now if you try that the first unit to garrison gets on top wether its an archer an elphant or a ram.

The idea was just being able to restrict. Nothing more nothing less.

Quote

 cycling could be automated so that, if low, units on top are replaced with fresh units (Or just deal the damage to the highest health unit). However, that way targeting a unit would likely be very ineffecient and the unit AI will feel even more stupid than it allready does.

For now AFAICS units on entities get shooted at first. The Auto replacement thing was one of the question sorry if it was not clear. The main drawback of that is you are able to deplete a garrison of archer that way. See feneur's comment above.

[FeXoR]

To clarify:

If a unit is automatically replaced when low (meaning not dead) the strength against capture won't drop (or?).

If a unit is automatically replaced when dead micromanagement becomes vitally important to keep the units alive (and, at least to me, that seams annoying).

So why have units on top of garrisoned buildings when it will have bad gameplay impact (Edit: If not just for visuals)? (though this might of cause be a matter of taste)

[Stan`]

1. Yes in this case that would work. If the units take cover after being damaged that would solve the capturing issue.

2. Yeah so I guess 1 is better in this case.

3. Well it won't necessary have a bad gameplay impact as you were supposed to be able to have a catapult on quinqueremes for instance. Also that makes defensive building more efficient as they might be able to respond to attacks with more deadly projectiles.

[Lion.Kanzen]

Stan is possibly rescale the unit on top of a building? But not too much, discreet may be.

[Stan`]

@Lion.Kanzen In theory it is. I know @sanderd17 managed to do it somehow but ran into graphical trouble. Still I guess It would be nice to have that patch maybe there's an easy fix.

[FeXoR]

I am sorry if I sound rude ;/

I appreaciate your efford and thinking but...

Please read my comments and think about it carefully:

On 18.5.2016 at 6:07 AM, stanislas69 said:

2. Yeah so I guess 1 is better in this case.

...referring to...

On 17.5.2016 at 0:22 AM, FeXoR said:

If a unit is automatically replaced when low (meaning not dead) the strength against capture won't drop (or?).

...while I stated before...

On 17.5.2016 at 7:51 PM, FeXoR said:

Unit cycling could be automated so that, if low, units on top are replaced with fresh units (Or just deal the damage to the highest health unit). However, that way targeting a unit would likely be very ineffecient and the unit AI will feel even more stupid than it allready does.

...meaning: I think this will have a very bad impact on gameplay:

- Units arround a structure will tend to attack the unit on top of the building.

- Only ranged units will be able to attack that unit on top of the building in the first place.

- If the unit on top is a siege weapon ranged units will cause negible damage so the default behavour will be utterly inefficient. (or the attacking units are siege engines - then they should attack the structure directly)

- If the unit on top is a normal unit there will likely be a lot of replacements for that unit garrisoned meaning even than it won't make much sense to attack the unit on top.

Yes, many of that stuff is related more to the clumbsy unit AI than your idea. Still at this point in developement it is a bad idea to add this.

Other things:

- Only allowing specific units to be placed on top of a building is an unneeded restriction more than an advantage IMO. Preferring units would be OK (but there are all the other issues left to solve)

- This all seams more like a style thingy to me than an actual gameplay feature. Maybe it's just me but I don't like such things at all if they interfere with gameplay.

@rezisable actors: It would be great if that would be possible and IMO a fundamental ability of the engine. For example variety in size would make the game look much more real.

[wowgetoffyourcellphone]

I have been use propped units on fortresses for a while in my mod. The problems with unit AI can be fixed, so I don't think that would be a problem. I think ranged units should auto-attack the propped defenders while the melee units auto-focus on the building itself. Seems like easy change to the unit AI. Of course, the player can manually focus his archer onto the building if she wants to. About cycling, guys, think of ease of use first. Make the feature easy to use and not complicated. You are adding a new combat feature, so keep it simple and direct.

Here's what I think about siege unit propping. Right now no one uses the bolt shooters. Why use bolt shooter right now? They're not unique enough. Let's make bolt shooters the siege that shows up propped when garrisoned. Rock throwers don't show up when garrison. So, now these two siege weapons have different uses and abilities. Garrison a bolt shooter on a ship and it show up on deck. A rock thrower is "too big" and is disassembled below deck for transport. Some kind of logic like this. (Maybe have extra late-game tech to allow rock throwers to show up propped.)

 

Unit scalling when propped. No, don't do this. This will look dummber than if you just keep it way it is (although scaling as engine feature would be nice for many other purposes like FleXor said! Especially for trees, rocks, etc.). Instead, the towers on ships should be scaled up a little bit so the archer on top doesn't look dumb. It would be better to upscale the ship's tower than to have to scale all the propped units down (this is just example).

Remember that the scale of soldier to structures is RTS scale. The "barracks" is about the size of my flat, haha, so scale is way off anyway. You guys have to think in RTS scale. For example, when I advocate battalions, I don't think in realistic scales, I think in RTS scales ("battalion" is 24 dudes, not 1000). So, when scale doesn't look "realistic" you have to remember that this is RTS game. As long as these scales are cohenrent in design a good aesthetic is achieved. Think of thing in aesthetics and authenticity, not realism and accuracy.

 

There is my rant for the day. Achievement unlocked. Two more tier to my final form.

Edited May 22, 2016 by wowgetoffyourcellphone

[Stan`]

@wowgetoffyourcellphone You should probably use my last patch now. It fixes some issues

[wowgetoffyourcellphone]

14 minutes ago, stanislas69 said:

@wowgetoffyourcellphone You should probably use my last patch now. It fixes some issues

Great! I will try.

I will see how modifying it like this works out:

 

  <VisibleGarrisonAllowedClasses datatype="tokens"> 
	Infantry+Ranged
	Siege+BoltShooter
  </VisibleGarrisonAllowedClasses>

 

 

Spoiler

EDIT: Also, I wish patches were submitted as mods so I don't have to overwrite thing in Public mod and I'd have whole files to work with, but I'll make do with what we have.  I could see some problems with development if that were the case, so probably not a good idea.

 

Edited May 22, 2016 by wowgetoffyourcellphone

[wowgetoffyourcellphone]

Patch works mostly as advertised.

 

Small problems. It does not like that I have visible garrison points for gates. Throws error and does not validate the gate entity. It also did not like that I had the battlements aura inherited from template_sructure_defense_wall (it wanted to see the aura in the long and medium templates? This was a weird one and took forever for me to track down). It also really doesn't like that I have visiblegarrisonpoints in the Carth corral (leftover from when I tested sheep food trickle).

 

ERROR: RelaxNGValidator: Validation error: (null):0: Extra element VisibleGarrisonPoints in interleave

ERROR: RelaxNGValidator: Validation error: structures/cart_corral:1: Element GarrisonHolder failed to validate content

ERROR: RelaxNGValidator: Validation failed for '(null)'

ERROR: Failed to validate entity template 'structures/cart_corral'

ERROR: Failed to load entity template 'structures/cart_corral'

ERROR: RelaxNGValidator: Validation error: (null):0: Extra element VisibleGarrisonPoints in interleave

ERROR: RelaxNGValidator: Validation error: structures/imp_wall_gate:1: Element GarrisonHolder failed to validate content

ERROR: RelaxNGValidator: Validation failed for '(null)'

ERROR: Failed to validate entity template 'structures/imp_wall_gate'

 

(There are other non-realated problems with visible garrison points on gates, but that's a different matter)

Edited May 23, 2016 by wowgetoffyourcellphone

[Stan`]

@wowgetoffyourcellphone Can I see your templates ?

@FeXoR My bad I might have been somewhat distracted when answering last time.

Quote

If a unit is automatically replaced when dead micromanagement becomes vitally important to keep the units alive (and, at least to me, that seams annoying).

That's why they shouldn't be automatically replaced IMHO. That is the current state of the patch.

Quote

...meaning: I think this will have a very bad impact on gameplay:

I don't see why this will have a bad impact on gameplay since it's only adding a bit to what's already in the game AKA units on walls. I'm just allowing different kinds of units on buildings/walls.

Quote

1. Units arround a structure will tend to attack the unit on top of the building.

2. Only ranged units will be able to attack that unit on top of the building in the first place.

3 If the unit on top is a siege weapon ranged units will cause negible damage so the default behavour will be utterly inefficient. (or the attacking units are siege engines - then they should attack the structure directly)

- If the unit on top is a normal unit there will likely be a lot of replacements for that unit garrisoned meaning even than it won't make much sense to attack the unit on top.

1 - 2 This is already what happens in the game right now.

3. True, I did not think of that. We are not forced to use big siege engines either.

4. It would make sense since it will lower down the capture protection. And that assume units are automatically replaced which they are not in the current state of the patch.

Quote

@rezisable actors: It would be great if that would be possible and IMO a fundamental ability of the engine. For example variety in size would make the game look much more real.

Dunno how hard it is to do. Wonder if @sanderd17 still have his old patch.

 

[wowgetoffyourcellphone]

21 hours ago, stanislas69 said:

@wowgetoffyourcellphone Can I see your templates ?

 

I hope this is what you need.

templates.zip

[Palaiogos]

Have any of you played Stronghold Crusader or Stronghold 2? The walls should be like that. You could move the units individually on the wall, and units could fire at units on the wall.

[Phalanx]

Here is my two cents, and it's similar to @wowgetoffyourcellphone, is that this is an amazing idea, but this scale of this game doesnt lend itself well to the idea of being able to defend structures that realistically. Look at the Stronghold series for example. That game was able to use that scale because you are defending one castle. In 0 A.D., you can expect to possibly be defending two fortresses at the same time, and this level of micromanaging might be stressful on players (adding to the stress of being doubleteamed. )

 

In short, I think visually garrissoning units is a fabulous idea, only if it is used for aesthetic purposes only. No added mechanics, work just the same as it does now.

Thats my opinion at least.

[wowgetoffyourcellphone]

Well, I did not say game should not be have visible garrison. I say to make it simple.

[Palaiogos]

Compromise:

1. The walls should be like the Stronghold series.

2. The buildings that are garrisoned have the same properties as before (harder to capture, shoot arrows, heal units, etc.)

3. Walls should have an ability to join to structures like barracks, and fortresses, maybe even civic centers like Stronghold 2.

[Stan`]

On 25/5/2016 at 7:34 AM, wowgetoffyourcellphone said:

I hope this is what you need.

templates.zip

I think that's because now classes are mandatory, I removed the optionnal keyword. Sorry for the late reply.

On 27/5/2016 at 11:17 PM, Palaiogos said:

Have any of you played Stronghold Crusader or Stronghold 2? The walls should be like that. You could move the units individually on the wall, and units could fire at units on the wall.

I did play it, but making units movable is another problem, since it relies on pathfinder more than anything else. Visible Garrisoned units don't/can't move, only rotate.

On 29/5/2016 at 8:36 PM, Palaiogos said:

Compromise:

1. The walls should be like the Stronghold series.

2. The buildings that are garrisoned have the same properties as before (harder to capture, shoot arrows, heal units, etc.)

3. Walls should have an ability to join to structures like barracks, and fortresses, maybe even civic centers like Stronghold 2.

Same that's totally different ^^

On 29/5/2016 at 0:50 PM, SeleucidKing said:

In short, I think visually garrissoning units is a fabulous idea, only if it is used for aesthetic purposes only. No added mechanics, work just the same as it does now.

Thats my opinion at least.

Well currently in the game it's used for walls. I am not adding a new feature, I'm extending it to all buildings. This is already in the game.