Well, I'm not Dan (or am I .. whohoo the mystery of Dantom lives on!) but after reading this I may be able to clarify a bit.

The problem comes when I load things from old savefiles. (The savefile does "for (v in src.vars) F[V] >> src.vars[V]" except with V is a variable like "type".) I had always thought that if the proceedure came across a variable there was no entry for, it would plug in the default value for that variable. But it's not doing that. Should I have the code say:

for (v in src.vars)
if (F[V]) F[V] >> src.vars[V]"

and would that work? (I hadn't thought of it until now. I bet it would.)

Yes, I think that would work. Without it, it looks like you'll just be nulling out new vars in savefiles.

But the real problem was... with the original saving code... these new list variables that didn't exist before (such as mob/var/list/skills), when they were getting their values assigned during the loading process, they were changing from lists into regular variables. So that listing the vars of a mob loaded from a savefile would reveal "skills" had the value of null, while the vars of a new mob would reveal that "skills" had the value of "/list". That meant I couldn't even switch the loaded mob's skills variable over to the default list.

I believe that your code-snippet above should solve this problem. Since you won't be nulling out the new vars, they will take on their default values, which will presumably be list values.

I think that the confusion is caused by the untyped nature of DM. Remember, just because you declare a var as a list doesn't mean that it will be used as such. In other words:

var/v
var/list/L

can be treated identically. The "list" simply tells the compiler to expect L to be a list. Assigning L to a non-list (like null) is still perfectly valid.

In your situation, I'm guessing that you have something like this:

mob
var/skills[0] // empty list

mob/New()
// assign default skills if needed
skills += "thievery"
...

[Here we use skills[0] rather than list/skills, because it automatically creates a new list for you. The alternative would be something like:

mob
var/list/skills // reference to a list
mob/New()
skills = list("thievery",...) list of default skills
...
]

Now all mobs will have some set of skills (or an empty set) by default.

When you write this to a savefile, it will save as a list. When you read it back in, it will load as a list. If you use your original code to read it in from a savefile that doesn't save this entry, your code will null out the skills, effectively discarding the list. In other words:

F["skills"] >> src.vars["skills"]

will make

skills = null

if that entry doesn't exist in the file.

So if you use your new saving code that checks for the existence of this entry, the skills var simply won't be overwritten when it doesn't exist in the file, and it will retain its original default (or empty) value.

See if that works.