In Pulp, is there any way to get the event.x and event.y values when calling an event handler from the game? For example, if I have an npc sprite called "npc", and an event handler set up like so:
on foo do
say "{event.x} y {event.y}"
end
When this is called from the games "loop" event handler using "emit foo", this will correctly print off the x y coordinates of the npc. But when using "tell npc .....", this always seems to print "0 0".
Seems like the logic for emit and tell should work the same way, right?
I'd like to avoid having to use emit, since it's so resource intensive (according to the docs), is there any way to tell npcs (or any sprites) to do things which require their coordinates, without using emit?
see the thing is, when you use tell, it uses a "static" version of that tile as opposed to an "instance" of the tile. this is because when you say tell "tileA" there could be any number of tileA's in the room. if there are more than one, then which x and y would it use?
there's a lot more to it as well on why it would be weird to design tell to be able to do what you want, but mostly, you're going to need to pick how it would work and implement it yourself.
I wouldn't use emit in the loop or the draw, but if it's something that's happening conditionally or on a button press, it shouldn't be too slow. you can also just find the tile yourself.
also, it might be a lot of work, but you could just hard code its position as two variables. I wouldn't do too many like that (like keep it under a thousand) but that would be faster than finding the tile (which is what emit does)
I'd imagine each instance would use its own X and Y, much like how it works when an event is triggered via emit. I'm mostly just confused as to why emit and tell don't both work the same way, if tell has to use static versions of the tiles, why doesn't emit? What sort of event handlers would you want to generically send to a sprites static version, but not send to any actual instances of it?
I'm not complaining, I'm pretty happy with pulpscript so far and I'm content with the answer just being "that's just how it is", but if there's some deeper reasoning/performance reasons, I'd be interested in learning.
The reason I was tying things into the loop event handler was to make the npcs randomly walk around the room. Very open to other suggestions on how to accomplish that though.
The idea of keeping the position coded as two variables is good, thank you for that idea.
I'm curious to know how other people are handling objects in rooms that move on their own, npcs, bullets, etc. Open to any suggestions.
As Del notes, calling tell "<tilename>" will call the handler on the tile script itself. This can be useful in itself for separating out code for neatness (eg I often use a separate soundplayer tile to control sounds via different handlers), but not what you're after in this case.
emit is the equivalent of looping through all tiles on screen, and doing tell <tile_x>, <tile_y> on each one. You can do that yourself to make sure the handler has an event.x and event.y set, but only so long as you know where the tile is. You can track that via separate variables if you don't have too many, but need to keep it updated if your tile moves. For instance:
my_tile_x = 10
my_tile_y = 5
tell my_tile_x, my_tile_y to
call "move"
end
... in the my_tile script ...
on move do
... swap tile to another location...
my_tile_x = <new_tile_x>
my_tile_y = <new_tile_y>
end
Another way to do it is to tell a tile to cal itself after an interval:
on move do
... move tile, updating new_tile_x/y ...
tell new_tile_x, new_tile_y to
wait 1 then
call "move" // call same function on new instance of tile
end
end
end
(off the top of my head...)
The advantage here is that you don't need to keep track of several new_tile_x/y's, but on the other side it can get confusing if you have multiple events all going on at the same time.
well, that is what I was trying to explain; sorry it wasn’t clear. tell speaks to the “concept” of a tile while emit speaks to each individual tile on the screen (and a few other active items)