Request: able to target features.

[smoth]

First so I can kick the most likely and not acceptable responses.
# No, giving them to gaia player is not an option
# No making the feature alive is not an option.
# I do not want to see "lua" "lua it" or "use lua"

The reason:

Wreckage is a feature. Walls are features. Both of which need to be able to be targeted to clear them out the way. If there was some other option I wouldn't have posted here. When you have large blocks of dead things in the way your units cannot target them to finish off the wreckage. When a player builds 20 thick walls you cannot destroy them.

Only dumbfires can hit them by targeting something behind it.

That ignorefeatures weapon tag is not an option as I do not want to ignore feature I want to be able to give them attention. No I am doing any kind of lua switch out for a gaia target able feature, don't even suggest it.

the request is simple allow us to issue attack commands on a feature.

[Argh]

1. You need to turn avoidFeature to 0, that will cure the dumb-fire thing, and allow for manual attack commands. Ignore == no collision, Avoid == change target if assignment == X. Like... in P.U.R.E., I have avoidGaia=0, ignoreGaia=1, so that I can manually target Gaia.

Only problem is, that means stuff tries to fire through Gaia all the time. Haven't figured out a Lua way around that just yet, but probably can change an attack-this-unit order into attack-ground-under-it. Maybe I should fix that today, since I don't have time for anything more important atm.

2. For interactive targeting (i.e., to make it a non-manual thing, where if users simply right-click with an appropriate Unit, they open fire) you need to use Lua. Sorry in advance, but it's really the right way to do this, beyond just using avoidFeature=0.

You could intercept a Move order (i.e., if position to Move to == occupied by Wreck && Unit == Attacker), or you could interactively react to Tooltip, or do a scan with the mouse.

I already have a few contextual-command things in RC3, you might want to check them out.

[smoth]

you completely ignored the post argh. Thanks, made my evening.

[Argh]

Here's some code, wrote it in 20 minutes, may or may not completely work, but it's 90% of a working solution, the basic logic is sound.

All you have to add is storage of the appropriate group, to evaluate which UnitDefIDs are in destroyFeaturesGroup, and build a Gadget or Widget.

Code: Select all

MousePress(x, y, button)
	clickX, clickY = x,y
	clickResult = Spring.TraceScreenRay(x,y) -- Note: that can return the FeatureID as a second parameter, for more fun options :-)
	
	if button == 2 and clickResult == "feature" then
		possibleCheck = 1
	else
		possibleCheck = 0
	end
end

AllowCommand(unitID, unitDefID, unitTeam, cmdID, cmdParams, cmdOptions, cmdTag, synced)
	if cmdID = CMD.MOVE and possibleCheck == 1 and destroyFeaturesGroup[unitDefID] ~= nil then
		return CMD.ATTACK
	end

	if cmdID = CMD.ATTACK and possibleCheck == 1 and destroyFeaturesGroup[unitDefID] ~= nil then
		groundY = Spring.GetGroundHeight(clickX,clickZ)
		Spring.GiveOrderToUnit(unitID, CMD.ATTACK,{clickX,groundY,clickZ}, 0)
		return true
	end
return true
end

I don't guarantee it works, I don't have time to put it into P.U.R.E. or Merc Squad and test it right now, but I'll probably be adding a working version (whether this is it or not) to P.U.R.E. soonish, as that would cure some of the stupid-behavior issues that still remain, in terms of city fighting. When I get that done, I will release it PD, like some of the other Useful Things.

At any rate, in no way did I "ignore your post". I just ignored the part about "do not tell me to use Lua", because that's silly. Anything that's exposed in the engine that Lua can get its digital paws on... use Lua. Even if it's just a fricking prototype, it's going to save the C++ guys a lot of time, and we're less like leeches, and more like... partners. Which is a good and useful relationship, if not entirely a two-way street atm.

[lurker]

Argh, you're missing the entire point of the post, which is to target features without turning off avoid and shooting trees. Your little script to automate making clicks into attacks is nice, but it's easy to hit the attack button, and you haven't done anything about smoth's feature request.

That ignorefeatures weapon tag is not an option

Smoth was saying not to make something up about lua because the important part, being able to shoot walls but not smashing into trees, needs engine changes. He wasn't being anti-lua. And that's why he said you ignored his post.

[Argh]

Wreckage is a feature. Walls are features. Both of which need to be able to be targeted to clear them out the way.Sounds like what I wrote fulfills that request, tbh.

Avoid is either on, or off... there is no magical in-between here, unless you have a magical way to determine when it's OK, and when it's not.

What I got, from his original post is that he wants to attack guys hiding in the middle of Features, where the raytest from the mouse gets a FeatureID back, instead of a UnitID, and the Attack order gets canceled. Well, this would fix that. If he wants Units to make that decision on their own... well... it would involve a very complex check of the ray-test, and I don't even know if the ray-test just stops at the first collision it detects or not.... and even then, the final attempts to resolve that would probably not be efficient or useful, because it's so situational. I mean... 20 walls, or 10? Big or small? Gets awfully situational in a real hurry.

Or do you just want to provide a manual-fire order, and have it work? Which is it?

If you want manual-fire of all weapon types to work, on stuff behind Features, but you don't want ignore or avoid on... fine, use this code. Otherwise, maybe a better explanation of the logic you'd like to see might be in order here? Because I don't see where the hell this is going that's practical on the engine side.

[lurker]

It's not about being able to click and having it targetted when you didn't hit the A button. It's about being able to target features that are otherwise avoided. Alternately, setting avoidance per feature would probably work.

The issue here is walls that must be shot to get past. They don't have a lot of hp but if you can't shoot them you can't get past them.

It's not magical to say that when you explicitly target something that you want it shot.

[smoth]

wreckage also can block things, if I want to be able to blow that pile of scrap up it would be good. I am sure other projects could benefit from that as well.

[Argh]

It's about being able to target features that are otherwise avoided.

Well... I re-directed targetting to the ground beneath, it's no longer going to register as a target command on that FeatureID. If you have avoid on, that should work, unless targetting a map-position doesn't ignore the ray-test, which it should by default (if that's not the case, then ok, that needs to be fixed, and that truly is engine-side).

But you'd still need the Lua side, for issuing the appropriate command, and not letting it get borked because the test from the mouse reports a Feature, not ground, because it's raytesting and intersecting that hitsphere / box / etc., even if the raytest for the weapon is turned off.

[lurker]

It's about being able to target features that are otherwise avoided.

Well... I re-directed targetting to the ground beneath, it's no longer going to register as a target command on that FeatureID. If you have avoid on, that should work, unless targetting a map-position doesn't ignore the ray-test, which it should by default (if that's not the case, then ok, that needs to be fixed, and that truly is engine-side).

It doesn't; it would be a nice solution if features within a certain distance of a ground target were ignored, wouldn't it?

But you'd still need the Lua side, for issuing the appropriate command, and not letting it get borked because the test from the mouse reports a Feature, not ground, because it's raytesting and intersecting that hitsphere / box / etc., even if the raytest for the weapon is turned off.

Nah, it already targets the ground underneath.

[Argh]

it would be a nice solution if features within a certain distance of a ground target were ignored, wouldn't it?

No... that would lead to borked results, tbh.

For example... you're having a fight around a really big building... the centroid is far away... you're basically going to raytest, it'll pull that FeatureID... it'll be far away, the avoid will halt the attack, both your guys just stand there.

Or you're having a fight with small, but tall stuff, and your guys self-immolate because they're ignoring it and self-damage each other (if you haven't already fixed that with Lua, like I have).

Or you're firing at some guy far away in the middle of a field of wrecks, you can't fire because the objects are all too far away. Which is the worst of the cases, and probably the most common IRL.

Seriously... I'd just turn the raytest off, on a target that's Ground, it'll be a better way and far faster code.

The other part of the problem, also... is that it should be possible for stuff to block LOS... that would lead to far smarter behaviors for anything involving buildings. Wreckage is the simpler case.

[lurker]

You can look at how far they are from you to fix the issue with large, things, and I have no idea what you mean about small, tall features; units wouldn't get approval to shoot past them. But turning off testing when attacking ground strikes me as the worst way to do it, as units attacking a large distance away kill themselves on nearby trees.

[Argh]

Meh, then put another check in, on the Lua side, for nearby crap- if targetting far, then check for nearby stuff. Not a biggie. Meh, do whatever you want, of course, I think that turning the raytest off is a lot more flexible, because then we're controlling the rest of it with Lua, like we should be, instead of dealing with yet-another set of assumptions that may not apply well across games.

[lurker]

Put the avoidance check in lua? For every unit?
I don't think avoiding features only until half range or so is assuming much about the game.

[Argh]

I don't think avoiding features only until half range or so is assuming much about the game.

Yeah, that'll probably work all right, and it'll be a lot less clunky than the current behavior for sure.

You'll still need the Lua though, because that raytest doesn't occur until well after the Order is done, and the Order doesn't know jack or squat about the interrelationship of all of these elements.

[KDR_11k]

Another thing Smoth mentioned was having the drag attack target the walls too so you could easily order your units to make a breach instead of having to manually target the different segments until they're destroyed.

[smoth]

a simple request thread has once again been mucked up.

[lurker]

No it hasn't? Argh just didn't realize how invasive the avoid tag is.

[smoth]

oh well that is good, I don't know I am tired and grumpy.

[Argh]

No it hasn't? Argh just didn't realize how invasive the avoid tag is.

Meh, I turned avoid off on every category awhile ago, I got tired of dealing with the stupid results. Until avoid / ignore was even available, World Builder was a mess- Kloot stuck in the current functionality, and I knew it wasn't perfect, but it was good enough for the immediate purposes.

Didn't know manual-fire orders on ground were still getting raytested, though. Thankfully that's probably a fairly easy fix- just find the length of the line segment, do what Lurker's suggesting as a fix, voila, most of the problem is gone.