Add "Military site" functionality to Headquarters

Bug #536583 reported by astuur
22
This bug affects 2 people
Affects Status Importance Assigned to Milestone
widelands
Won't Fix
Medium
Unassigned

Bug Description

A tribes Headquarters should be both, a waerhouse and a military site.
Though it can be selected for attack there is no option to determine how many defenders should be stationed within the Headquarters, no way to view or kick out individual soldiers (like with military sites) - and soldiers are only stored there.

tags: added: military
Changed in widelands:
importance: Undecided → Low
Timowi (timo-wingender)
Changed in widelands:
status: New → Confirmed
Revision history for this message
Raul Ferriz (raul.ferriz) wrote :

I think that only HQ, because HQ has conquering area, should be able to keep a minimum soldiers to defend HQ, but this will break auto production of soldiers, they are only created when there are no soldiers on warehouse, so a hack should be used here.
So only HQ may have a keeper army, at least one soldier, like other militarysites.

But would be usefull for all warehouses and HQ to show a list of soldiers keeped and basic controls to kick out soldiers and send them to other warehouses.

What do you think?

Changed in widelands:
status: Confirmed → Triaged
assignee: nobody → Raul Ferriz (raul.ferriz)
Revision history for this message
Timowi (timo-wingender) wrote :

A HQ should have its own class. It should be a warehouse and a militarysite. This would make battle code a bit easier. There should only a minimum soldier setting. New soldiers are created if there are less than these minimum in a HQ.

listing soldiers in a warehouse and kicking them out is a different think. I work on some changes to warehouse code to stop storage and send out wares. This works for soldiers too as they are workers.

Please do not add the military stuff to the warehouse class. Warehouses should not become militarysites.

Revision history for this message
Raul Ferriz (raul.ferriz) wrote :

Timowi, what happens if a player want to kick off of warehouse only upgraded versions of workers? Like master miner, to keep out of 'dangerous' areas like frontiers? Do your code support this?

Revision history for this message
Timowi (timo-wingender) wrote :

My code currently does not support this. It doesn't even compile. Perhaps I will add more detailed worker lists to the warehouse windows if it makes sense. But it have nothing to do with this bug. It's only about the HQ. I will write a blueprint and push a branch somewhere after build15 is ready. I work on quite a lot of improvements to the economy code.

Changed in widelands:
milestone: none → build16-rc1
status: Triaged → In Progress
Revision history for this message
Raul Ferriz (raul.ferriz) wrote :

All logic is implemented and on lua_hq branch.

Only UI is needed to be coded. I want to reuse code inherited from wh, to reduce bugs and to keep code clean, so I have requested a new feature (https://bugs.launchpad.net/widelands/+bug/546799).

By now only storage (just like a wh) is showed on hq window, I will add a button to raise a new window just like list of workers to pop up the military list of hq. But this will change to tabs when bug 546799 is finished.

Revision history for this message
SirVer (sirver) wrote :

Sounds good, Raul. Looking forward to this feature.

Revision history for this message
Raul Ferriz (raul.ferriz) wrote :

After deep reading of this bug report, I think that I have in right direction, but still not fully fixed.
By now I have created new headquarters class inherited from warehouse. This is needed to add functionality only on headquarters easily.
Also I have provided a basic ui (still under development) to see ware and worker stock like a warehouse, also soldiers are seen, just like military sites or training sites.

But by now I have not added 'minimum defense soldiers' on headquarters.
I have filled a blueprint for achieveing that in a general term, it is the blueprint for garrison-attackables, so may be in near future this will be implemented.

Revision history for this message
SirVer (sirver) wrote :

Raul, I have not heard of you in a long time. How is the state of your work on this? I feel this feature could be good in build 16.

Revision history for this message
Raul Ferriz (raul.ferriz) wrote :

Hello again SirVer and all others Widelands Developers!

My progress stalled long time ago, more or less at same time when I start to not write anything here ( march or april, I don't remember exactly). I had not free time because of new responsabilities at work and until last month with wedding preparations (yeah, now I'm a married man!). Actually I only have enought time to read mails sent by launchpad, but not enought time to develop things, by now. May be I would have enought free time to work again on Widelands ( I would love to participate on Widelands Tournament, but was impossible to get the time), but at least until end of current year this would not happen, sorry.

If I my memory works good, all my code is on launchpad. If not, then I can search throught my code on home, may be still is there, but I don't promise anything because my disk die some months ago and I'm not sure if that code was on my backups.

Revision history for this message
SirVer (sirver) wrote :

Gratulation on your marriage! :)

There has been quite some changes in the way warehouses work since you last worked on your code. I doubt it will merge/compile cleanly now. I postpone this feature for build 17 as build 16 already has enough features and this one could not be merged quickly. Maybe you'll have time to look at it then again or someone else can pick it up.

Changed in widelands:
milestone: build16-rc1 → build17-rc1
Revision history for this message
SirVer (sirver) wrote :

Well, I guess this won't make it into build 17. I remove it as targetted bug.

Changed in widelands:
milestone: build17-rc1 → none
assignee: Raul Ferriz (raul.ferriz) → nobody
Revision history for this message
Nasenbaer (nasenbaer) wrote :

needed for colonization and military site functionality of ports -> build18

Changed in widelands:
milestone: none → build17-rc1
milestone: build17-rc1 → build-18rc1
Nasenbaer (nasenbaer)
Changed in widelands:
importance: Low → Medium
Nasenbaer (nasenbaer)
tags: added: seafaring
Revision history for this message
Nasenbaer (nasenbaer) wrote :

I set this to Confirmed, as the work of Raul Ferriz is unfortunally no longer mergeable - a complete rewrite seems to be less work than to fix the merge conflicts:(

Changed in widelands:
status: In Progress → Confirmed
Revision history for this message
SirVer (sirver) wrote :

No work has been done on this and I think it will likely not happen. Retargetting. If someone wants to squeeze this into b18 - go for it.

Changed in widelands:
milestone: build18-rc1 → build19-rc1
Nasenbaer (nasenbaer)
Changed in widelands:
milestone: build19-rc1 → build18-rc1
milestone: build18-rc1 → build19-rc1
Revision history for this message
SirVer (sirver) wrote :

Setting to incomplete for bug sweeping.

Changed in widelands:
status: Confirmed → Incomplete
Revision history for this message
SirVer (sirver) wrote :

wow, b16 -> b17 -> b18 -> b19... And now I am suggesting not doing it for b19 either :P. Eventually.....

Changed in widelands:
milestone: build19-rc1 → none
SirVer (sirver)
Changed in widelands:
status: Incomplete → Confirmed
GunChleoc (gunchleoc)
Changed in widelands:
milestone: none → build20-rc1
Revision history for this message
fuchur (fuchur77) wrote :

Currently in the forum there is a discussion about several bugs (https://wl.widelands.org/forum/topic/2786/). Part of it was the missing ability of stationing soldiers permanently in headquarters, warehouses and ports (i.e. topic of this bug). The start of it was the observation in a tournament game that the headquarters of a player was destroyed when a nearby military building was conquered by the opponent. The reason was that simply that no soldier was in the headquarters.

Now I think that all three building types with storage (warehouse) abilities are quite important. So the natural wish is to be able to select a certain number of soldiers stationed in it. Just like in any other military building. (just to repeat the point of the bug report)

To be discussed are several implementation details (I will use the term "warehouse" for all three types):

1. Maximum number of soldiers?

According to the importance of the building it should not be too low. I'd suggest at least 5. But that depends on what kind of playing strategies are wanted. Should it be easy or hard to defeat a warehouse? If the number is too high it would be almost impossible. And if the warehouse is really important the player can build other military buildings next to it to have a certain protection.

2. Should a warehouse be conquerable?

I'm not sure about this. On one side if it behaves like a military building in being attackable so it would only be consequent. On the other side it would be quite an advantage for the attacking player.

3. Should the player get the wares inside the warehouse, at least the basic ones?

I don't think so. That would be too big an advantage for the winning player. The defeated player already lost all the wares which is already (depending on the stock) a big drawback. That should be enough.

"Yes" to points 2 and 3 is favoured by Tinker in the forum thread.

Revision history for this message
GunChleoc (gunchleoc) wrote :

I think we should only implement this for ports and headquarters. Then make it all configurable by Lua, so we can play with it easily for balancing. So, the basic C++ code would be available in the Warehouse class.

Implementation-wise, the best way to go would be to refactor all the solder stuff out of the Militarysite into a new Garrison object. Both Militarysites and Warehouses (including Headquarters and Ports) could then own such an object.

GunChleoc (gunchleoc)
Changed in widelands:
milestone: build20-rc1 → build21-rc1
Revision history for this message
GunChleoc (gunchleoc) wrote :
Changed in widelands:
status: Confirmed → Won't Fix
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.