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.
ID:1316027
Jul 6 2013, 3:27 pm
|
|||||||
Resolved
| |||||||
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 |
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. |
Maybe there should be an option in the menu for whether to use step_x/y or pixel_x/y for nudging?