I am trying, by pressing one time down for example on my keyboard, my character to move one full tile down (32 pixels) the above, but the whole animation to be displayed pixel by pixel. If I use
mob And I press down once, the character will move one pixel down the above. If I use mob And press down again, then character will immediately appear one full tile down. What I am trying to do is a combination of these two... | |
|
Dec 26 2015, 12:30 pm
|
|
GreatPirateEra
 |
Do you have a movement state? If you want an idle state to appear when the mob isn't moving, you can leave it's icon state blank. For the movement state, leave the icon state name blank as well, but check the "movement" checkbox.
|
GreatPirateEra wrote:
Do you have a movement state? If you want an idle state to appear when the mob isn't moving, you can leave it's icon state blank. For the movement state, leave the icon state name blank as well, but check the "movement" checkbox. But it does have a movement state :/ What I mean is more of a smooth tile moving than just the default where it just appears on the next tile. | |
What you could do, is use an update loop which checks the state of a var every tick, and also increments that var if a direction is held down, and reset it to 0 if it isn't. If the number is very low, like <10, then step_size = 1 and call step(), but if the number is >10, then step_size = 32, and call step().
| |
This idea is nonsense. Either it's rigid tile movement, or pixel movement. Even a single atom off grid will cause your grid to fail.
Just set step size to 0 and use gliding. | |
Might be an rts-esque game where placement of your units is very important, and you use movement to place things. Gotta be accurate or fast.
| |
Even then, you can just leave a dense object behind the mob until the move is completed.
The problem isn't the type of game, it's that pixel movement is antithetical to grid collisions. This system introduces corner cases that cannot be fixed without emulating tile movement in softcode which not only would be slower than using the existing implementation, but would stack softcode on a more robust solution than the system you are emulating needs. I'm p sure i've thought this one through, and I can only see a single case where this would be useful: a game with a sidescroller mode and a tiled mode like Zelda II, or Tales of Destiny. Even then, it'd be unsafe to rely on pixel collision and substep visual incrementing. I.E. instantly move the object into position and animate -32px on the move axis, then animate again to 0 in the second step. | |
Ter13 wrote:
This idea is nonsense. Either it's rigid tile movement, or pixel movement. Even a single atom off grid will cause your grid to fail. Um sorry but how is it nonsense when you yourself made an attempt to implement what I am trying to do xD http://www.byond.com/forum/?post=1573076 I found your post some time after I posted mine. Maybe I didn't spoke it out correctly because my english is kinda bad. What I meant is a better tile-glide moving (press up/down/left/right once -> player moves a tile but with the whole animation) as you mention because the default is bad imo, it just appears the mob immediately to the next tile... | |
The link you've posted was an entirely different topic, and if you had adequate knowledge of DM, you'd have known that. Intermingling pixel movement and emulated grid movement is entirely doable without much performance loss. Ter13 listed caveats that are entirely avoidable.
I don't have the patience to step you through the process, so I'll merely say it's possible and you'll know how to do it yourself once you learn enough about BYOND. | |
Daybreakinz wrote:
Ter13 wrote: If you use gliding then it won't immediately appear on the next tile. It'll go smoothly. But you have to choose between glide or pixel movement in your game, if you use pixel movement anywhere then gliding is disabled globally for all movables. | |
...yeah, you have miscommunicated badly. That link to my post doesn't use pixel movement. It uses smooth tile gliding...
Totally different from how this post has been understood by everyone. EDIT: perhaps nonsense was a harsh phrasing, but no offense was intended. I've been on mobile a few days. Still driving back home after a christmas visit to wisconsin. Am in louisville atm, when i get off the beltway and get back home, i'll help clarify the misunderstanding that's going on here. If someone wants to explain the nuances of pixel/tile mode, though, you have 16 hours to beat me to it. | |
If you're looking for tile movement, that's one thing, but the way I read this is that you're looking for pixel movement with tile-size steps. The difference is that you want to be able to bump into a wall with bound variables, or something?
Bad. Don't do this.
for(var/a in 1 to step_size) | |
I'm still not sure which you want, really.
With tile movement and gliding, characters are only on one tile or another, but gliding makes them appear to move gradually. You'd set glide_size to determine the number of pixels to glide per tick. With pixel movement, the goal is not to constrain characters to the tile grid; it's expected that at any given time, they'll probably have some kind of pixel offset and may overlap a couple of tiles. This kind of movement is more freeform and fluid, but usually functions better at high FPS. Which of these is your goal? | |
Lummox JR wrote:
I'm still not sure which you want, really. The first, tile gliding. My character is 30x30 pixels. Maybe I used a poor explanation, but all I want is him to move from one tile to another, not with the default system that it just appears on it but to glide between. | |
I'm an hour away from home. What's going on here is OP does not have the context of which features kick the world into pixel movement mode necause he isn't aware of the historical separation of the two movement modes in our environment.
Will explain in depth in an hour of nobody gets to it first. | |
Alright, I'm late. Got home and realized the person that watched our cats while we were away fucked up and lost one of them. Reviewed the security footage on the apartment and found that she'd only showed up one of two days, so I spent my evening after 14 hours on the road walking around the neighborhood leaving treats around hoping she'll find her way back home, and then updating the company we got her chipped through with her status as lost. Super bummer.
Anyway, BYOND has two basic movement modes: Tile movement, where movables slide smoothly from tile to tile, and Pixel movement, where movables move a set number of pixels in a single-frame step. Pixel movement mode is not manually specified. DM automatically kicks the world into pixel mode if any of the following variables are set outside of specific ranges: * bound_x * bound_y * bound_width * bound_height * step_x * step_y * step_size If you want to use tile movement mode, no movable atom's bounding area can be smaller than a single tile, and must be an even multiple of the world tile size on all axes. Further, no movable atom can have step offsets. (Nudging in the map editor will kick the world in to pixel movement mode because nudges currently use step_x and step_y, and not pixel_x and pixel_y.) Lastly, step_size cannot be set to anything other than the default value on any movable atom. This is dependent on your tile_size world variable. Daybreakinz wrote: My character is 30x30 pixels. Maybe I used a poor explanation, but all I want is him to move from one tile to another, not with the default system that it just appears on it but to glide between. The default system DOES glide from tile to tile smoothly. This is tile movement. If it's jumping instantly from tile to tile, one of the variables I mentioned above is out of whack and you are in pixel movement mode. Daybreakinz wrote: Um sorry but how is it nonsense when you yourself made an attempt to implement what I am trying to do xD That code snippet that you linked to is actually using built-in tile movement, but it's been modified to create a smoother glide size by performing an exact calculation of how long the movement should animate the slide. This will often result in visually smoother movement than the default values provided you don't depend on client-side +REPEAT macros, and provided you perform your calculations correctly to ensure that subsequent movements don't interrupt sliding. So yes, basically, what you are trying to do doesn't really make sense, because you have accidentally caused another problem by having a 30x30 mob bounding area rather than 32x32, which would match the tile size. | |
Ter13 wrote:
Alright, I'm late. Got home and realized the person that watched our cats while we were away fucked up and lost one of them. Reviewed the security footage on the apartment and found that she'd only showed up one of two days, so I spent my evening after 14 hours on the road walking around the neighborhood leaving treats around hoping she'll find her way back home, and then updating the company we got her chipped through with her status as lost. Super bummer. Ouch. Sorry to hear that. I hope you find your cat soon. | |
Oh I see, posts get deleted so long as they don't conform to some superficial code of congeniality. Just what I'd expect from a half-assed programmer.
| |
Thanks for proving you have no concept of what indefensible means. My post is justifiable, but it doesn't conform to your own bigoted belief of what's acceptable; because it falls on the side of a spectrum you happen to find offensive. That's not how logic works, and likely why you're not a very good programmer. Sound arguments operate independent of emotion. I suggest you study the basics.
| |
