Spring RTS Engine

:-/

Acidd_UK wrote::-/

Welcome to the other side of the looking glass.

are units able to leave several corpses, instead of just one at a time?

*thinks of killing something at nethack*

mongus wrote:are units able to leave several corpses, instead of just one at a time?

I highly doubt it.

you can't create features via script ATM can you? if you could then this would easily be possible...

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

B + 2.

>.<
he said he is going to implement all of them and that is good
no idea about your question though

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.

Explain concisely (read bullet points) why chunks over gradual reclaiming. Don't say you can hack chunks to work like gradual, I want to see the reasons.

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.

Well I'm going to implement both original system, chunks and gradual so it's probably only worth arguing about to persuade the mod of your choice to use your preference.

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.

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: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.

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.


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.

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?

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?

If no one has thought of that first (i have), your points are good.

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.

PauloMorfeo wrote: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.

Wouldn't it be more logical that a unit thats being gradually reclaimed shouldn't autoheal?

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.

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!

Post I just made above here was directed at Bruce's last post on the first page of the thread, didn't see there were two. Hope it didn't confuse anyone.

Lol, yeah I didn't even take that suggestion seriously :D