ID:746716
 
Applies to:DM Language
Status: Open

Issue hasn't been assigned a status value.
This sort of goes with the "side-stepping" request, but it's a smaller and more precise one.

The request is to allow the walk() proc (maybe others also, but walk() is all I care about at the moment) to sort of change direction when moving diagonal. Basically, walk(src,NORTHEAST,slide=1) would move src northeast, but if it ran into an obstacle that stopped it from going northeast, it would either move north or east until it could start moving northeast again.
I don't know if this could be implemented natively. This kind of advanced logic sounds like it's better handled by the user. With walk() you should get a Bump() event when the diagonal no longer suffices, which you can then use to change the direction--even if just for one step.
SuperAntx implements this very simply in this library.
Was trying to avoid soft coding it. Thanks for the suggestions, though.
In response to Aaiko
Aaiko wrote:
Was trying to avoid soft coding it. Thanks for the suggestions, though.

Not to spark a huge discussion, but why were you trying to avoid soft coding it? I've seen lots of people have this opinion but you've got to soft code the rest of your game. If you can soft code the enemies, special attacks, and everything else, you can easily soft code this.
In response to Forum_account
Forum_account wrote:
Not to spark a huge discussion, but why were you trying to avoid soft coding it? I've seen lots of people have this opinion but you've got to soft code the rest of your game. If you can soft code the enemies, special attacks, and everything else, you can easily soft code this.

It's just a lot of processing. I made my own movement system to add in dual key movement and to reduce network lag with movement by simply using the walk proc to move the player in a certain direction until they let go of the key. On top of that, it's just a large game that already uses a ton of things that will have to be edited to make this work, and it's a lot more processing. I'd have to replace walk with steps and just do a ton of processing.

Nothing soft coded is going to be better than something built-in. When you're working on a single player game or a game that only maybe 4 people will play per server, you can go wild. But larger (and complex) games that you want to have at least 100 players on average, either you buy very expensive servers, or you make/want things as efficient as possible.

I'm perfectly fine (and capable of) implementing this on my own, and pretty much anything else I request (or work around it), but it's always better built-in and because I haven't seen the BYOND source, I have no idea how easy it would be for them to add it, so I make the request.

Aaiko wrote:
It's just a lot of processing. ... I'd have to replace walk with steps and just do a ton of processing.

It wouldn't take much processing at all. When a mob bumps something, check if they were moving on a diagonal and try to move them in one of the component directions. This isn't much work and it only happens when something bumps into a wall. There's so much else happening in a game that this feature might account for 0.1% of the game's CPU usage - even if you improve its performance as much as possible, it can't reduce the game's CPU usage by more than 0.1%.

Nothing soft coded is going to be better than something built-in.

That's not true. Built-in features often have to be implemented in a generic way but soft-coded features can be written to do exactly what you want. There's also no guarantee they're implemented efficiently. Setting the layer var to make objects lower on the screen appear closer achieves the same effect as the SIDE_MAP map format but is much more efficient.
I'm not really sure about the OP, but I will say the way movement behaves "out of the box" by default is quite weird. If I hold up arrow and then begin to hold right arrow, I expect my character to travel north east. Instead, byond cancels out north (oldest direction key down) and carries on with east.