pixel_w doesn't affect map editor placement

ID:2240851
 
Apr 26 2017, 2:33 am
BYOND Version:511
Operating System:Windows 7 Ultimate 64-bit
Web Browser:Chrome 57.0.2987.133
Applies to:Dream Maker
Status: Open
Issue hasn't been assigned a status value.
pixel_w is the only pixel_* variable to not be represented in the map editor currently. Minor oversight in the 511 series.
Apr 26 2017, 8:10 am
I looked through all the map editor code that uses pixel_w or pixel_z, and the only discrepancy I found was in a backend routine that looks up the pixel offsets. That routine was missing some logic for pixel_w that it has for pixel_z, which may have been interfering with a lookup in some cases. The odd thing is, this should only have come up in cases where the other pixel offsets were all set. In any other case, I believe the var lookup should have been normal.

This is the old defective logic:

u1c GetMapPopPixelOffsets(DMPopId4 id, s2c *px, s2c *py, s2c *pw, s2c *pz) {
    ProtoObj *pobj = GetMapPopProtoObj(id);
    Value val;
    *px = *py = *pw = *pz = 0;
    u1c has_px=0, has_py=0, has_pz=0, has_pw;
    if(GetMapPopHardVar(id,pixel_x_STR,&val)) {*px = FloatTos2c(Value2Num(val)); has_px = 1;}
    if(GetMapPopHardVar(id,pixel_y_STR,&val)) {*py = FloatTos2c(Value2Num(val)); has_py = 1;}
    if(GetMapPopHardVar(id,pixel_z_STR,&val)) {*pz = FloatTos2c(Value2Num(val)); has_pz = 1;}
    if(GetMapPopHardVar(id,pixel_w_STR,&val)) {*pw = FloatTos2c(Value2Num(val)); has_pw = 1;}
    /*
        If the offsets were not explicitly set by the mappop, look in the
        base type to see if it has any.
     */
    if(pobj && (!has_px || !has_py || !has_pz)) {
        ...
    }
    return 1;
}

You can see the flaw there, a big mistake on my part: has_pw is not initialized, and then it's not actually used in the same check as the others. In the part I omitted, the pixel_w read should be fine. So as far as I can tell from the code, the only way for this issue to trigger is if you set pixel_x/y/z in the map pop itself but for pixel_w to be set in the type. I've fixed that broken logic for the next release (minor build 1382).

If you're seeing pixel_w not work in other circumstances, any further info you can give me on that (or a test project) would be a help.