So Vlevo explain my position about the distance. For sure we can get the distance to an object. But as portal are not an object, if you want the distance, you have to calculate it : Dist = squareroot (x²+y²) (is squareroot is available, it was in math lib in old levels).
Or you can create an objet with pos.x and pos.y information.
I was just making the remark that both possibilities are more adavance coding.
About the move feature, I heard about that in an other post (don’t know where). I just tryed and it was refused, I did not understand that we need another pair of boots. I’ll take a look. In order to be change our way of coding using these boots, it could be great to have the same feature with attack…
You don’t need the same feature for attack. If you code properly. you just move if > some distance from the enemy and attack if <= some other distance. There’s no need to make a separate attack feature.
hum, yes, if you know the range of all your attacks. I wonder for the attack that request some time if the time is taken before or after the attack. Do you have the risk the target was gone at the time you want to attack ?
I have a look to the items. I watch the boots with move. The text to explain move is the same than the one for moveXY (at least in french).
To my strange brain your explaination, sotonin, does sound like my “partial moveXY” mentioned above (and prolly poorly explained) or as I like to call my function “moveTowardsXY” only better, because there is no arbitrarily fixed move distance and no need to reissue the command every so often to keep going… (iow: I made my own “semi-blocking” move command, by moving an acceptable distance toward my target and then processing before reissuing the command to again move closer)
edit:
I just discovered this post about the new boots with some code examples, if his ideas/examples are right and one HAS to continually reissue the command then move really is alot like my moveTowardXY (except as I suggested above, I don’t have to do the partialXY computing.).
attack(object) prolly is “blocking” but really should be a function of ones boots, if boots non-blocking then the move portion of attack should be non-blocking. (ogres may be dumb enough to infinitely chase after something they can’t catch, but my well dressed hero shouldn’t have to be.)
Knowing if math functions were available would be good. Currently I am comparing the squared versions for distance to things I didn’t know I could objectify. (x²+y²) < distanceTo(enemy)²
Now I am having a new problem with this level. It has to do with the new “sliding”. my hero runs around grabbing coins, kills the head hunter, grabs some more coins, gets to this one coin, slides toward/into the wall and she just sticks there doing nothing until the big ogres bash the snot out of her and she dies (so I don’t know if it inf-looped or ?? because she dies before it complains)
Oh, and now that I think I understand what “move” does . . . . I think that it should be renamed “moveToward” since my understanding is that you will never get to your target.pos unless you either 1) reissue the command every “frame” or 2) are within one frame distance from it to begin with. Conceptually that is not “move” but “moveToward”… (a large conceptual difference between “move<Direction>”, “moveXY” (both concrete moves) and “move”)
Sorry, I didn’t notice that the previous post was also mine.
on that note I have another comment about the math functions. In another post someone suggested that it was silly to expect codecombat to tell us all the language functions we should just go learn it our selves elsewhere. 1) that may work for languages where nothing is in a separate - must be imported - library, but that won’t work for python . . . does codecombat python have all the standard python libraries? which libraries are those anyway? did code combat implement those as libraries? or did they fold them straight in? 2) lets not even get started on how silly it is for a “learning” site to tell you to go learn someplace else… and 3) nick mentioned having trouble trying to fit it on the helpful function area of the level screen, @nick could you put a “Language Functions” pop-up/link in the programmicon books?? say II+ since they are probably not needed/wanted (teaching-wise) prior to that.
I would name it moveToward except that you only have to learn it once (and we’ll have a few levels at beginning of mountain to teach it) and afterwards it would just be a pain to type the “toward” all the time.
We will expose the documentation for the standard libraries just as soon as we can figure out how to make the UI work. We have actually written most of the docs, but if we put them in the current interface, the docs area would explode, so we need a more flexible UI there before I’m willing to, say, slap the Math, String, Vector, Object, Array, and Function properties into the next Programmaticon, say.
I meant one listing in the Programmaticon: “Language Functions” that would popup a box of the functions instead of listing them all in the main help area.
hmm, I never thought of the typing long name thing, since I never type the whole name in . . . isn’t that why the little box pops up with variables and funtions to choose from.
Thanks to @Mr_Berg in another thread, I figured out what my “sliding” problem was…
It was actually a do-nothing condition, I only ran to the teleporter if the enemy was closer than the nearest coin but there was no “coin” to compare if the closest coin was further away than some set distance. (I implemented the solution from that thread and Yeah!!)
Problem code looks like:
if enemy and item and “enemy closer than item” then use teleporter
elseif item then get item
//else the coins aren’t getting any closer so stand there like a/an <insert expression of choice here>
One might get lucky and a coin spawn close enough before the ogres pound the snot out of you…(but don’t count on it.)
hero shouldn’t have to be.)