Pixel perfect

Sep 3 2011, 5:50 pm

My two Windows 7 desktops have an issue with the in-DM reference. They aren't updating to the 490 reference, and deleting the "C:\Program Files (x86)\BYOND\help\ref" folder, containing the files DM actually pulls the reference from, does nothing.

However, Forum_account's Pixel Movement library has a reference feature where he injects his custom reference pages into the .html file and it works, whether the folder exists or not.

Is there some parallel hidden folder with the same file path that I can't reach from the Start menu that BYOND and Dream Maker can? I know it's supposed to update my reference because I have a Windows XP laptop that has the proper 490.1102 entries.

I don't know if this is a bug or if it's my computer acting up somehow, but help would be appreciated.

Sep 3 2011, 5:53 pm

Super Saiyan X

Kaiochao wrote:

My two Windows 7 desktops have an issue with the in-DM reference. They aren't updating to the 490 reference, and deleting the "C:\Program Files (x86)\BYOND\help\ref" folder, containing the files DM actually pulls the reference from, does nothing.

However, Forum_account's Pixel Movement library has a reference feature where he injects his custom reference pages into the .html file and it works, whether the folder exists or not.

Is there some parallel hidden folder with the same file path that I can't reach from the Start menu that BYOND and Dream Maker can? I know it's supposed to update my reference because I have a Windows XP laptop that has the proper 490.1102 entries.

I don't know if this is a bug or if it's my computer acting up somehow, but help would be appreciated.

I have the same issue. Lummy suggested it's because of some internal IE cache...but I cleared every Cache I know of. Still have the issue. Try reporting it?

Sep 3 2011, 6:03 pm
Gooseheaded	While using an isometric project, I cannot edit maps using the map editor. I can make a map file and it will be created with the max X Y and Z variables, but I can't place, remove, or select anything on the map.

Sep 3 2011, 9:22 pm
Liam Howe	Whn will the linux version update?

Sep 3 2011, 9:24 pm
Avainer1	It was updated @ Liam. Fugs and I ran a test server.. So I had to update it. Works fine. Click here to download it!

Sep 3 2011, 9:25 pm
Liam Howe	I should of asked about it earlier when I checked and it hadn't updated, I've just made myself look like a prat now lol. Thanks.

Sep 3 2011, 9:44 pm

Naokohiro

Super Saiyan X wrote:

Kaiochao wrote:

My two Windows 7 desktops have an issue with the in-DM reference. They aren't updating to the 490 reference, and deleting the "C:\Program Files (x86)\BYOND\help\ref" folder, containing the files DM actually pulls the reference from, does nothing.

However, Forum_account's Pixel Movement library has a reference feature where he injects his custom reference pages into the .html file and it works, whether the folder exists or not.

Is there some parallel hidden folder with the same file path that I can't reach from the Start menu that BYOND and Dream Maker can? I know it's supposed to update my reference because I have a Windows XP laptop that has the proper 490.1102 entries.

I don't know if this is a bug or if it's my computer acting up somehow, but help would be appreciated.

I have the same issue. Lummy suggested it's because of some internal IE cache...but I cleared every Cache I know of. Still have the issue. Try reporting it?

http://www.byond.com/members/ BYONDHelp?command=view_tracker_issue&tracker_issue=3051

Sep 4 2011, 1:59 pm (Edited on Sep 4 2011, 2:04 pm)
CauTi0N	Whilst certainly very happy about this, I did a test and it seems a bit choppy. Any ideas on how to fix the visual... errors? I literally made a mob that walks with step_size=4, so it's not that there are programming errors. However, I do enjoy the fact that when you set step_size to 70, it won't set you over the edge.

Sep 4 2011, 2:02 pm
Lummox JR	I need more to go on than "a bit choppy", but I can tell you that several issues have already been raised (and several fixed) in this comment thread and in bug reports.

Sep 4 2011, 2:12 pm
Minorex	When is the 490.1103 patch going to be released? I've been waiting for 5 hours or so for it to be downloadable so I could get in touch with my host to get him to update his BYOND and host my project for testing.

Sep 4 2011, 3:59 pm
Tom	There is a new release (build 1103) in http://www.byond.com/download/build/490. This fixes a few of the bugs reported here.

Sep 5 2011, 1:38 pm

CauTi0N

Lummox JR wrote:

I need more to go on than "a bit choppy", but I can tell you that several issues have already been raised (and several fixed) in this comment thread and in bug reports.

You should know by now my ability to report bugs is not near my ability to report anything else. :P When I say choppy, it appears as if the image wants to simply delete itself and then re-appear whenever the character moves. Not a hindrance to gameplay, just a visual error. I'm not sure if it has to do with changing the fps or if it has to do with your removal of "gliding," but it definitely seems like visually things are just being re-placed rather than actually moving.

This might have been fixed, I have no idea. I'll test it out on another computer later also, it could be this graphics card.

Sep 5 2011, 2:23 pm
Fugsnarf	From what you're explaining, that problem should be fixed. I'm having absolutely no problems with movement animation or looks. There are apparently minor slow-downs and speed-ups that don't affect gameplay too much

Sep 5 2011, 4:03 pm
CauTi0N	Appreciate the response Fugsnarf.

Sep 5 2011, 9:34 pm
BlackKingX	Pixel turning(for top-down games) too?

Sep 6 2011, 10:19 am

Forum_account

Overall it's better than I expected, but does have some problems. Most are insignificant, but some are rather annoying.

1. The step_x and step_y vars can't be incremented by decimal values. Imagine a top-down shooter with 360 degree movement - you can't just do something like this:

Move(loc, dir, step_x + cos(angle) * step_size, step_y + sin(angle) * step_size)

Because certain angles will prove slower and negative movements will be favored (-3.5 rounds down to -4, while 3.5 rounds down to 3). Soft code can work around this, but only to a limited extent. If support for more geometry is added this problem will only get worse.

2. If a mob is standing against a wall (see below) and tries to move up and left, the move fails entirely. Is there a way to make it succeed partially? For example, if the mob is trying to move up and left 4 pixels, they end up moving 0 over and 4 up?

Wall
 #
 #
 #
 #mob
 #

I'm sure I'll get the answer "call Move twice" but that's far from ideal. It's potentially incorrect - handing the move piecewise can make you bump or cross objects you wouldn't otherwise bump or cross. It also convolutes the usage of the Move proc. If you wanted to override it to make things happen when a player moves, you'd have to detect when it's being called to perform this type of move because you're using two calls to emulate one conceptual move.

3. It's also strange to use the Move() proc to perform a move in two directions. Is there another way to do this? For example:

// is there a better way to do this?
Move(loc, dir, step_x + 3, step_y + 5)

// something like this, maybe?
PixelMove(3, 5)

To perform a move you have to read the mob's current loc, dir, step_x, and step_y when you don't care at all what the values of those vars are.

4. The Bump and Cross procs could be given more information. For example, what was the move that's trying to be performed (for Bump) or was performed (for Cross) that is resulting in the proc being called? The pushable crate example in the demo is a mess for what should be a stupidly simple feature

we've made it our mission to do this in the most intuitive way possible.

    Cross(atom/movable/A)
        if(ismob(A))
            if(step(src, get_dir(A, src), max(1, A.step_size - bounds_dist(src, A))))
                PlaySound()
        return ..()

I don't see anything intuitive about that second if statement. The values you're searching for (which, in this case, we're lucky they can be found) could be passed to the Cross proc. To keep it intuitive the developer should be as insulated as possible from ugly calculations like that.

Sep 6 2011, 10:28 am

Lummox JR

To respond to those issues quickly:

1) While I might not necessarily rule out decimal support for step_x/y for the future, at present they are not implemented that way internally and it's way more trouble than it's worth to do so.

2) This situation already comes up in legacy code. If you want the mob to move north when hitting a wall going northwest, you need to do custom processing for it. That hasn't changed. Changing this as you describe would be inconsistent and would break existing code.

3) A proc like you describe is simple to setup in soft code, but we have discussed the option of adding appropriate step and walk procs.

4) I'm more than happy to modify the Cross() proc, but what values do you suggest providing? The current distance or the potential overlap? Distance in each direction? Direction of movement? (Note the get_dir() is there on purpose because the mob's dir might not be the push direction, if moving diagonally.)

Sep 6 2011, 11:42 am
Gigimoi	I'm yet to have any issues with it, good job! For simple use, it's great!

Sep 6 2011, 2:40 pm
Tom	Build 1104: http://www.byond.com/download/build/490

Sep 6 2011, 3:55 pm

Forum_account

Lummox JR wrote:

To respond to those issues quickly:

1) While I might not necessarily rule out decimal support for step_x/y for the future, at present they are not implemented that way internally and it's way more trouble than it's worth to do so.

2) This situation already comes up in legacy code. If you want the mob to move north when hitting a wall going northwest, you need to do custom processing for it. That hasn't changed. Changing this as you describe would be inconsistent and would break existing code.

The easiest way to implement #2 is to implement movement entirely in soft code. I wouldn't say that it breaks existing code because there was no existing code that used the native pixel movement. You're right that it's not consistent with the tile-based behavior, but it never will be. Moving a pixel at a time isn't consistent with the old behavior, this is just a consequence of adding a new feature.

Imagine a top-down shooter with 360 degree movement - you're being chased down a hallway but because you're not running perfectly parallel to the walls, the second your mob's shoulder touches the wall you stop dead and are easy pickings for whatever was chasing you. It's just not that useful of a default behavior.

3) A proc like you describe is simple to setup in soft code, but we have discussed the option of adding appropriate step and walk procs.

It's essentially just a convenience, but it's a convenience that everyone would want and including it shows that you understand how people would use the feature.

4) I'm more than happy to modify the Cross() proc, but what values do you suggest providing? The current distance or the potential overlap? Distance in each direction? Direction of movement? (Note the get_dir() is there on purpose because the mob's dir might not be the push direction, if moving diagonally.)

For the Cross proc the distance of the overlap and the direction of the breach (which side of the tile was crossed first). For the Bump proc there are more values that wouldn't be known: original position, magnitude of the potential overlap, total attempted move, direction of the bump. I'm not sure which values would be most useful, but in both cases the direction would be useful: making tiles that can be entered/exited in one direction, boxes that can be pushed in one direction, mobs that bounce elastically, etc.