Descriptive Problem Summary:
I have no idea what's going on here, just that something is. My attempts to make this into a nice small demo have failed, so I'm going to have to do this as a download-the-BS12-source example :(
Numbered Steps to Reproduce Problem:
1. Download the Baystation12 source tree; zip file here
2. Insert "/datum/New() return ..()" anywhere before line 12 of code/world.dm,
var/global/datum/global_init/init = new ()
3. Compile, run, and watch the entire codebase runtime.
A useful test position is line 80 of code/_helpers/global_lists.dm, which is where the first runtime occurs (the line "hair_styles_list[H.name] = H"). At this point, my testing has found:
- hair_styles_list is not a list, datum, or any other built-in type
- hair_styles_list is not null, but behaves very much like null (hair_styles_list.type runtimes "Cannot read .type", call(hair_styles_list, "something")() fails "Cannot execute null.something()")
- hair_styles_list is boolean true
- "[hair_styles_list]" is the empty string
Code Snippet (if applicable) to Reproduce Problem:
(This is an example of what the top of code/world.dm could look like following the above instructions)
/datum/New()
return ..()
/*
[...]
*/
var/global/datum/global_init/init = new ()
// [...]
Expected Results: The insertion of "/datum/New() return ..()" in any file would not affect the execution results of any code.
Actual Results: It broke the entire codebase.
Does the problem occur:
Every time? Or how often? Every time.
In other games? No.
In other user accounts? Unknown.
On other computers? Unknown.
When does the problem NOT occur? N/A
Did the problem NOT occur in any earlier versions? If so, what was the last version that worked? Unknown.
Workarounds: None
Also, you should never specify a return value in New(). Does simply calling ..() without the return statement have the same effect?