We can no longer create new instances of objects in an object's field-initialization. If you try, the project will compile fine, but, at runtime, this produces bizarre errors when you try to use the field where the object does not exist yet is not null either. If you compare the object to null, the comparison fails, and if you check to see if the field is false, that comparison also fails [if(field == null) and if(!field)].
The only way I've noticed so far in which I can use the field and not get a runtime error is if the field is a /list and I try to iterate over it with for(var/x in list), which does not throw a runtime error but still does not iterate at all (as if it's an empty list)
Numbered Steps to Reproduce Problem:
1) Initialize an object's field to a new instance of an object.
2) Attempt to use the field.
3) At the moment it attempts to use the field in some way, the outcome is not as expected; if just outputting the field, it produces a bad output runtime error, if attempting to use one of the field's own fields (since it's supposed to be an instance of an object), it produces a cannot access ".fieldname" runtime error (notice it is not "null.fieldname")
Code Snippet (if applicable) to Reproduce Problem:
mob/var/obj/O = new
mob/verb/v()
src << O // bad output
// or...
src << O.name // cannot access .name
or
mob/var/list/L = list(new /obj)
mob/verb/v()
for(var/x in L)
src << x
// the above loop compiles fine but displays nothing, as if it's an empty list or not a list
src << L.len // cannot display .len
Also note that using newlist(/obj) produces same results
and for completeness...
mob/var/obj/O = new
mob/verb/v()
if(O == null)
src << "O == null"
if(!O)
src << "!O"
// at this point, you have seen no output
// both above expressions resulted in false
Expected Results:
We used to be able to initialize fields to new instances of objects, and it would work fine, as expected. I don't know if seeker/daemon were programmed to create the objects just before world/New() or what, but I recall it used to work.
Also expected: If we're NOT supposed to be able to do this, then it should not compile fine and produce very odd runtime results.
Actual Results:
Runtime errors (explained above) when accessing the field.
Iterating over the field as if it's a list does not produce runtime errors but does treat it as an empty list or not a list.
The object does not seem to exist (the field does not reference anything useful), yet it's not null.
The code compiles fine yet produces these results.
Does the problem occur:
Every time? Or how often?
Every time
In other games?
Probably
In other user accounts?
I was using guest, but no reason for it to be different
On other computers?
Unknown; I have access to only 1 computer at the moment
When does the problem NOT occur?
The problem is always occurring for me. I cannot get it to work as it should (used to).
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.)
It used to work for me in all previous versions that I would do this in. I update seldom, so I don't recall what the last version was that I used. If I am able, I will test this later and update this entry.
Workarounds:
Create the object as a statement within a function.
Your third example is direct proof that something else is wrong, because O is obviously null there and the failure to produce output means either output is being sent to the wrong place (or there's nowhere to send it), or somehow src itself has gotten botched in the routine you're testing. I'm guessing the examples you posted are extrapolated from other code in your project, but were not tested themselves in a vanilla project.