ID:2577552
 
Not a bug
BYOND Version:513.1525
Operating System:Windows 10 Home 64-bit
Web Browser:Firefox 76.0
Applies to:Dream Daemon
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:
Area datums returned from "locate() in world" statements have contents list with zero elements when they actually have contents.

As a consequence, any for-list on the area will not iterate or yield anything.

Numbered Steps to Reproduce Problem:
1. Locate an area of choice from world
2. Run length() on the area's contents

Code Snippet (if applicable) to Reproduce Problem:
Consider cloning this SS13 codebase: https://github.com/Baystation12/Baystation12
Then at the file /code/module/overmap/ships/computers/helm.dm - alter the get_known_sectors proc:
/obj/machinery/computer/ship/helm/proc/get_known_sectors()
var/area/overmap/map = locate() in world
world.log << "Size of area's contents: [length(map.contents)]"
for(var/obj/effect/overmap/visitable/sector/S in map)
if (S.known)
var/datum/computer_file/data/waypoint/R = new()
R.fields["name"] = S.name
R.fields["x"] = S.x
R.fields["y"] = S.y
known_sectors[S.name] = R
..()


Expected Results:
The area datum to have contents list with non-zero length and contain elements.

Actual Results:
The area datum has contents that is completely empty.

Does the problem occur:
Every time? Or how often? Every time
In other games? Unknown
In other user accounts? N/A
On other computers? Unknown

When does the problem NOT occur?
Unknown.

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.)
Unknown. It may have worked before 513 or 512 judging from how the code has been written.

Workarounds:
Getting the map datum from an other acquisition method.
The phrase "area datum" is confusing AF because that isn't a thing. It's just called an area.

But are you sure the area has contents at all? The code above doesn't show any way of disproving that the area is empty, and it's entirely possible to instantiate an abstract area that doesn't actually exist on the map and has no contents at all.

Area contents are calculated two ways. First, by looping through all turfs on the map and their contents. (That's what happens in a for() loop, which is why for performance you should always avoid looping through or even using area contents.) Second, areas can also contain objs and mobs directly, for when they're used as rooms in a MUD, so those direct contents are counted as well.

If an area actually is on the map then there's no way that its contents list should be empty. This tells me the area you're getting is one that isn't on the map, so you must have some abstract areas hanging out.
The phrase "area datum" is confusing AF because that isn't a thing. It's just called an area.

area is a child of atom, atom is a child of datum.

ss13 circles use datum to be the byond version of Object, or struct.
MrStonedOne is correct about the confusing use of "area datum" - my apologizes about that.

Yes, the area doesn't exist on the map during compile-time; as it is only inserted into the world during run-time when the server is up and running.

I've tried this thoroughly as I could get to be. I've let the generation finish before trying to acquire the area from the world. But the contents still return empty despite it existing there.

So the only method I've used so far has been using a locate(x,y,z) at the z-level where it is exclusively reserved for the area. To get the turf, then get the area through the turf's loc variable. Which has been working splendid so far.
In response to Irrationalist
Irrationalist wrote:
So the only method I've used so far has been using a locate(x,y,z) at the z-level where it is exclusively reserved for the area. To get the turf, then get the area through the turf's loc variable. Which has been working splendid so far.

I'm a little confused: this method is returning an area that has contents, or that doesn't?

If the area is confirmed to be on the map then it should definitely have contents. If it doesn't that would be a big bug, but I'd need a test case for it.
In response to Lummox JR
Lummox JR wrote:
I'm a little confused: this method is returning an area that has contents, or that doesn't?

This method does return an area that has contents. Compared to the previously stated method (locate(type) in world), that I had issues due to it returning the area without the contents.
Lummox JR resolved issue (Not a bug)