ID:1380344
 
Not a bug
BYOND Version:499
Operating System:Windows Vista Home Basic
Web Browser:Firefox 23.0
Applies to:Dream Maker
Status: Not a bug

This is not a bug. It may be an incorrect use of syntax or a limitation in the software. For further discussion on the matter, please consult the BYOND forums.
Descriptive Problem Summary:
This is kind of like the last problem that was found with bound_width and bound_height to where the screen will move before you do and create the choppy effect as if the world was in pixel movement mode even though the bound is moving in multiples of 32. This is also happening with the 500 version even though the bound_width and bound_height works fine.

Link to last post.
http://www.byond.com/forum/?post=1367910

Numbered Steps to Reproduce Problem:
Change bound_x or bound_y to 32

Code Snippet (if applicable) to Reproduce Problem:
usr.bound_x = 32
usr.bound_y = 32


Expected Results:

Actual Results:

Does the problem occur:
Every time? Or how often? : Happens everytime.
In other games?
In other user accounts? :Yes
On other computers?: Yes

When does the problem NOT occur? :Happens all the time

Did the problem NOT occur in any earlier versions? If so, what was the last version that worked? (Visit http://www.byond.com/download/build to download old versions for testing.)

Workarounds:
Unknown
I'm almost tempted to say this isn't a bug, as when you mess with bound_x/y the server has good reason to assume you want pixel movement mode. With bound_width/height, you may merely be defining a big icon spanning multiple tiles. Is there any particular reason you'd need to alter bound_x/y but still use glide movement?
Well the only reason I was using it was the cut down the work on equipping items like weapons. For example using a blade that you need outside of the player icon. So was thing to make it like this. O is the person S is sword and x is just space.
xxx
xox
sox

So Each "space" would be 32 pixels and the usr bound_height would be 64 and the bound_x would be 32 to center the player in the center an able to create overlays that can be made around them without having to add anymore lines to the program. I know there are ways to add overlays off to the side.

/obj/Weapon/sword

icon = 'sword.dmi
New()

pixel_x = -32
//Then later on just putting
src.overlays += new/obj/Weapon/sword


But in the equip system I'm using I just haven't figure out how to put that in so i tried it by changing the bound_x and turning all icons to 96 pixels and centering the player and just add on top. Kind of the lazy to do it but I thought it would work. But if it's not a bug then back to the drawing board. Thanks
You don't have to change bounds at all to do any of that. You also don't need to change the pixel_x at initialization.

When you use pixel_x, it offsets the graphical appearance of the player or overlay.

Moving bound_x and bound_y is unnecessary because you are already moving the graphic down and to the left, thus, the bottom-left corner of the icon will be -32,-32, meaning 1,1 will visually be 32 pixels from the edge of the graphic on either axis. If your bounds are at 1,1, they will cover the center of the 96x96 graphical area.

/obj/weapon/sword
icon = 'sword.dmi'
pixel_x = -32
pixel_y = -32
Yeah I understand that but the thing is that even if I add that I have a var with in the object which holds the icon and the color of the object and I load image using the var not obj because that was the only way I could seem to fix the saving and un-equip error I kept running into. For example.

                     obj/Weapons
Shadow_Blade
icon='Weapons.dmi'
I='Weapons.dmi'
icon_state = "show"
Element = "Dark"
Strength = 200
Speed = 200
Defense = 200
SlashAttack = 400
Weight = 4
walk_delay = 0
I = 'Weapons.dmi'
//how all weapons and clothes are


usr.Strength+=Strength
usr.Defense+=Defense
usr.Speed+=Speed
usr.SlashAttack += SlashAttack
usr.SlashType += SlashType
usr.EquipDefend += EquipDefend
usr.walk_delay+=walk_delay
suffix="Equipped"
usr.Equipment[Equipment_Class]=src
//usr.overlays+=icon(icon)
I += rgb(WR,WG,WB)
usr.overlays += I


// This is for all items equip. I know using I just for the icon file is kind of redundant but using icon or src wasn't working how it should as you can see how I had it once.


So because of this I really didn't see a way to add pixel_x or pixel_y to this and that is when I tried to use bound_x and bound_y to get around this problem. It might seem like a dumb way to do it but my programming skills aren't on par with yours but I would at least hope I make up with that by thinking outside the box. This is starting to sound like it is going to end up in Developers Help.
There's still no reason that you can't use an object. Objects have icons too, so instead of I += rgb(), you'd just do obj.icon += rgb(). Make sense?
Yeah on paper it makes sense but when I try it that way it messes up when it saves and won't let you remove the overlay for some reason and it seem to stop doing that after I added in the I var to take place of the icon. But that still don't change the part to where adding pixel_x = -32 pixel_y = -32 in the obj would change anything. It will change if I use src but then it will go back to not letting you remove the overlays after you save and log-out. Seeing how I don't re-color weapons I can have a second overlay part just for weapons.
That's because the object reference changes between saving and regenerating it.

You shouldn't be saving overlays: Check out my tutorial on the subject, particularly my conversation with midgetbuster:

http://www.byond.com/members/ Ter13?command=view_post&post=1187381
I'm gonna go ahead and close this report. When using gliding tile-based movement, the use of bound_x/y just doesn't make sense. bound_width/height in full tile increments does.
Lummox JR resolved issue (Not a bug)