Where the beam ends

[Zizzo]

Beams can, of course, be targeted beyond their intended range, as we've all done to get Manathrust to hit the right monsters. The engine presumably knows where to end the beam in this case — but is it possible to find that out? Specifically, is it possible for a caller of ActorProject:project() to find out what the points of interest indicated below were for a given invocation?

points-of-interest.jpg (179.46 KiB) Viewed 3857 times

[My motivation is T2 archery; that point is where I want the arrow to fall to the floor if it doesn't hit a monster before then.]

[darkgod]

You can use actor:getTargetLimited(t) instead of actor:getTarget(t)

Which basically does a call to actor:getTarget(t) followed by a call to actor:canProject(x, y)

[Zizzo]

You can use actor:getTargetLimited(t) instead of actor:getTarget(t)

Which basically does a call to actor:getTarget(t) followed by a call to actor:canProject(x, y)

[sound F/X: source diving] Hmm, odd; the return values that :getTargetLimited() appears to be expecting from :canProject() don't seem to sync up with what :canProject() is actually returning. In particular, :getTargetLimited() is returning the third and fourth return values from :canProject(), which appear to be stop_y and stop_radius_x. Worse, the related function :getTargetLimitedWallStop() returns the fifth and sixth return values from :canProject() — which only returns five values…

At any rate, I gather the second and third return values from :canProject() [stop_x and stop_y] are what I want? I'll experiment some with this. Thanks.

[Nagyhal]

Oooh, nice. I didn't know about these. When did they come in?

Isn't there a massive amount of copy-pasted code within the ToME talent files that could be replaced by the functions getTargetLimited and getTargetLimitedWallStop?

[Nagyhal]

Zizzo, the code works as intended, and gathers only the second and third return values (or the fourth and the fifth in the case of getTargetLimitedWallStop.)

When you see this, you'll want to kick yourself... or well, you'll want to kick something, at any rate - I certainly felt like it!

Code: Select all

--- Calls :getTarget and :canProject to limit the results and returns the same as getTarget
function _M:getTargetLimited(t)
	local x, y = self:getTarget(t)
	local _ _, x, y = self:canProject(t, x, y)
	local target = game.level.map(x, y, Map.ACTOR)
	return x, y, target
end

--- Calls :getTarget and :canProject to limit the results and returns the same as getTarget
function _M:getTargetLimitedWallStop(t)
	local x, y = self:getTarget(t)
	local _ _, _, _, x, y = self:canProject(t, x, y)
	local target = game.level.map(x, y, Map.ACTOR)
	return x, y, target
end

For some reason, the first underscore is not followed by a comma - and so while it seems like the first two and the the first four return values are discarded, it is actually one less than that in both cases.

While some complex Lua code can use metatables to overload the underscore with strange new capabilities, in this case there seems to be absolutely no point to the extra underscore.

Why they were written in this confusing way I cannot guess! DarkGod, is there a stylistic reason for it?

They're nifty functions, either way - whatever the reason for this strange overabundance of underscores

[Effigy]

It's an inline declaration of the local "_" just before the call. This is legal since Lua doesn't require a semicolon after each statement, but it can definitely be confusing. So basically, this would be more clearly expressed as two lines, but I assume DG put it on one to save space.

It may not even be needed to declare the underscore as local since it's a junk variable, but it may be done for performance since access to locals is supposed to be faster than globals.