We've done some more testing with players aswell, the Black Screen happens to both players at the same time, changing map and coming back to the map temporary fixes it until someome makes an action and then it goes black again.
i understand this is non trivial but this really should be at the top of the list, or maybe you should try hiring/asking someone who can help you out
can anyone say with 100% the highest size that I can cut the backgrounds so the black screen doesnt happen?
By default the client buffers 4 tiles on each side of the viewport. so 4*TILE_WIDTH, 4*TILE_HEIGHT. Anything bigger than 4 tiles on each side needs to be cut down.
In response to Ter13
Ter13 wrote:
By default the client buffers 4 tiles on each side of the viewport. so 4*TILE_WIDTH, 4*TILE_HEIGHT. Anything bigger than 4 tiles on each side needs to be cut down.

Why not just let the developer control this value?

It could even allow them to cut it a bit smaller if they don't have any large overhanging objects to display.
In response to Bravo1
Bravo1 wrote:
Ter13 wrote:
By default the client buffers 4 tiles on each side of the viewport. so 4*TILE_WIDTH, 4*TILE_HEIGHT. Anything bigger than 4 tiles on each side needs to be cut down.

Why not just let the developer control this value?

It could even allow them to cut it a bit smaller if they don't have any large overhanging objects to display.

There's already a feature request for this by MSO, a way to edit the client "bubble". He made the request for me because something I made was glitching visually when it left the viewport and came back in.

It's been dormant for a little while but Lummox liked the idea.

http://www.byond.com/forum/?post=1982146
I'm still confused about this. ok My game has 5 Maps with 5 backgrounds, and only 3 out of 5 dissapear the other 2 don't sometimes is 2 out of 5 sometimes is 1 out of 5 its never 5 out of 5.


I know complainig doesnt help but for the love of god, to not get the dissapearing bug I have to make those Cuts and make them seperated states, and thats just a tiny little area. For big areas will be a massive time waster and probably even performance issues from all those icons.

Please you need to fix this and soon not 1 year from now and not 5 years from now, it has to happen this months.

EDIT: Whatever kinda tests you need us to performe to get this bug fixed let us know. No more time wasting around with webclient fixes we need those old time bugs 3-5 years still around to be fixed already. The more time its left behind the less likely it will ever get fixed.
Just gonna throw in my two cents again. This is currently a dealbreaker for 510's major feature set.

Please prioritize a fix for this.
Yep, I know 510's features bring this more sharply into play. It's bumped up higher on my list.
Agreed, it's the only thing holding me back from going full on with MLAAS' lighting revamp.
In response to Zasif
Zasif wrote:
Please you need to fix this and soon not 1 year from now and not 5 years from now, it has to happen this months.

If it's just a fighting game or something with like 1v1 or something in a small area that you could move across

popped into my mind ._.
I haven't tested zoom at all, but you could increase the view size and then set the zoom to mimic the default "view" with an object with your eye set to it that follows the player to simulate the screen moving o: idk
I haven't tested zoom at all, but you could increase the view size and then set the zoom to mimic the default "view" with an object with your eye set to it that follows the player to simulate the screen moving o: idk

Hello server bog.
In response to Ter13
Ter13 wrote:
I haven't tested zoom at all, but you could increase the view size and then set the zoom to mimic the default "view" with an object with your eye set to it that follows the player to simulate the screen moving o: idk

Hello server bog.

For those who don't know how to handle the delicate nature of DM, sure.
Just to give everyone an update on this, this is my main current focus.

I'm starting with something like Ter's idea of a set of map chunks, and I'm going to use the data in each chunk as a way of seeing extra atoms that are out of the expected tile bounds. This will fit pretty decently in with the current setup.

Objs and mobs (counting images and animation, although rotations from animation are a tricky spot) are the first to undergo this treatment. Turfs I expect to be a lot tougher, but I can handle those later once objs and mobs are taken care of.
In response to Lummox JR
Lummox JR wrote:
Just to give everyone an update on this, this is my main current focus.

I'm starting with something like Ter's idea of a set of map chunks, and I'm going to use the data in each chunk as a way of seeing extra atoms that are out of the expected tile bounds. This will fit pretty decently in with the current setup.

Objs and mobs (counting images and animation, although rotations from animation are a tricky spot) are the first to undergo this treatment. Turfs I expect to be a lot tougher, but I can handle those later once objs and mobs are taken care of.

Hallelujah!
Question why is that this doesnt happen to objs, I can make the 3000x1000 background into an obj and the bug won't happen.
It does happen
On his particular project it doesn't occur if he uses objects, I was helping him with it. I think it might be a height thing, no idea.
Progress report: I have something working finally for objs and mobs. It's very rough around the edges and I think it needs a lot of cleanup, but the proof of concept is here--and I have it working with older messages, avoiding the need for a major version bump.
Page: 1 2 3 4 5 6 7