ToME: the Tales of Maj'Eyal

Everything about ToME
It is currently Sun Apr 22, 2018 2:22 pm

All times are UTC




Post new topic Reply to topic  [ 6 posts ] 
Author Message
 Post subject: Where the beam ends
PostPosted: Tue Mar 15, 2016 3:19 am 
Offline
Sher'Tul

Joined: Thu Jan 23, 2003 8:13 pm
Posts: 1476
Location: A shallow water area south of Bree
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?

Attachment:
points-of-interest.jpg
points-of-interest.jpg [ 179.46 KiB | Viewed 1314 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.]

_________________
"Blessed are the yeeks, for they shall inherit Arda..."


Top
 Profile  
 
 Post subject: Re: Where the beam ends
PostPosted: Tue Mar 15, 2016 8:44 am 
Online
Master of Eyal

Joined: Wed Jul 24, 2002 9:26 pm
Posts: 10181
Location: Angolwen
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)

_________________
[tome] joylove: You can't just release an expansion like one would release a Kraken XD
--
[tome] phantomfrettchen: your ability not to tease anyone is simply stunning ;)


Top
 Profile  
 
 Post subject: Re: Where the beam ends
PostPosted: Wed Mar 16, 2016 1:09 am 
Offline
Sher'Tul

Joined: Thu Jan 23, 2003 8:13 pm
Posts: 1476
Location: A shallow water area south of Bree
darkgod wrote:
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.

_________________
"Blessed are the yeeks, for they shall inherit Arda..."


Top
 Profile  
 
 Post subject: Re: Where the beam ends
PostPosted: Sat Jul 23, 2016 2:21 am 
Offline
Wyrmic

Joined: Tue Feb 15, 2011 12:01 am
Posts: 282
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? :mrgreen:


Top
 Profile  
 
 Post subject: Re: Where the beam ends
PostPosted: Fri Aug 19, 2016 12:03 am 
Offline
Wyrmic

Joined: Tue Feb 15, 2011 12:01 am
Posts: 282
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:
--- 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 :wink:


Top
 Profile  
 
 Post subject: Re: Where the beam ends
PostPosted: Fri Sep 30, 2016 2:15 pm 
Offline
Uruivellas

Joined: Fri Oct 10, 2014 4:00 pm
Posts: 824
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.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 6 posts ] 

All times are UTC


Who is online

Users browsing this forum: No registered users and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group