*MAJOR* issue that needs to be fixed before release

*MAJOR* issue that needs to be fixed before release

Discuss the source code and development of Spring Engine in general from a technical point of view. Patches go here too.

Moderator: Moderators

User avatar
Caydr
Omnidouche
Posts: 7179
Joined: 16 Oct 2004, 19:40

*MAJOR* issue that needs to be fixed before release

Post by Caydr »

I was afraid this would be lost in the other thread, so I decided to post a new one on the topic. It's a really important matter.

I just played a quick test game, I found that when something leaves your LoS even for a split second, everything that was attacking it loses their attack order. I understand the reason for this - it fixes an exploit. But I think a timer is needed, rather than an instant order removal. If the order stayed for, say, 5 seconds after LoS is lost, or better 10 seconds, it would not be exploitable in the way it was before, at least not to nearly the same degree, and the problem I saw would not happen.

Seriously, this is a *major* flaw. Imagine attacking an Annihilator with a bunch of far off units supporting come cannon fodder that's rushing up to it - basically the best way to kill them. Every time the cannon fodder that was spotting for you is killed, you lose targetting instantly, even having to tell the cannon fodder to attack again, and losing extremely valuable time when your entire group is probably under fire.

Please fix this before release. It's critical.
User avatar
ILMTitan
Spring Developer
Posts: 410
Joined: 13 Nov 2004, 08:35

Post by ILMTitan »

I agree.

An even more troublesome example is using a lone bomber to attack a unit. It might not be able to line up a run only while a unit is in its line of sight.
Warlord Zsinj
Imperial Winter Developer
Posts: 3742
Joined: 24 Aug 2004, 08:59

Post by Warlord Zsinj »

Yeah, from the sounds of it, this "fix" could well create far more problems then it solves. I think perhaps another way around is necessary.
User avatar
Guessmyname
Posts: 3301
Joined: 28 Apr 2005, 21:07

Post by Guessmyname »

If the unit's out of 1.5 the los radius, maybe then the attack orders should be lost
User avatar
rattle
Damned Developer
Posts: 8278
Joined: 01 Jun 2006, 13:15

Post by rattle »

How about introducing a new tag called PursueRange. And while we're at it EngagementRange. They determine how far they pursue their target and when they engage enemies (they're kind of related, that's why I put it there).

Another way around that would be to keep stuff which is out of LOS visible as ghosts for a set amount of time (30 to 60 seconds perhaps).
Zirjin
Posts: 3
Joined: 19 Aug 2006, 08:10

Post by Zirjin »

I don't know the exploit at all. But what about the orders are maintained for as long as the unit is visible on radar, not just LOS?
User avatar
jackalope
Posts: 695
Joined: 18 Jun 2006, 22:43

Post by jackalope »

Zirjin wrote:I don't know the exploit at all. But what about the orders are maintained for as long as the unit is visible on radar, not just LOS?
this sounds reasonable to me
User avatar
KDR_11k
Game Developer
Posts: 8293
Joined: 25 Jun 2006, 08:44

Post by KDR_11k »

rattle wrote:Another way around that would be to keep stuff which is out of LOS visible as ghosts for a set amount of time (30 to 60 seconds perhaps).
I wrote a proposal about that some time ago that units would keep shooting at a ghost (called it virtual unit back then) when the target leaves detection and would pick the next unit that matches the target description (i.e. same unit type with LOS or any radar blip moving at roughly the same speed with only radar coverage) if any come into range before the ghost times out. The ghost would move linearly with the target's max speed since your units could only guess where the target may be, they don't really know it. That way your units don't know more than you but they'll try their best to fulfill their orders.
User avatar
krogothe
AI Developer
Posts: 1050
Joined: 14 Nov 2005, 17:07

Post by krogothe »

IMO it should always keep targetting for buildings, out of LOS/radar or not. Its not like its gonna move!
As for mobile units, targetting should be lost for units that leave both radar and LOS, but not just LOS. For bombers that might complicate things a little but its only fair!

Having moving ghosts will be a source of annoyance because units will be wasting firepower on something that probably wont be there (certainly not against a skilled player), wasting huge amounts of micro time for the attacking player. Other things like attacking units of the same descriptions is a source of more pain and unwanted behaviour, we cant forget combat can involve hundreds of units not five.

Im also worried about the effects of this change on KAI, since it used out-of-los targetting.
colorblind
Spring Developer
Posts: 374
Joined: 14 Mar 2005, 12:32

Re: *MAJOR* issue that needs to be fixed before release

Post by colorblind »

Caydr wrote:It's critical.
Not really. Ever heard of force-fire? :)

The bomber problem is annoying though; when I have the time I'll try to work on a solution. Don't get your hopes up though.
User avatar
Neuralize
Posts: 876
Joined: 17 Aug 2004, 23:15

Post by Neuralize »

Yeah, but having to force fire an entire attack group of units, on the move?

They're going to stop moving, and thus your units become vunerable to whatever they're circling or running away from.
User avatar
Caydr
Omnidouche
Posts: 7179
Joined: 16 Oct 2004, 19:40

Post by Caydr »

It most certainly is critical. Posting Spring with this system as-is would be a disaster.

Even the method I mention would only fix the problem part of the time.

I really can't think of a perfect solution. This "fix" that was done corrects something that was highly exploitable, but in turn has broken the majority of the game.

Hm... here's something that might fix the problem better. Maybe the unit keeps tracking of whatever it's attacking for 5 seconds after it leaves LoS, and beyond that will just attack the "last known position" until the unit it was assigned to attack is seen elsewhere.

This would solve the problems with medium-range combat (artillery with spotters, for instance), bombers, etc... Does anyone have any other ideas?
User avatar
FoeOfTheBee
Posts: 557
Joined: 12 May 2005, 18:26

Post by FoeOfTheBee »

Zirjin wrote:I don't know the exploit at all. But what about the orders are maintained for as long as the unit is visible on radar, not just LOS?
This plus maintaining the order indefinitely for buildings would be my preference.
User avatar
krogothe
AI Developer
Posts: 1050
Joined: 14 Nov 2005, 17:07

Post by krogothe »

Foe OfTheBee wrote:
Zirjin wrote:I don't know the exploit at all. But what about the orders are maintained for as long as the unit is visible on radar, not just LOS?
This plus maintaining the order indefinitely for buildings would be my preference.
+1
Using arbitrary things like 5s or 1.5x range is plain bad design and hacky fixes IMO
User avatar
Caydr
Omnidouche
Posts: 7179
Joined: 16 Oct 2004, 19:40

Post by Caydr »

So what happens when you don't have radar, you're just fighting with kbots. The enemy kbots leave your LoS for a split second and yours stop moving and fighting.
User avatar
KDR_11k
Game Developer
Posts: 8293
Joined: 25 Jun 2006, 08:44

Post by KDR_11k »

krogothe wrote:IMO it should always keep targetting for buildings, out of LOS/radar or not. Its not like its gonna move!
Yes but it shouldn't stop shooting when the building is dead, i.e. the command gets converted into an attack position order.

Hm, maybe convert attack orders that leave detection into fight orders unless hold position is set?
User avatar
Machiosabre
Posts: 1474
Joined: 25 Dec 2005, 22:56

Post by Machiosabre »

though I imagine it would be really annoying for modders it seems like having a range in which units stay targeted per unit would be the best solution, it'd be impossible for some timer/range for everything to take both ,lets say, bombers and llts into consideration.
User avatar
Caydr
Omnidouche
Posts: 7179
Joined: 16 Oct 2004, 19:40

Post by Caydr »

An addition to modrules.tdf, maybe?

I don't know. I just hate to see such a brilliant release marred by this.
10053r
Posts: 297
Joined: 28 Feb 2005, 19:19

Post by 10053r »

So here's a good solution to the problem in terms of gameplay. It is probably a bad solution in terms of how easy it is to impliment.

When unit 1 has an attack lock on unit 2, the old behavior was for unit 1 to pursue unit 2 to the ends of the earth, and always know where it was. This was obviously a problem, especially for commanders and berthas on commander ends.

Let's think about it from unit 1's point of view. I'm a basic artillery unit, and I've been told to kill a commander. The commander walks out of my range of sight. Obviously, I should keep pursuing him. The death of the commander is obviously more important than my own life. How do I know where the commander is? I don't. But I do know the commander's top speed and how long ago I lost track of him. This means the commander's position, from my point of view, is a circle, possibly modified by terrain, which is expanding every second. If I only lose track of him for a second (say because the fink overhead is circling round for another pass), I still have a pretty good idea of where he is. I should pick a random spot in that small circle and fire at it. If, however, I am pursuing him and he is getting away (because he is so much faster than I am), then I should start firing at random spots in the circle, and possibly moving myself to get into range of them. The next commander (or decoy) my team spots which is inside that circle automatically deletes the search radius and turns it back into an attack order. The circle is deleted out of my memory after x time (say 1 minute at game speed 1), or when the circle covers the whole map.

Obviously this wont be easy to code. But it is the RIGHT thing to do. It gives our units the intelligence we expect of them, while eliminating the exploit. Here's some psuedo code:

Repeat forever {
if (targetisvisible(target)) {
attack(target.x, target.y)
else {
searchcounter = 0
while (searchcounter < 60 and searchcounter*target.speed() < mapsize and not(targetisvisible(target))) {
attack(randomnumberbetween(lastknownx + target.speed() * searchcounter, lastknownx - target.speed() * searchcounter), randomnumberbetween(lastknowny + target.speed() * searchcounter, lastknowny - target.speed() * searchcounter))
searchcounter++
}
}
}

This doesnt take into account terrain, but that might not be neccesary for reasonable gameplay.
User avatar
Soulless1
Posts: 444
Joined: 07 Mar 2006, 03:29

Post by Soulless1 »

In case the previous suggestion (which is very good, imho) can't be done, here's a simple thing that would work for now - in fact, they could both work in unison :-):
_________________________________________________
lets think for a second about the exploit this was designed to prevent:

basically, the exploit involved using an llt or similar to track the location of important enemy units like commanders once they have left LoS

This only works with certain units, since any unit with reasonable speed would just hare off and get shot and couldn't be used to track

so wouldn't the best way be to provide a new tag called, say, 'targetlocktime=x' where x is the amount of time a unit will hold targets after they leave both LoS and radar (this is set for individual units). There could also be another tag, 'lockable=0/1' which would override this and enable a target (this tag is on the target's end) to be held indefinately - this could be given to certain units (I'm thinking mostly of buildings here but its better to leave it flexible)

Then everything would be at the modder's discretion - for example they could set the first to 0 seconds for all immobile units and buildings, since they can't follow anyway and are the most exploitable. Most mobile units could have a value of, say, 10 seconds or so (this could be the default value) and then other units such as bombers could be given above-average values if the modder wanted so that they could be used for long ranged attacks.
Last edited by Soulless1 on 29 Sep 2006, 19:51, edited 1 time in total.
Post Reply

Return to “Engine”