ID:2379020
 
Resolved
Vars set in init procs in a parent type were not reset properly in child types. This has been fixed by completely revamping how init procs operate, combining them so only a single init proc is ever called instead of recursing through parent types. That was already a planned optimization, but now it takes the additional step of analyzing init procs so they can be combined intelligently.
BYOND Version:512.1429
Operating System:Windows 7 Ultimate 64-bit
Web Browser:Firefox 60.0
Applies to:Dream Daemon
Status: Resolved (512.1430)

This issue has been resolved.
Descriptive Problem Summary:

Initializer expressions such as "list()" and "new /datum" specified for a var on a type cannot be overriden in subtypes with non-initializer expressions, including "null".

Probably caused by an interaction between how "init()" works and the var storage changes in 1428.

Code Snippet (if applicable) to Reproduce Problem:
/obj
var/foo = list()

/obj/bar
foo = null

/client/New()
..()

var/obj/bar/O = new
src << isnull(O.foo)


Expected Results:

1 - the subtype sets the value to null

Actual Results:

0 - the parent type sets the value to list() and the subtype does not override it

Does the problem occur:
Every time? Or how often? Every time
In other games? Yes, in a minimal project
In other user accounts? Unknown
On other computers? 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.)

Introduced in 1428. Present in 1429.
Aw, crap. I understand why this would happen. This is gonna be a pain to fix but I'll try to come up with a solution.
Lummox JR resolved issue with message:
Vars set in init procs in a parent type were not reset properly in child types. This has been fixed by completely revamping how init procs operate, combining them so only a single init proc is ever called instead of recursing through parent types. That was already a planned optimization, but now it takes the additional step of analyzing init procs so they can be combined intelligently.
Any chance we get a before and after measurement of cpu and mem usage?
In response to Yoyobatty
That's something you'd have to measure for yourself. It will vary by game. In an early test of the optimization that went into 1428, MrStonedOne saw about a 100MB improvement in memory on /tg (we both thought it would be higher) and a slight speed boost in object init.

Consolidating init procs is not likely to have a huge impact on well-behaved SS13 codebases because the best of those should be generally avoiding init procs altogether anyway. The main reason I went ahead with the optimization now was because of the bug that the previous optimization introduced.
Interesting, perhaps he will be able to repeat the test again for this update. Also, when are we expecting beta 1430 to release? This fix you mentioned is included and fixes some game-breaking, albeit minor bugs in SS13.
Tomorrow is a likely target. I'm still looking into the old rc5 crypto library and how it changed with the newer builds due to 24-bit twiddling, so I want to get a handle on that and also see if I can add in any protections for worlds compiled before 512.