Units do not turn to fire their Arc-ed weapons

[Caydr]

This thread doesn't seem to be getting any attention in general discussion, so here's a link. Devs please consider...

http://taspring.clan-sy.com/phpbb/viewtopic.php?t=5037

[Argh]

Again, I think this needs to be put to AF or Krogothe, not to to the Spring core developers. I really feel we need to convince them to make the core AI subroutines of Spring much more robust and flexible, period, with more controllable sub-behaviors available via TDF tags. It'd make AI development easier, too, if AI developers didn't have to code battle micromanagement into their software, because Spring's own battle micromanagement was adequate.

That, and I'm hoping AF will get to his pathfinding routines he's been talking about for awhile now soon

[Pxtl]

Again, I think this needs to be put to AF or Krogothe, not to to the Spring core developers. I really feel we need to convince them to make the core AI subroutines of Spring much more robust and flexible, period, with more controllable sub-behaviors available via TDF tags. It'd make AI development easier, too, if AI developers didn't have to code battle micromanagement into their software, because Spring's own battle micromanagement was adequate.

That, and I'm hoping AF will get to his pathfinding routines he's been talking about for awhile now soon

I'd be wary of including too much AI in the units, we don't want this to become MOO3 or Populous, where your units decide their actions in their own inscrutable ways. I just want the obvious functionality to work (Yes, I know your weapon is point blank, but could you be so kind as to attack the peewee that's shooting my fusion reactor that's 4 feet from you?)

[Caydr]

Well krogothe/AF read this forum too don't they?

[ILMTitan]

I'm looking into fixing this. Three options however.
1. The unit turns so that forward is facing the enemy
2. The unit turns so that weapon[0]'s firing arc includes the enemy
3. The unit turns so that weapon[0]'s firing arc is centered on the enemy.

Which is best?
This also assumes that weapon[0] is the primary weapon. I can't think of a better way to determine the primary weapon.

[Argh]

Option 3 is best.

[Sean Mirrsen]

What about units that have no clear "primary" weapon? Like some support ships in Homeworld, they have only point defences. I'd suggest something like an "attackDirection" tag, telling which way the unit should attempt to face when attacking. Defaults to "0 0 1", forward. For the Broadside cruiser of the FF mod, it would be "1 0 0" or "-1 0 0". For bombers it could be an approximation, something like "0 -1 1", forward/down, or just forward.

[FireCrack]

the best way would be to provide a scalar (in the FBI) that indicates the angle to attack from. 0 would mean dead forward, 1 wopuld mean dead back, 0.5 would mean dead to either side, etc...

[ILMTitan]

I don't really want to get into changing the FBI. I just want to make units act in an intelligent manner.

I'm now thinking that I'll try to make the unit orient so that the enemy is within an arc half the size of the firing arc.

Also, this is probably only going to change ground and naval units.

[Caydr]

Great to hear someone's working on this, it's one of the very few remaining things that's holding back any real testing on GEM.

[j5mello]

not to spoil ur happiness Caydr but

Also, this is probably only going to change ground and naval units.

[ILMTitan]

I'm modifying class CGroundMoveType:public CMoveType, so that KeepPointingTo() actually does something. The other two possibilities are CAirMoveType, which also uses an empty KeepPointingTo(), and CTAirMoveType, which implements KeepPointingTo(). I do not know which units use which class.

Also, as I was looking at the code, another thought came up. Currently a unit will stop as soon as any of it's weapons can hit a target. Should this be changed so that it stops once it's primary weapon is in range, but not necessarily able to hit the target, and then rotate?
If one change is made and not the other, I can see a situation in which a unit with a long range frontal secondary weapon and a shorter ranged side facing primary weapon will "wiggle." Once in range of its secondary, it rotates its primary in and secondary weapon away, then decides it needs to move closer to the target because the secondary is out of arc and the primary doesn't have the range. Moving closer would cause the secondary weapon to be in range again, however, causing it to stop and try to rotate for its primary.

[Sean Mirrsen]

Ideally, a unit set to "roam" should never stop when attacking, and a unit set to "manuever" should stop as soon as it is no longer being hit by enemy weapons. A unit set to "hold position" should stop once the target is in the range of at least half of its weapons, but ideally, there should be a tag defining preferred attack distance for the unit. And if not present, that tag should default to "longest range for 1- and 2-weapon, second longest for multi-weapon units". That presumes that a tank with a secondary gun shouldn't close in, but fire its main gun, yet a bigger unit might want to close in so more of its weapons can hit the target.

[ILMTitan]

I need to test my changes on a unit that has a weapon[0] arc preferably to one side and a secondary weapon arc to the front with a greater range. Does anyone know what mod I may be able to find that in?

[Argh]

<shrugs> I'm kind've drawing a blank, trying to imagine a unit that would be designed that way. I can see your point about the "wiggle", but that would only happen if the longer-ranged gun overlapped with the shorter-ranged primary- not a very common occurance, I would think.

[Felix the Cat]

A turretless flamethrower vehicle (arced to the front) with a machinegun mounted facing sideways, so that the two arcs intercept? Only thing I can think of at the moment.

edit. What would be really really REALLY neat is if a mod maker could implement his own unit AI routine in a DLL that Spring would use instead of the standard one. Correct me if I'm wrong, but for modders who have a working knowledge of C++, this would be a far superior way of generating unit behavior than scripting? Of course animations etc. would probably still be better off done via script.

[FLOZi]

It's called a group AI, felix

[Felix the Cat]

It's called a group AI, felix

Fine then. I'll just say for the fourth or so time... allow GroupAIs to be set as inherent properties of a unit rather than having to be assigned by the player.

Do GroupAIs override the core unit behavior coded into Spring?

[ILMTitan]

GroupAI's iirc can only give commands, much like a human, and thus are able to manipulate the core unit behavior, but not override it completely.

[Felix the Cat]

GroupAI's iirc can only give commands, much like a human, and thus are able to manipulate the core unit behavior, but not override it completely.

Well then I guess I didn't communicate well enough.

I want modders to be able to override the core unit behavior. edit. with full, unrestricted access to every piece of information that the Spring engine can possibly make available to the core unit behavior DLL.