ID:1316027
 
Resolved
The map editor now has an option to nudge items using pixel offsets rather than step offsets, for games that don't use pixel movement.
Applies to:Dream Maker
Status: Resolved (511.1348)

This issue has been resolved.
In the Dream Maker map editor, I've found that using the "nudge" option can break games that do not use pixel movement. The step_x/y does unspeakable things to movement, for some reason. I'm not sure if this is a bug or not, but this can be easily adverted by changing the nudge command from using step_x/y to pixel_x/y.

I'm not sure if anyone's run across this issue in the past, but I have.
If you set step_x/y, then the game switches from tile-based movement to pixel movement (and since the default step_size is a full tile and gliding is disabled, it tends to look awful). However, for games with pixel movement, using step_x/y is preferable to pixel_x/y because it properly offsets the bounding boxes.

Maybe there should be an option in the menu for whether to use step_x/y or pixel_x/y for nudging?
In response to DarkCampainger
DarkCampainger wrote:
Maybe there should be an option in the menu for whether to use step_x/y or pixel_x/y for nudging?

+1 to this.

Another user (I think it was Tobba) mentioned recently that this was a problem in the editor as well. An option to disable pixel movement support in the map editor would probably be pretty helpful.
Yeah that was me, I'm fairly sure that one of those flag bits in the start of the DMB controls pixel movement enable/disable and is set if pixel movement vars are referenced in code
Perhaps just make it so the editor can get the value of that off the compiler and use pixel_x/y if it isnt set
This might be something of a necro, but this seems a fairly small change that would give a lot more convenience to mappers.
Title says it all.

We have designed systems that check all incoming code for this.

We have to deal with new map editors who don't know that using nudge in the map editor defines step_ variables rather than using pixel_x/y.

We have to deal with admins accidentally breaking gliding under view/edit variables by either making a typo in bound* or using step_ instead of something else absent mindedly.

And all I can think about, is how awkward of a system this is.

One, i don't like the idea of it being one way, that from that point on, gliding in the round is broken until next round, and there is nothing you can do about it. You can turn pixel movement on, but not off.

Two, Wouldn't a world var be better for this?

world
movement = MOVEMENT_AUTODETECT //(current legacy behavior, default)
movement = MOVEMENT_PIXEL
movement = MOVEMENT_TILE

In response to MrStonedOne
^

Dear god, This.

Just make MOVEMENT_TILE convert all step values into pixel offsets and assume the nearest bound values that would be valid on compilation.
In response to MrStonedOne
YES, PLEASE.

With this, mapping pixel offsets could be REALLY nice too, with the shift feature of DM.
In response to MrStonedOne
Jesus fucking christ, I'd love for this to be implemented.
LUMMOX, PLEASE ADD THIS
In response to MrStonedOne
I'm not sure if there's an easy way to set a global flag like this and have it impact the way the vars are loaded or saved. It's something I can look at.

One of the things I've been meaning to get to in the map editor is the introduction of a mode where the nudge commands impact pixels again instead of step.
In response to MrStonedOne
I mean, all you have to do is find a way to intercept the enabling of pixel movement, and prevent it if world.movement isn't set right.

then do your thing with the map editor
In response to Lummox JR
Why don't you just make it an option between pixels or step nudges? Drop down box from nudge > pixels or steps.
In response to AERProductions
AERProductions wrote:
Why don't you just make it an option between pixels or step nudges? Drop down box from nudge > pixels or steps.

That's what I was initially planning on.
In response to MrStonedOne
This could also be a #define generated in the .dme from an option in Build Preferences like DEBUG.
In response to MrStonedOne
If this becomes a compile time config can the byond vars relevant only to pixel movement be unincluded (or vice versa for those who want pixel movement on).

But if it shapes up in a different way nevermind.
This will be resolved in 511. I've added a new feature to nudge as pixels instead of steps, and it will save with the environment internals so it's per-project.

Saved for 511 because it involves pixel_w.
Lummox JR resolved issue with message:
The map editor now has an option to nudge items using pixel offsets rather than step offsets, for games that don't use pixel movement.