No you can’t. it’s 3 seconds. So you would have to stand there doing nothing for 3 seconds to get teleported back.
Cool, 'cause that is how I have my routine coded (no escape for 3 secs)
Hmm… that is interesting and it makes more sense now what might be happening to me… thanks for that info.
I still don’t know exactly what is happening, just that my code works differently now than it did 12 to 24 hours ago. The timing is off now, such that the loop doesn’t work the same.
Also, something is different about movement. This may sound crazy (and no drugs are alcohol are involved, I promise) but when my hero moves to a target, he often seems to skid or slide past the target instead of stopping exactly on the target like he did previously (I think).
Like I said, it’s a cool level, but can be hard to figure out what is going on at times due to the teleporting.
In thinking about this some more, I don’t think it matters given the 3 second delay, which I did not realize was there. All I was saying is that when you re-appear after a teleport, it’s at a location that is also a teleport entry. It could be anywhere on the screen, it doesn’t have to be to another teleport location. Unless there is some law of physics regarding teleportation that I am unaware of. 
A teleport location could be an item in this sense:
teleport = self.findNearest( self.findTeleport() )
self.moveXY( teleport.pos.x, teleport.pos.y )
I am just throwing this out there as a concept, I don’t know the coding specifics of how the teleporting happens, or what is feasible to code.
I don’t know the feasibility of objectification of teleporters, but while we wait for the real answer I wrote my code something like this (pulling code and x,y # out of thin air to show the idea)
let’s say there were two porters
porterloc = [(5,5),(100,100)]
def usePorter(num)
px,py = porterloc[num]
self.moveXY(px,py)
loop:
#blahblahblah
useporter(1)
would move you to 100,100 and if the porter was ready for use BAMPF!
It perfectly feasible but very confusing and not something we’re gonna do. And it’s not going to solve anything (im not actually sure there’s a problem to be solved)… we’d have to respawn the potion or whatever is the teleporter in 3 seconds anyways so it’s re-usable. so it would in the end be the exact same situation.
it sounds like you just want an easier way to get teleports. But i don’t think something used on one level warrants a whole new component or systems behind it. Perhaps if we start using them a lot we could build a whole component around it that registers them. But i’m not exactly sure how players would get the skill. Typically we don’t make skills and put them on items if they are only going to be beneficial on a single or even a handful of select levels.
It’s only 4 telelports. just make an array of objects that have the x / y coords then loop over it and check distance to those coords to decide which one to move to
Maybe you’re talking only for advance players, because at this step of the game, creating object and calculate distance by hand was not learned in previous level.
About the use of portal, @sotonin, is what I observed a correct behavior:
I try to catch an item close to a portal, so I use movexy to this item. Just before reaching the item position, the hero enter the portal and appear at the other end of the level, and she continues to target the same position, as she did not reach it. I lost control.
That make me thing that it could be great to have an additionnal and optional parameter to attacks and movexy : the distance we want to move before exiting the function and get back control on the hero. Same for attack because in one level, I also lost control of my hero because she try to attack an enemy that was always moving. And she can’t reach him : No more control. Ex:
this.movexy(pos.x,pos.y,3); // move 3 meters in the direction of the target
this.attack(enemy,5); // Try to attack the enemy, but stop after 5m if this can't reach it
@nick, is it something feasible ? In the initial levels (in the old ages), the commands were not blocking like it is now, so it was possible to change direction taking into account the real time of the level.
@eiler13, I must stick to warrior right now, because I don’t have any equipment for the ranger or magician yet. The advantage of the ring is that you could use it for everyone (with hanzo also, if I have enough gems one day).
1 Like
Calculating distance is not something learned by desert? Thats something learned very early on. Most people will use flags for this level anyways though.
this.distanceTo(someobject with x and y);
I adjusted the level so the coins shouldn’t spawn too close to the teleporters anymore. this should help with that.
Yeah, that’s what I’m doing actually, though I think I’ll adopt/steal Vlevo’s approach and do it in a function.
My point is not really about what’s possible to code but whether we have to code specific xy coordinates as opposed to more conceptual code that says move towards “nearest portal”. The former is a lot more verbose and my point is not really about the people discussing things in this forum but the kids who are using this site to learn. But maybe these repeatable levels are more about advanced users anyway.
Anyway, just meant to share some thoughts and ideas. No criticism intended, and no expectation that my advice is useful.
Yeah. I understand. Most people will probably use flags anyways. Unfortunately as i described previously, it would be hard to justify making a whole new set of components for teleports to make them easily accessible when it’s only useful for one level or even a handful of them.
LOL, I forgot about flags. I basically don’t use flags on repeatable levels since you can’t test them with the run, only the submit. Also, seems sort of like taking the lazy way out. Anyway, thanks for explaining.
Agreed. im the same way. Hate flags 
I believe Vettax was refering to calculating distance to points on the map and not to objects since you keep shooting down the obectification of the teleporters. (not saying you’re wrong, just pointing out you say use an object at the same time you’re saying , no way the teleporter will be given to us as an object.)
So, which level teaches how to “create object with x and y”?
(Sarven Treasure is a free level, the teaching level should also be.)
Last night, I finally fixed the bug that was causing a dropped frame of idleness in between every hero action, plus the auto-braking in between every action, that was making move basically useless and also making moveXY much less fluid. So if you noticed any timing or balance changes on any levels starting last night, that’s probably why. This also makes you slide a bit if you transition into an action that doesn’t including any braking, like say or cast.
Keep your eye out for any levels that don’t work quite right any more. The heroes are more responsive, move works, even the gaps between attacks are less, but this can change a lot of little balance issues.
This change might have affected the code we were using in Sarven Treasure to cancel the in-progress movements during a teleportation. Will check it out. By the way, the move boots are awesome now for this sort of thing (since they allow you to change your targetPos every frame), so try them out.
We’ll be teaching the object literal syntax, like {"x": 34, "y": 30}, in the first few levels in Cloudrip Mountain.
I am also having a new problem (started last night) with a “infinite loop” that shouldn’t be infinite but I’ll open a new topic for that.
by “object literal syntax, like {“x”: 34, “y”: 30}” do you mean that we can/could:
if self.distanceTo({“x”: varx, “y”: vary}) < somedistance:
I’m not sure I understand how the “move” command will work… is it basically the same as computing a partial distance and "moveXY"ing to it then if I still want to go to the original destination I compute the next partial and moveXY to it, except that the move-partial stuff is handled for me???
Yes. thats exactly correct about the objects. The move command is identical to movexy except you pass an object just like that in instead of individual x and y variables. It will not lock so you can be more responsive. (ie your script runs more cycles instead of waiting til you get there before allowing you to do any more actions)
I couldn’t get move boots working correctly on sarven treasure. it still seems to get stuttery. however they worked for treasure grove.
Also. i’m not “shooting down” the request for an object specifically for teleporters, I think it would be neat too, but I don’t think anybody will devote resources to building it for just one level. or even a few levels. It’s too specific. I’ve wanted to add specific things for levels but was informed that it would just confuse people.
2 Likes
Man I am glad to hear that. I thought maybe I was crazy for thinking my hero was skidding around like on skates. Also makes me wonder if in some cases I was skidding into the portal accidentally because I was coding to move near the portal, and then wait for enemies to get closer before going into the portal.
Just tried out the leap boots and move but didn’t have much luck with it – kind of slow and stuttery, but maybe I didn’t do it correctly. I’ll just wait until we get some instructions on that or see how other people use them…
No you are right. for some reason on that level it doesn’t work right. It works great on multiplayer treasure grove though. I have no idea what could be different about that level though, very strange
Cool (distanceTo thing)
So,
move
attack
would be the same as
moveXY
attack
since the attack waits until the move is done either way.
but
move
<insert bunches of code>
attack(enemy)
is much better than the same with moveXY since it doesn’t wait for the move to finish before processing some more code.
If that is correct then do multiple move commands stack allowing processing to continue until they are either done or you hit a blocking action?
(Sorry for being so slow on the uptake.)
Awesome! thanks. If so then I really may have to break down and buy a pair.
Too bad there weren’t “item test” levels (fitting room, whatever one wishes to call it), where npc-x lets you borrow his boots (or what not) so we could get a taste of what we were missing by not buying item X-Y-Z. 
Not quite. .attack moves to the enemy (probably using moveXY behind the scenes.) so that wouldn’t work it would still lock but on the attack instead.
You would set your script up so if at any time certain conditions are met: do this.
if enemy and distance <= 5 or whatever
attack
else
move({x: blah, y: blah});
but then you could add more conditions in there like if item go after the item etc. it will continually loop over all the conditions (even while moving) what the end result is… you could be in the middle of moving towards an item or enemy and suddenly change your mind because of some other condition that happens. (moving towards item but change mind because enemy is close now). So basically one long set of conditions that if matched do something. The difference being, with moveXY the script basically halts until you get to the coords. this doesnt happen with move it continues to cycle over and over through the loop while moving.