Gradual reclaim
Moderator: Moderators
-
unpossible
- Posts: 871
- Joined: 10 May 2005, 19:24
Right, to pull this back on topic, I've implemented this patch to change game behaviour to allow gradual reclaim and multiple reclaimers assisting per feature. However, I need to add some logic so that it is mod selectable - my plan is to allow the following options:
A. Only one unit can reclaim at a time
B. Several units may assist reclaim
coupled with
1. Current behaviour (reclaim all resource at end of reclaim cycle)
2. Gradual reclaim (reclaim a % of the feature every tick)
3. Hybrid (reclaim is split into x chunks. E.g. Hybrid 5 would reclaim 5 chunks of resource at 80% left, 60% left etc down to 0% left.)
Now, the problem I have is that I'm having trouble finding when and where Spring reads the mod file for the tags. If any devs can point me towards the right file then that would bre great. I'll keep looking in the meantime
A. Only one unit can reclaim at a time
B. Several units may assist reclaim
coupled with
1. Current behaviour (reclaim all resource at end of reclaim cycle)
2. Gradual reclaim (reclaim a % of the feature every tick)
3. Hybrid (reclaim is split into x chunks. E.g. Hybrid 5 would reclaim 5 chunks of resource at 80% left, 60% left etc down to 0% left.)
Now, the problem I have is that I'm having trouble finding when and where Spring reads the mod file for the tags. If any devs can point me towards the right file then that would bre great. I'll keep looking in the meantime
-
Felix the Cat
- Posts: 2383
- Joined: 15 Jun 2005, 17:30
Since you were all like "omgwtf gtfo" in the other thread, I've copied and pasted my comments here so that you can read them without having an aneurism.
It's important not to arbitrarily limit the number of chunks. The format should be numChunks=x, where x is (surprisingly) the number of chunks, and is not arbitrarily limited to any maximum.
This variable should be per wreck, and if numChunks is omitted it is assumed to be equal to 1, which is current reclaiming. IMO there's no need for a "gradual" reclaim, the modder would simply set numChunks to some high number (100 or so). I could see a problem if numChunks is greater than the number of ticks it takes to reclaim, simply because the engine may update and take out one chunk when the player is really owed 2 chunks, and thus the player gets half the resources he should have.
IMO multipleReclaim should be defined on a mod-level basis as it is unnecessarily confusing to have one feature be able to use multiple reclaimers while another cannot. That is, unless our modders see a use for multipleReclaim on a per-feature basis?
Also, give modders the ability to change the feature through a chunkX=featurename tag; when the number of chunks reclaimed = X, the feature will change to the different feature specified in featurename. This would allow for gradually decaying features along with gradually decaying remaining metal.
Torrasque, I'm not sure what you mean by numChunks=0 denoting "infinite"? Do you mind explaining?
I could see a use for two types of "infinite". First is a feature that takes infinitely long to reclaim and gives no resources (because it has no chunks), however, reclaimability is already settable on a per-feature basis, correct?
Second is a feature that takes infinitely long to reclaim and gives its resource value per tick; this would be something like a "stedda" way of doing geothermals - get a builder to the feature and reclaim and it will give +X metal/energy per tick, where X is its value in metal/energy.
It's important not to arbitrarily limit the number of chunks. The format should be numChunks=x, where x is (surprisingly) the number of chunks, and is not arbitrarily limited to any maximum.
This variable should be per wreck, and if numChunks is omitted it is assumed to be equal to 1, which is current reclaiming. IMO there's no need for a "gradual" reclaim, the modder would simply set numChunks to some high number (100 or so). I could see a problem if numChunks is greater than the number of ticks it takes to reclaim, simply because the engine may update and take out one chunk when the player is really owed 2 chunks, and thus the player gets half the resources he should have.
IMO multipleReclaim should be defined on a mod-level basis as it is unnecessarily confusing to have one feature be able to use multiple reclaimers while another cannot. That is, unless our modders see a use for multipleReclaim on a per-feature basis?
Also, give modders the ability to change the feature through a chunkX=featurename tag; when the number of chunks reclaimed = X, the feature will change to the different feature specified in featurename. This would allow for gradually decaying features along with gradually decaying remaining metal.
Torrasque, I'm not sure what you mean by numChunks=0 denoting "infinite"? Do you mind explaining?
I could see a use for two types of "infinite". First is a feature that takes infinitely long to reclaim and gives no resources (because it has no chunks), however, reclaimability is already settable on a per-feature basis, correct?
Second is a feature that takes infinitely long to reclaim and gives its resource value per tick; this would be something like a "stedda" way of doing geothermals - get a builder to the feature and reclaim and it will give +X metal/energy per tick, where X is its value in metal/energy.
Because there might be some king-of-the-hill type feature that will give you a huge ressource boost if you can hold and reclaim it for one minute? Okay, that's unlikely.
I think that chunk idea was just to prevent those "we don't want any changes" people from complaining about this being forced upon mods.
I think that chunk idea was just to prevent those "we don't want any changes" people from complaining about this being forced upon mods.
This already exists - just have a high metal concentration and/or lots of geo spots in a small area. This immediately becomes a king of the hill type scenario...KDR_11k wrote:Because there might be some king-of-the-hill type feature that will give you a huge ressource boost if you can hold and reclaim it for one minute? Okay, that's unlikely.
Nothing is being forced on mods, if the tags are not specificed by the mod, it will default to the current way of working. This is just to give mod authors more choice.KDR_11k wrote:I think that chunk idea was just to prevent those "we don't want any changes" people from complaining about this being forced upon mods.
Background: The reason I think this would be nice is that currently, if a com goes up on the front line eraly in the game, it's usually not worth trying to get it reclaimed right away. As such, you tend to leave the comm wreckage a while, until you have built some m storage and secured the area. Then when you finally do reclaim the com, the huge one-off m boost seems somehow artificial to me. With gradual reclaim, the idea is to intensify the fighting over dead commanders. Because you receive the metal in a steady stream, both teams will do their utmost to stop the other team getting a builder even remotely close to the wreck. As such, I think it would make even dead commanders an important part of the early game, would make ppl think twice about comm bombing etc etc.
-
dogthinker
- Posts: 33
- Joined: 10 Jul 2006, 09:28
I'm sure you've already thought of these exploits, but I'll throw em out just to be sure... I only have a basic knowledge of the game so these might not even be functional exploits anyway...
1) If I reclaim most of a wreck, then ressurect it, is there a risk I could turn a profit on the exercise?
2) If I reclaim from a live unit that has an autorepair, is there a risk I'm picking up free metal?
1) If I reclaim most of a wreck, then ressurect it, is there a risk I could turn a profit on the exercise?
2) If I reclaim from a live unit that has an autorepair, is there a risk I'm picking up free metal?
-
PauloMorfeo
- Posts: 2004
- Joined: 15 Dec 2004, 20:53
If no one has thought of that first (i have), your points are good.dogthinker wrote:...
1) If I reclaim most of a wreck, then ressurect it, is there a risk I could turn a profit on the exercise?
2) If I reclaim from a live unit that has an autorepair, is there a risk I'm picking up free metal?
1- Obviously, ressurection has to cost metal, at least in those cases. (and i have been complaining that even now ressurection must cost metal. I mean, a unit of 100 metal leaves a carcass of 75 metal. Ressurecting it should cost 25 metal, should it not?)
2- That is the hardest one. To be the most similar to what the game behaves now, gradual reclaim should not work on «live» units.
Bruce, that's a little too complex for this guy's first project I'm thinking. Would be nice for a CnC mod though of course.
I think it's a good idea, but I can't decide whether I'd want it to be continuous or in steps. Like, if a corpse takes 60 seconds, every 15 seconds you get 25% of its value.
You'd have to make sure that the wreckage's value actually changed as the process went on though. Sounds complex.
I think it's a good idea, but I can't decide whether I'd want it to be continuous or in steps. Like, if a corpse takes 60 seconds, every 15 seconds you get 25% of its value.
You'd have to make sure that the wreckage's value actually changed as the process went on though. Sounds complex.
Actually working out how much of the wreckage is left is pretty easy, since you can use a variable that already exists. From the point of view of reclaiming live units, I think this is handled in a different place to reclaiming features, so hopefully won't affect it (tho I will check this).
Resurrecting a unit should cost in this way - what I think would be best would be for you to have to 'pay back' any resources that have been reclaimed from a feature, before the resurrection process begins. But it's a very good point and something I hadn't thought of.
Cheers!
Resurrecting a unit should cost in this way - what I think would be best would be for you to have to 'pay back' any resources that have been reclaimed from a feature, before the resurrection process begins. But it's a very good point and something I hadn't thought of.
Cheers!