I did a forum search and was surprised that I found nothing on this subject.
When I put in a large icon and I move around, the icons appear and disappear when I move away from them. I was told that this is intended behavior. I'd like to know if it is, and if so, I'd like to know why. If it is indeed intended behavior, it completely ruins the point of large icons. If I can't put them down in a game without them disappearing right when I move, there isn't much point to them unless I'm not moving.
SuperAntx's Retro Game illustrates this fairly well as you can see the trees flickering when you move, and some disappearing when you stand still.
ID:132658
 Jan 16 2010, 10:19 am
|
|
|
Jan 16 2010, 2:09 pm
|
|
DarkCampainger
  |
Strange. This must have been a recent-ish change, because that game worked flawlessly not too long ago.
|
Fugsnarf wrote:
I did a forum search and was surprised that I found nothing on this subject. If you used keywords like in your topic name, then I'm not surprised. ;P I'd like to know if it is, and if so, I'd like to know why. It's quite intended, or more accurately, how it's supposed to be. A graphical extension of an object's appearance is still tied to that object, and will only be seen if that object itself is seen - which requires the client to be aware of it. The client is only aware of objects within its viewing range, to avoid needless bandwidth waste. Therefore, if an atom's location is outside of a player's view, that player won't see any of that atom, even if its visual appearance happens to cover the entire map. That's simply how it naturally works. This issue was eliminated in v455 by having the server account for extensions of objects' icons when sending map data to the client. However, this caused monstrous bandwidth problems with extensions that went too far away from the actual object, so the old behavior had to be reinstated, basically ([link]). If it is indeed intended behavior, it completely ruins the point of large icons. Large icons were added to BYOND in the release of v4.0. Other than not being able to edit large graphics directly in Dream Maker's icon editor, they work perfectly. Large atoms were never added, and would need revamping of the existing systems to even be possible. In the current system, it's a fundamental fact that an atom can only ever have one location (so it can't occupy more than one tile). The new 'big native icons' feature of v455 is nothing new. It's just a more convenient way of achieving the same functionality of pixel-offset overlays, which we've had for a very long time now. If I can't put them down in a game without them disappearing right when I move, there isn't much point to them unless I'm not moving. They don't disappear right when you move. They only disappear when the object (the object itself, mind) goes too far out of your viewing range. This is non-problematic with atoms that have a large graphic that doesn't take up many tiles. | |
I want a way to choose if I want them to disappear when I can't see the original tile of it or not. Changing the map_format is a terrible compromise to this issue that just won't work for me and many other programmers. I couldn't care less if there's a bandwidth waste. I'll take that over doing everything manually by each 32x32 tile any day.
| |
Well, this may be a different issue entirely, but then why do the bottom-right corners of the trees in SuperAntx.RetroGame vanish? I had assume that was what he was referring to, and the tree (parts) that vanish are still well within the view (in fact, I can stand right next to some of them and have them disappear)
Anyone else seeing this? | |
I wonder if this might be related to what was encountered in Regressia:
http://www.byond.com/members/IainPeregrine/forum?id=378 | |
Yeah, that (and what Foomer linked to) would be a whole different issue, then, if extended visual parts just vanish randomly with no reason, even if they're very much in range. That's definitely a bug. Since Peregrine said he noticed it after a BYOND update, he may be able to point out in which version it was added (or it could be that he or someone else filed a bug report already).
| |
Fugsnarf wrote:
SuperAntx's Retro Game illustrates this fairly well as you can see the trees flickering when you move, and some disappearing when you stand still. That's odd, it hasn't always done that. Both the tree trunks and grass are turfs with no layer set. Bumping the tree trunk up a layer seems to fix the problem. I noticed another bug though. Big icons just out of view don't seem to load upon login. The bug appears to happen in the video so it's been around for awhile. | |
I wouldn't think so, but it's possible. The problem is that the icons becoming invisible only really happens when you're moving to the right. If you're moving to the left, you'll obviously only see the lower-left corner before it disappears. If you're moving right, the entire thing will all of the sudden vanish and it looks really stupid. Big icons are just about a must for a project I'm working on now, and this is a big issue.
| |
SuperAntx wrote:
Fugsnarf wrote: Please post bug reports for these issues, with as much information as you can provide. Behavior that has changed in recent releases should be particularly easy to fix, so long as we can isolate the problem. I watched your video and also noticed the flickering. We should be able to fix that if we can get a sense of what the conditions are to trigger it. | |
Tom wrote:
Please post bug reports for these issues, with as much information as you can provide. Behavior that has changed in recent releases should be particularly easy to fix, so long as we can isolate the problem. I've submitted a bug report about the issue. I'm fairly certain it has something to do with an update in 460 which coincidentally was something I suggested. I watched your video and also noticed the flickering. We should be able to fix that if we can get a sense of what the conditions are to trigger it. I'm not entirely sure what causes it so I don't think I'll be able to submit a proper bug report. What I can say is you must be connected to a server, the tick_lag must be below 1, and the client.pixel must be moved rapidly in small increments. Even with all those conditions the flicker seems to be completely random. I'll have to sit down and see if I can figure out the exact cause. | |
SuperAntx wrote:
Tom wrote: Yeah, I think in that regard it's really not a bug, since the trunk is being used as an underlay, and per the new behavior overlays/underlays no longer do that "push back" of other neighboring tiles on the same layer. I think the overlay behavior we have now is much better, so the solution is to use the workaround you suggested, and increase the layer of the trunk. I watched your video and also noticed the flickering. We should be able to fix that if we can get a sense of what the conditions are to trigger it. If you can't figure out an exact cause, it could still help us to have a demo of the issue. I suspect the issue is related to new chunks of the map needing to sent periodically. However I know client.pixel_x/y/z also has an influence on the map boundaries and it's possible that during a refresh of the actual dimensions expected by the client, it's showing the map when it shouldn't be. So a demo would help me to isolate where the issue is cropping up. [edit] I'll probably be able to test this with your game myself, actually, but submitting a separate bug report for that flicker issue would still be helpful. Lummox JR | |
Kaioken wrote:
It's quite intended, or more accurately, how it's supposed to be. A graphical extension of an object's appearance is still tied to that object, and will only be seen if that object itself is seen - which requires the client to be aware of it. The client is only aware of objects within its viewing range, to avoid needless bandwidth waste. Therefore, if an atom's location is outside of a player's view, that player won't see any of that atom, even if its visual appearance happens to cover the entire map. That's simply how it naturally works. For me the big icon would still be visible with the default bottom left atom 2 or 3 tiles outside of view range. | |
Yes, the cilent atom update range is up to exactly 4 tiles outside of the client's view, as quoted in [link].
| |
That issue isn't really the point of this thread. The point is that I'm suggesting that there be a choice as to if I want the icon to disappear when it's far away, or stay there and deal with the bandwidth. I'll deal with the bandwidth any day to save the time, because the game I'm working on right now needs me to use big icons, or I have an enormous amount of work on my hands. Double the work it would normally be in fact, since I'm doubling the pixel size.
| |
You can always manage a "large object" using multiple atoms, like what hub://Shadowdarke.BigAtom does for you. That comes with various benefits as far as integrating the "large object" into the system goes, including it always appearing when in sight, no matter how large the object.
| |
I don't think you get it. The whole reason I want this is so that I -don't- have to do that. It saves time, and it's way easier to do, especially for what I need.
| |
It's not really saving time if you have to wait on someone to add a new feature to the language. It's as simple as including BigAtom and setting one or two variables.
| |
Nadrew wrote:
It's not really saving time if you have to wait on someone to add a new feature to the language. It's as simple as including BigAtom and setting one or two variables. For the staff, it's as simple as reverting the Big Icon behavior to what it was before they made it so it disappears like that. This 'bug' annoys the hell out of me. I call it a bug, because before I updated, I could freely put large background turf images on a map without worrying about it completely vanishing on me ingame. | |
Mista-mage123 wrote:
For the staff, it's as simple as reverting the Big Icon behavior to what it was before they made it so it disappears like that. That would be quite a game-breaking downgrade. You wouldn't be able to properly use big icons as overlays, or anything besides static map objects for that matter. Be mindful of how you design your maps from now on. Don't stack a bunch of turfs without configuring their layers accordingly. | |