ID:2422389
 
(See the best response by Kaiochao.)
A rather specific question here: Do objects hold their null vars? For example:

obj
var
autoInitialized = "Some value"
nullUntilNeeded


Now let's say we had a verb to print out all of this obj's .vars list -- autoInitialized would appear of course, but assuming nullUntilNeeded was never assigned and remained null, would it appear as well? To more generally put it, do null variables still exist in every instance's var list, or are null variables left out of its .vars until initialized?

I am hesitant on just how many variables I can get away with assigning to specific types of mobs and objects, if they will all be carried around and bog down its .vars; I'd much prefer if null vars were left off that specific object.
Best response
Couldn't you just see for yourself?
mob
var blah
Login()
src << ("blah" in vars)

Let's say we had a verb to print out all of this obj's .vars list. Like, if the DM Reference had an example for printing out all of an object's .vars list:
mob/verb/dump()
var/V
for(V in vars)
usr << "[V] = [vars[V]]"

You'll see that some built-in vars default to null, and they're still in the vars list. The vars list is a list of vars defined for an object, and null is a valid value for vars before and after initialization, so it wouldn't make sense to leave them out.
I did consider trying to print the entire .vars, though due to the poor management of variables in the past with the source code I work with, mobs have an amount of variables ranging into the quadruple digits, so it wasn't terribly helpful.

Your bottom example of printing I had not thought of as you would never really try to do that (as far as I could imagine). Thanks for answering as well. A shame it turns out that way, but cheers.
In response to SeymourG
How is it possible to have thousands of vars in a single type unless there's some kind of automated code generation or a lot of copy/paste involved? Using 1000 variables instead of a single list of 1000 elements, or something like that?
No, just really really poor var management. The source has been through a lot, what can I say.

You'd think if you had two different enemy types, they'd have certain vars only they would use defined to themselves, like:

mob
Henchman1
var
HenchHit = 1
HenchFollow = 0
Boss1
var
BossRules = "Something"
BossBash = 150


But no, several people had the bright idea to instead define almost every mob var for all mobs, like:

mob
var
HenchHit = 1
HenchFollow = 0
BossRules = "Something"
BossBash = 150


So now, every mob has an incredibly excessive amount of vars, most of which it can and will never use. Fixing that at this point would be virtually impossible, as you'd not only have to fix the assignment, but add checks to so many mob procs...

They're mostly not copy-pasted, it's just the result of a lot of buildup. And the same goes for obj's.
In response to SeymourG
If your code is really as unmanageable as you say, a starting point might be to simply move the entire problem onto a subtype of /mob.

So you could just make a backup copy of your codebase, then start attacking it with find and replace, looking for "mob" and replacing with "mob/entity", "mob/actor", or whatever ambiguous name you choose to call everything. Just be sure you are changing type paths and not anything else. If the world.mob var has been left unchanged, that will need to be manually set to the same path, at least until you decide to give player mobs their own separate type.

By moving all definitions onto a subtype, you will have freed up the /mob type and returned it to the default state, which should allow you to gradually shift the code onto more proper subtypes. When you can split the solution to a problem into stages, it becomes a whole lot more feasible to implement.
To answer the question a bit deeper.

"Do object hold their null vars"

Objects do not allocate memory for any of their variables until that variable is changed from their compile time value (initial(thing.var)). This applies to both null vars and non-null vars.

mob
var
blah = null
blah2 = "not null"
blah3 = "not null"
New()
blah2 = null


In this example, a new mob would hold its blah2 variable, but not its blah or blah3 variables, (until they got written to) instead looking up the compile time value that is only stored once for each type.

Note, references can only be assigned at runtime, so blah = list() would be null at compile time, and a list at runtime.

In response to MrStonedOne
MrStonedOne wrote:
In this example, a new mob would hold its blah2 variable, but not its blah or blah3 variables, (until they got written to) instead looking up the compile time value that is only stored once for each type.

That is absolutely what I was looking and hoping for. This way, I can sleep a little easier when I create new variables. Thank you for the additional insight.

Login to reply.