less rtard pathing behavior from features

less rtard pathing behavior from features

Requests for features in the spring code.

Moderator: Moderators

User avatar
1v0ry_k1ng
Posts: 4656
Joined: 10 Mar 2006, 10:24

less rtard pathing behavior from features

Post by 1v0ry_k1ng »

in advance, I dont anything about how the pather works etc this is purely a request,

but is there any way to make units treat feature blockage more like impassable terrain, ie, not try and fail to drive through impassable wrecks/rocks repeatedly?
User avatar
smoth
Posts: 22309
Joined: 13 Jan 2005, 00:46

Re: less rtard pathing behavior from features

Post by smoth »

1v0ry_k1ng wrote:feature blockage more like impassable terrain, ie, not try and fail to drive through impassable wrecks/rocks repeatedly?
+9001
User avatar
Argh
Posts: 10920
Joined: 21 Feb 2005, 03:38

Re: less rtard pathing behavior from features

Post by Argh »

Do they obey the Footprint settings of Features (i.e., do Features get written to the path map like buildings do), or do they just bump into Features with a non-passable Footprint, hoping to eventually run over it?

I suspect the latter's the issue. If we made it so that Units could no longer crush Features, short of Lua, it'd make the whole situation a lot easier to manage, imo.
Tobi
Spring Developer
Posts: 4598
Joined: 01 Jun 2005, 11:36

Re: less rtard pathing behavior from features

Post by Tobi »

They obey the footprint of features. (as displayed in F2 view with /cheat on)
User avatar
smoth
Posts: 22309
Joined: 13 Jan 2005, 00:46

Re: less rtard pathing behavior from features

Post by smoth »

still they try to move through them sometimes and get stuck. Also they can get pushed into a feature...
User avatar
Pxtl
Posts: 6112
Joined: 23 Oct 2004, 01:43

Re: less rtard pathing behavior from features

Post by Pxtl »

I'd just be happy to see them stop shooting at them. Seriously, there's nothing as fun as watching a SAM truck spend 5 minutes trying to hit an LLT through a wreck.
User avatar
smoth
Posts: 22309
Joined: 13 Jan 2005, 00:46

Re: less rtard pathing behavior from features

Post by smoth »

It is a flaw with dumbfire missiles pxtl
User avatar
Pxtl
Posts: 6112
Joined: 23 Oct 2004, 01:43

Re: less rtard pathing behavior from features

Post by Pxtl »

I mostly play CA, but I've seen it happen with all manners of projectile weapons - SAM trucks are the most obvious culprits since they're long ranged, low-profile, and particularly in CA they don't fire while moving - so you see them pounding at the same spit of wreckage for minutes on end - and those are homing missiles. It's another particularly nasty snag when you're using low-ROF weapons where every shot counts - nothing like rounding a piece of wreckage with a Kodachi and watching it blast its one rare shot into point-blank range on a broken factory and injuring itself in the process.

Imho, the only weapons that seem to avoid features properly are beam weapons.
User avatar
1v0ry_k1ng
Posts: 4656
Joined: 10 Mar 2006, 10:24

Re: less rtard pathing behavior from features

Post by 1v0ry_k1ng »

Pxtl wrote:I mostly play CA, but I've seen it happen with all manners of projectile weapons - SAM trucks are the most obvious culprits since they're long ranged, low-profile, and particularly in CA they don't fire while moving - so you see them pounding at the same spit of wreckage for minutes on end - and those are homing missiles. It's another particularly nasty snag when you're using low-ROF weapons where every shot counts - nothing like rounding a piece of wreckage with a Kodachi and watching it blast its one rare shot into point-blank range on a broken factory and injuring itself in the process.

Imho, the only weapons that seem to avoid features properly are beam weapons.
and thats why everyone hates trees
User avatar
Argh
Posts: 10920
Joined: 21 Feb 2005, 03:38

Re: less rtard pathing behavior from features

Post by Argh »

AvoidFeature...
User avatar
smoth
Posts: 22309
Joined: 13 Jan 2005, 00:46

Re: less rtard pathing behavior from features

Post by smoth »

. . . should be set to true on default" is the rest of your sentence.
User avatar
Argh
Posts: 10920
Joined: 21 Feb 2005, 03:38

Re: less rtard pathing behavior from features

Post by Argh »

I don't really care, if it's default or not, since I overrode the default to 0 ages ago. Can Features take non-sphere hit volumes these days?
User avatar
Pxtl
Posts: 6112
Joined: 23 Oct 2004, 01:43

Re: less rtard pathing behavior from features

Post by Pxtl »

Doesn't AvoidFeature fail when you want to _attack_ the feature?
User avatar
Argh
Posts: 10920
Joined: 21 Feb 2005, 03:38

Re: less rtard pathing behavior from features

Post by Argh »

Yes. Because there is no true Attack Ground in this engine atm, even orders sent through Lua don't work. And yes, that's a very big annoyance.
User avatar
Pxtl
Posts: 6112
Joined: 23 Oct 2004, 01:43

Re: less rtard pathing behavior from features

Post by Pxtl »

Sounds like a whole mess of features are needed to fix features
- ability to define feature-avoidance-classes so we can have a many-to-many relationship of which weapons avoid which features
- ability to target features (and not just the ground under them) so that a feature that is normally avoided can be targetted
User avatar
Argh
Posts: 10920
Joined: 21 Feb 2005, 03:38

Re: less rtard pathing behavior from features

Post by Argh »

We need a true attack-ground command, that doesn't care about collisions with Neutral Units, Friendly Units, or Features. Then we could just Lua for our cases, i.e., "avoid Features, unless somebody tells you to shoot through them anyhow".

Problem here is that Avoid is all-or-nothing, and can't be turned on or off via Lua atm.

As for movement, if the Unit can't run over a Feature, it should not attempt to move there. Problem is, it's not really detecting the Feature per se, just the blocking-map position and value. Perhaps add an alpha level to the blocking map, and use that to store crush values?

While I'm on this subject... there a problem with the logic drawing the blocking map, where 1-footprint objects sometimes aren't drawing a blocking pixel, due to rounding errors caused by the difference in sizes of the two textures involved (totally fixable, just offset up to nearest valid 1). I suspect this is why Units try to drive through stuff that's supposedly blocking a lot.
User avatar
smoth
Posts: 22309
Joined: 13 Jan 2005, 00:46

Re: less rtard pathing behavior from features

Post by smoth »

are you sure you didn't mean collide feature argh?
User avatar
Argh
Posts: 10920
Joined: 21 Feb 2005, 03:38

Re: less rtard pathing behavior from features

Post by Argh »

No, there's an Avoid as well, i.e.:

Code: Select all

avoidfriendly=0;
avoidneutral=0;
avoidfeature=0;
collidefriendly=0;
collideneutral=1;
collidefeature=0;
User avatar
smoth
Posts: 22309
Joined: 13 Jan 2005, 00:46

Re: less rtard pathing behavior from features

Post by smoth »

Argh wrote:No, there's an Avoid as well, i.e.:

avoidfeature=0;//says that it will not avoid feature when targeting..
collidefeature=0; //says that it will not collide with feature

so your units do not avoid the features and they shoot through them.
User avatar
Argh
Posts: 10920
Joined: 21 Feb 2005, 03:38

Re: less rtard pathing behavior from features

Post by Argh »

Yes. If I had Features in any of my game maps or as part of the game, they'd shoot through them, just like they shoot through friendlies. The only Features in P.U.R.E. were Spring Trees, so it's pretty much 100% redundant atm, since I haven't even had Spring Trees in my game for nearly a year.

Some weapons do not ignore Features and Neutral, so that they impact with buildings, etc. But all of them have Avoid turned off, because otherwise they behaved so poorly that it drove me nuts.

The problems with this are pretty complex, and need engine changes, but I've been saying that for over a year, and got most of the current features out've Kloot, for which I am grateful.

The thing is... we need three things, really:

1. A true attack-ground function, that ignores all Avoid options for the Weapon. Pretty much every RTS has one, and it's usually conditional- some Units can do it, some can't. It's stupid that if we turn Avoid on, that we can't blow up a tree that's in our line of fire, if we need to.

But those are our choices- Avoid doesn't currently have any flexibility, and Attack commands don't understand context at all- an Attack command issued by a Unit's AI is treated like an end-user's explicit command. That's wrong, and the engine should not do that- if I give an explicit order, it should be obeyed.

I don't mind, if my guys won't shoot at a target on the other side of a building automatically because they're blocked. But it really annoys me, that I can neither attack that building, because it's Neutral, so my explicit order is canceled, nor can I tell my troops to just attack anyhow, knowing that they'll have to blow the building first.

Surely it's not too hard to detect an explicit command, i.e., one not issued through the Unit AI (so therefore either from Lua or from an end-user), and if that conflicts with Avoid... then the end-user's command wins. But that's the current situation with Avoid.

2. Smarter Unit AI, where if they've been given a target, and can't hit it due to Avoid, then they'll automatically switch to Fight until they can attack it.

That's probably doable with Lua, I'll look at that. However, this isn't a catch-all system, because you don't want mobile artillery to be issued a Fight command in that situation.

3. A better LOS system, that actually allows for LOS to be obstructed by Features or Units (i.e., the raytraced one that I described months ago that hasn't gone anywhere), so that fighting in dense collections of Units or Features actually deals with LOS correctly, so that you don't have the sad spectacle of seeing the enemy, but having your Units just SIT THERE DOING NOTHING, and refusing to obey your Attack commands if they fail an Avoid test. It's the part where I can watch my Units behave in totally retarded ways that finally convinced me to just say 'screw it' and let them shoot through things, even though it's totally unrealistic.
Post Reply

Return to “Feature Requests”