Descriptive Problem Summary:
in 510, it was changed so that client's view perception allowed them to see objects off screen if part of it was pixel shifted onscreen. (or on screen otherwise from transform or large icons)
However view() was not updated to take this into account, so view() and what the mob or client can see are out of sync.
ID:2145152
 Sep 8 2016, 10:07 am
|
|||||||||||||
| |||||||||||||
|
Sep 8 2016, 10:12 am
|
|
MrStonedOne
 |
basically the hope is to be able to use view(0, location) to get a list of atoms visible under the cursor for making a custom right click menu, but that's not working as intended.
|
I don't think this will ever be possible for view(). Transforms are strictly visual. view() only takes physical location into account, i.e. atom bounds.
It seems to me that a different proc would be needed for this sort of thing, one that uses the new visual bounds instead. | |
I mean, view() is suppose to be a list of atoms that can be seen, so it makes more sense to update view() with the new behavior, and that coincides with the ref:
view(usr) //objects that usr can see even when i use a client or a mob to do it, pixelxy and transform aren't taken into account. | |
I mean, view() is suppose to be a list of atoms that can be seen, so it makes more sense to update view() with the new behavior, and that coincides with the ref: Yes, but "seen" in the context of view() depends on physicality within the world. view() has never ever applied visual effects, since the first days pixel offsets were handed down. But when step offsets and bounds went into place, it was updated for those. All along from the beginning, view() has been about how objects' physical locations interact with opacity, luminosity, infrared, sight flags, and invisibility. So this would be a huge change. Changing view() in this manner would outright break many games, and would be a huge, huge performance hit. Having a routine that simply checks visual bounds and can grab a list of objects within those bounds, on the other hand (with no regard to opacity or luminosity, at that), is a very different animal, and would be doable. If the reference seems at all unclear on this point, then I think the logical thing to do is to clarify in the reference that view() is based on physical locations, as it has always been. That way no games break and performance is not hurt. | |
Honestly this is just bringing into focus many limitations to view()
How it works is undefined, changed by what context it's ran in, and limited. you can't make view() not take lum into account without using it on a mob, so if you want to use your own lighting system, and change flags on lit tiles, you have to use range() (since lum only goes up to 6) change every turf's lum to 1, then view() then range() again to set the turfs back, or start changing a special mob's locs around and use view on that mob. It acts like it's the same as client's visibility, the docs strongly suggest it is, but it's not, except when it is, maybe, depending on how you read the docs. There is still no way to simply see if a given turf or atom is in view of a given atom without looping thru view. Then there is the mess with hear(). Then there is viewers(), just as needlessly limited. its like view() except when its not. If I can't get this fixed in view() for 511, and this is gonna get held up for 512, lets just flat out 100% refactor all of view and hear and the procs and the client side shit, while we are at all. add flags, remove the bullshit mob limitations, add the ability to have it work off of a mob's sight flags and other shit, but have a center that isn't mob.loc. ie, a third arg to allow the mob and the center be different. (or just remove that and allow sight and the rest to be passed to view() directly) add some of the sight vars to all atoms since nobody said an object or a turf can't see other things (in game camera, "talking" immobile wall, etc) There is so much that needs to be unfucked about view() range() hear() hearers() viewers(). Pixel shift apparently changes what tile an atom is on for client view sakes, but doesn't get taken into account for locs, or view() or anything accessible in game. And again, to repeat, the reference says view(client) and what the client can see on its screen should be the same, but thats not the case now, and all of our code is expecting that to be the case, the name of the proc makes it sound like that should be case, but its not, because reasons. | |
I think a new proc to grab all atoms in the visible bounds of a tile WOULD be great though.
| |
i think we should just unfuck view() and related functions then allow that to naturally do what you are suggesting.
| |
MrStonedOne wrote:
Honestly this is just bringing into focus many limitations to view() It's defined, but the rest is accurate. you can't make view() not take lum into account without using it on a mob, so if you want to use your own lighting system, and change flags on lit tiles, you have to use range() (since lum only goes up to 6) change every turf's lum to 1, then view() then range() again to set the turfs back, or start changing a special mob's locs around and use view on that mob. Luminosity should actually support values over 6 now. But yeah, there's no way to discount luminosity entirely. That could be accomplished with a new flag, which would be a good choice for a feature request. 511 added SEE_THRU to ignore opacity for that reason. It acts like it's the same as client's visibility, the docs strongly suggest it is, but it's not, except when it is, maybe, depending on how you read the docs. That's a fair point. Big-icon objects for instance are checked against multiple turfs on the client end to see if they're visible on any of them. Of course if the bounds match the icon, then view() should already account for that properly. There is still no way to simply see if a given turf or atom is in view of a given atom without looping thru view. Quite true. That's a limitation based on how view() works. It is not a direct LOS calculation, but always has to take the entire field into account and spread shadows and light. Doing that calculation on a direct path for just opacity would be difficult, but not necessarily impossible; handling luminosity in that way would not be. The ultimate issue is that BYOND's view code is not a true shadowcaster (as is found in many Roguelikes), and it's also tile-based. It was designed around doing the best job feasible for tile-based games with a lot of flexibility, and generally speaking it does. I simply don't think the perfect view() you envision is at all achievable--and altering the way existing games work is absolutely a no-go. What I do think is that certain limitations in the existing system can be improved upon. And I'm not necessarily averse to trying to implement something like a more realistic view() but with a different name. But we're also talking about mixing a system that's tile-based with tile-crossing situations (transform, offsets, etc.), and there are inherent difficulties with that. | |
So far what I'm getting from this is that a bunch of feature requests are in order:
- A proc to say which atoms' visible bounds overlap with a given pixel bounds region, like bounds() and obounds() but based on the visual bounds introduced in 510. (I'd have to double-check whether any bounds at all are kept for objects that aren't "out of bounds", that is not offset by very much and not using big icons. Even if not, looping through turfs internally to grab them would probably be acceptable.) - A sight flag that ignores luminosity in view() calculations, just as SEE_THRU ignores opacity. - Possibly allowing TILE_BOUND objects to avoid being always shown with SEE_PIXELS in use (that one's not related to any of the above, but it occurred to me when considering SS13's general needs). - A possible new proc that acts much like view() but is based on visual bounds rather than physical ones, so it acts more like what the client actually sees visually. - Maybe adding new arguments to view() (would require new instruction codes) allowing sight/invisibility values to be sent manually rather than forcing the reference point's info to be used, allowing for easier use of the view system without having to resort to making temporary mobs. | |
Yeah I think that list is pretty on point with the kind of internal functionality that would help us with a lot of various projects.
| |