Why does this happen??

Page: 1 2 3 4 5 6
May 17 2016, 9:23 am
Something you should be aware of: Colors don't save with overlays. You'll want to rebuild your overlays from scratch for anything you load from a savefile.

I found out last night that in fact no new appearance features from 500 onward are saved. That's something I'll probably change in 511.
May 17 2016, 10:19 pm
Thank you I'll keep this in mind.
May 19 2016, 10:31 pm
What is the proper way to exclude an object on the map from being affected by the color properties of a plane?
May 19 2016, 10:34 pm
If a plane master has a color, all objects on that plane will be affected by it, without exception.

The way a plane master works is that all objects on the plane are drawn, and then the master's properties are applied to the resulting composite as if it's a single icon.
May 19 2016, 10:45 pm
What if they're not on the same plane? Using the lighting example; how can I have some objects on the map appear over the plane master?
May 19 2016, 10:50 pm
Use a higher plane.
May 19 2016, 10:53 pm
In response to Ter13
Wonderful. Thank you very much!
Jun 27 2016, 9:31 am
Is there a way to use the right mouse button as a macro?
Jun 27 2016, 9:47 am
Not as a macro, no, but you can disable the right-click menu (either with a client setting or a skin setting) and then any right-clicks will be sent via normal mouse commands.

511 introduces MouseRightButton as a macro name, but it's for use as a mapping target from a gamepad button, not as a macroable thing itself.
Jul 1 2016, 10:50 am
This is kind of a broad question but what is the simplest and most proper way to incorporate diagonal movement?
Jul 1 2016, 12:35 pm
In response to Exentriks Gaming
Exentriks Gaming wrote:
This is kind of a broad question but what is the simplest and most proper way to incorporate diagonal movement?

I don't follow. Diagonal movement is already built into the engine.
Jul 1 2016, 12:39 pm
Having it work using a combination of two keys for example: pressing the up and left arrow keys would move diagonally towards the north west.
Jul 1 2016, 1:20 pm
Oh, that's fairly straightforward. Have key-down and key-up macros for each of the arrow keys. The verb they use should be instant. When the verb is called, mark down whether the key is up or down. Then in a loop that runs every tick, move the player based on which keys are down.
Aug 20 2016, 6:00 am
Is there a difference from when a verb is called through a macro as to when it is called from within another proc? I've run into a weird problem and I don't have the slightest idea what is going on... basically this is what's happening:

Code at work:
                while(attackStance && src.client)
                    src.dir = get_dir(src, src.client.mouseLocationObject)
                    src.underlays -= src.arrowPointer
                    arrowPointer.transform = turn(initial(arrowPointer.transform), client.mouse.GetAngle())
                    src.underlays += src.arrowPointer
                    sleep(world.tick_lag)


When you call the verb through a macro this is how it works:

Notice how even while moving the mob's direction always faces the mouse; this is the intended behavior.

When you call the verb through another proc:

Here the mob direction only faces the mouse when it is not moving...

What is happening here and how can I get the intended result?
Aug 20 2016, 6:16 am
In response to Exentriks Gaming
It seems to me like the timing is different.

For the case where you're always facing the mouse, this is the order of things:
1. Move, changing dir based on movement
2. Face the mouse
3. Render the screen (done by the engine)
4. Back to #1

For the other case, #1 and #2 are swapped:
1. Face the mouse
2. Face the movement direction
3. Render
4. Back to #1

The best way to guarantee an order is to put these things in the same loop. It's good to have one main loop, anyway.

A common game loop involves just one loop for all objects that need to update every tick:
var list/updaters

/updater/proc/Update()

proc/GameLoop()
    var item, updater/updater
    for()
        for(item in updaters)
            updater = item
            updater.Update()
        sleep world.tick_lag

You'd probably then add your players to the updaters list, and give them an Update() proc like this:
// (In your "player" type)

// This gets called once every tick
proc/Update()
    // Handle movement input
    MovementUpdate()

    // Handle attack stance stuff, i.e. face the mouse
    if(attackStance)
        AttackStanceUpdate()
Aug 20 2016, 6:27 am
In response to Kaiochao
Thank you very much, I already had a game loop and got it to work immediately. For future reference, do you have any idea what could be causing this shift in the order?
Aug 20 2016, 6:41 am
In response to Exentriks Gaming
When the loop is started by a proc, if that proc was started before movement was handled, then the mouse aiming loop will always happen before movement happens, and vice-versa. If you start the aiming loop at the end of the movement-handling code, it would probably always happen after movement is handled.

It could be that (non-instant) verbs called by the client aren't processed until everything else is, within the same tick. Hence movement is handled before those verbs.

Still, it's not really worth worrying about, since the main update loop pattern is more reliable and already gives you full control.
Aug 20 2016, 6:55 am
In response to Kaiochao
Really appreciate it.
Aug 21 2016, 9:40 am
Basically I'm trying to make a simple light effect and I had this working a while back but now I can't put my finger on what is causing this problem. Here's the code, most of it is pretty much what you'd get out of the DM reference:

obj
    crossHair
        lantern
            plane = 3
            blend_mode = BLEND_ADD
            mouse_opacity = FALSE
            icon = 'bigFireflyOrbs.dmi'
            pixel_x = 20
            pixel_y = 0
            //screen_loc = "14:6,12:5"
            New()
                ..()
                alpha = 100
                var/matrix/M = matrix()
                M.Scale(3)
                src.transform = M

obj
    planemasters
        night
            plane = 3
            screen_loc = "1,1"
            blend_mode = BLEND_MULTIPLY
            appearance_flags = PLANE_MASTER | NO_CLIENT_COLOR
            color = list(null,null,null,null,"#333f")
        //  color = list(1,0,0,0, 0,1,0,0, 0,0,1,0, 0,0,0,0, 0.2,0.8,0.8,0)
            mouse_opacity = 0

client
    proc
        InitializeNight()
            for(var/obj/planemasters/P in src.screen)src.screen -= P
            for(var/obj/crossHair/P in src.screen)src.screen -= P

            var/obj/planemasters/night/P = new
            var/obj/crossHair/lantern/B = new

            src.screen += P
            src.mob.overlays += B



This is what shows up:

Instead of it being a big glowing circle, something is causing it to show up like this.

I had this working a couple months back and this is how it looked:


Any help is much appreciated, I've tried messing with the alpha variables in the color matrix of the planemaster and several other things but nothing seems to work.
Aug 22 2016, 8:45 am
Bump.
Page: 1 2 3 4 5 6