Macros in Pixel Movement

ID:1516967
 
Mar 13 2014, 3:27 am
(See the best response by Ter13.)
I've got a small problem. When using the pixel movement library, I've noticed that it seems to make my interface macros somewhat redundant. Is there any way that I can get them to work?

(I know that it no doubt has something to do with the keyboard library too)

Mar 14 2014, 6:35 am
I don't quite feel like I have enough information to go off of. What exactly isn't working for you? Any related code that you may have narrowed it down to?
Mar 14 2014, 6:37 am
Simply put, after ticking the pixel movement library (and so enabling it to work in my project), the macros that used to work prior to the library being enabled no longer work. Though I can use the verb ingame by clicking the actual verb (rather than the set key/macro).
Mar 14 2014, 7:47 am
What pixel movement library are you using?

You know that BYOND has native pixel movement now, right? There's really not a need for a pixel movement library anymore. Just neat little helper functions.

Check out: http://www.byond.com/developer/Ter13/EdgeSlideDemo for an example of how I manage my pixel movement system.
Mar 14 2014, 8:11 am
I was using FA's pixel movement library (sorry for my lack of clarification). However, that movement system you posted seems pretty good. Is it worth me switching to it?
Mar 14 2014, 8:12 am
FA's pixel movement library is very outdated, and is software mode. Mine expands on the native pixel movement implementation, hence, mine will be significantly faster, and most likely better in almost every way.
Mar 14 2014, 8:13 am
Right. So I'll be using your one then. (I'm usually rather reluctant to use FA's libraries, though I was pretty desperate for a non-tile based movement feature.)

Thanks, Ter.
Mar 14 2014, 8:20 am
The funny thing about that? The demo I linked you isn't a pixel movement library. It uses BYOND's built-in pixel movement, but I've modified it slightly so that your mob doesn't get caught on the tiniest little edges every time you bump into something.

All it does is define behavior for mobs that allows them to slide around obstacles rather than bump into them.

Plus, if you take a look at how I set up my macros, you will get a good example of low-impact move macros.

The only downside to that demo is that if your client is suffering from a lot of lag, the movement will feel a little unresponsive. That's because I'm actually only detecting keypresses and keyreleases on the server, and the client isn't sending a repeating signal to the server over and over again.

The upside of this approach, is that it's a lot less stressful to the server. The downside, is that it has a built-in delay when not playing over the local network. Although, it really shouldn't be all that bad provided you have first-world internet speeds.
Mar 14 2014, 8:28 am
Mm. Thing is, I wasn't so sure about BYOND's built in pixel movement. Like I'd heard of it, though I never went in depth to actually check it out (guess this is my punishment for not using my initiative).
Mar 14 2014, 8:34 am
Best response
Most people aren't, which was part of the reason I made that demo. To prove to people that the built-in pixel movement was viable.

My advice would be to not trust much of anything around these forums without looking into it yourself.

Looking at the answers that have been left in Developer Help over the last 30 or so days since I decided to stop being so active on the forums, at least 50% of the "best" answers are in some way wrong, or inaccurate. There are a small handful of people who give out real, solid advice here, Stephen, KaioChao, Lige, and LordAndrew are pretty much the ones I'd stick by. You can lump me into that if you want, or remain skeptical. Your choice there.

While I might have given up on actually trying to prove to the forum community that most of what they say is inaccurate, I'm still willing to provide evidence that they are wrong in my demos and libraries.

If you run into any trouble with the EdgeSliding approach, let me know, I'd be happy to help, provided it's a well-phrased, well-demonstrated problem, and not just a "how would I..." question.
Mar 14 2014, 8:36 am
Well said. Thank you for your help, Ter. I'll give you a shout if I need you.
Mar 14 2014, 5:32 pm
Forum_account's Pixel Movement (and Sidescroller) libraries do use native pixel movement, by the way. However, the problem isn't with the Pixel Movement library.

The actual issue here is with the Keyboard library, which (by default) binds every key on the keyboard at runtime, overwriting any macros you add to the interface (.dmf) file.

A few ways to go about this:

A) You can specify which keys to give to the Keyboard library by setting client.keys. The Keyboard library will only overwrite the keys listed in client.keys, which includes every key by default. The rest will be left as they are defined in the skin.
client
    set_macros()
        keys = list()

        //  These are the keys that the Pixel Movement library use. 
        keys.Add(
            Controls.up, 
            Controls.down, 
            Controls.left, 
            Controls.right)
        ..()


B) You can use the Keyboard library as it was meant to be used; as an interface for the skin macros.
client
    // This is the object whose key events are called. 
    // It's set to the client (src) in client.New(). 
    // The Pixel Movement library sets it to mob, though. 
    datum/focus = src

    // This is a list of keys (by name). 
    // keys[some_key] will give you 1 (some_key is pressed) or 0 (not pressed). 
    keys[]

// These are the key events. They do nothing by default. 
// (since /client isn't a /datum, they had to be defined separately)
    key_down(k, client/c)
    key_up(k, client/c)
    key_repeat(k, client/c)

datum
    key_down(k, client/c)
    key_up(k, client/c)
    key_repeat(k, client/c)


C) Don't use the Pixel Movement library.

I'll say that all games can benefit from including a Keyboard-like library, since dealing with the skin macros is just tedious.
Mar 15 2014, 7:09 am
In response to Ter13
I suppose the rest of us that don't meet your standards should just stop posting on this forum.
Mar 15 2014, 7:50 am
In response to Koshigia
Koshigia wrote:
I suppose the rest of us that don't meet your standards should just stop posting on this forum.

You know, looking back. Yeah, you are right. That was an unfair observation to tie into that commentary. Sorry.

In retrospect, I shouldn't demean well-meaning people, who actually want to help, and that was definitely the wrong way to go about saying what I did.

I think, the important thing to note, though, is that on the subject of the viability of pixel movement, and BYOND in general, not to listen to the naysayers who claim that BYOND isn't capable of having smooth pixel movement with more than 1 or 2 players in a real gameplay situation.

Again, you are right, and I shouldn't be lumping the well-meaning folk into the "don't listen to" category the same as the naysayers who like to claim that X is impossible to do in BYOND because Y unfounded reason.
Mar 15 2014, 8:09 am
In response to Ter13
Thank you for the clarification and the apology. No hard feelings then I hope.
Mar 15 2014, 8:54 am
In response to Ter13
Does the normal get_dist work with your Edge Slide demo? I know FAs had to make its own. If it does work is it in pixels or still called by tile distance?
Mar 15 2014, 8:56 am
get_dist is specifically for tile distance. All edge_sliding does, is make things slide around obstacles.

I didn't create my own, because BYOND, by default has bound_dist.
Mar 15 2014, 8:58 am
In response to Ter13
Awesome thank you!
Mar 15 2014, 1:05 pm
I also wanted to say thanks.

I just got into native pixel movement two weeks ago, and I ended up switching back to tile movement due to the getting caught on every edge thing. The Edge Slide demo got rid of the quirks though.

Nice work.
Mar 16 2014, 2:43 am
In response to Kaiochao
Thank you for this. I'll try each of these as well as what Ter suggested so I can see which works best for me.