Proc before map initialization

Page: 1 2
Sep 11 2015, 8:24 am
You might be able to do this with the global variable initialisations like this:

/var/datum/config/config = new

/datum/config/New()
    // Pre map initialisations go here.


Because IIRC, datums created like that will get New() called, even before other global variables are initialised (and also before the map is initialised)

(oh but DON'T put a sleep() in there, because I think that delays ALL global var initialisations and makes the map be initialised BEFORE the global vars are all done...)
Sep 11 2015, 8:39 am
How about...

Make objects initialize in world.New()'s ..()

So as long as you call parent after you have initialized things, you are fine.
Sep 11 2015, 10:56 am
In response to PJB3005
Smart workaround there, PJB. Thanks for contributing that. Hopefully Wirewraith and others will find it useful.

I suppose the only downside is that other global datums will init too, and the order may be unpredictable. But that's probably not a huge concern.
Sep 11 2015, 10:58 am
Yeah it is unpredictable, but still before the map gets initialised.

I actually stumbled upon that completely accidentally too.
Sep 11 2015, 10:59 am
In response to Lummox JR
Lummox JR wrote:
I suppose the only downside is that other global datums will init too, and the order may be unpredictable. But that's probably not a huge concern.

That would be my only concern with using it. If there was any way to force the order of initialization, that would be really neat. I'm not sure what impact it would have that a general pre-init proc wouldn't be able to do, but it's a thought.
Sep 11 2015, 11:05 am
Yeah, with global inits like that I don't think it's possible to control the order, except that I suspect the global inits will be processed in the order they were encountered.

What's happening there is that just like with an obj that sets up an initialized list var, a hidden init proc is created. This one just happens to be global. I don't know what order it chooses for the init, but I suspect it's simply chronological; in which case whatever it saw first, it does first.

So with that said, the most likely way you can guarantee a datum inits before all other procs is to put it in a file like 0defines.dm that will get preferential treatment in compilation order.
Sep 11 2015, 2:36 pm (Edited on Sep 11 2015, 6:19 pm)
In response to Lummox JR
Lummox JR wrote:
Smart workaround there, PJB. Thanks for contributing that. Hopefully Wirewraith and others will find it useful.

I suppose the only downside is that other global datums will init too, and the order may be unpredictable. But that's probably not a huge concern.

It is a concern, a concern that can be dealt with but the entire point of this thread is to not have to deal with it. We've been working around this issue for years but Wire is a newer member of the team and just tripped over it himself which lead to this post. The point of the request is to prevent this same confusion from repeating like it always does.

A guaranteed initial point of entry when a server is starting as a hook in DM itself would be much less confusing and very helpful to our situation and probably also to others. If it's not too difficult to add something like this we would really appreciate having it available.

Whether you can get to it or not thanks for all your work on BYOND Lummox, you've done a lot of wonderful things here.

Lummox JR wrote:
So with that said, the most likely way you can guarantee a datum inits before all other procs is to put it in a file like 0defines.dm that will get preferential treatment in compilation order.

Yep, that's what we do, although ours is _setup.dm :)
Nov 7 2015, 3:44 am
Almost certainly a topic created already for this, but it's too vauge for me to search and find any results, so apologies in advance.

A proc that is called BEFORE the world's initialization. Before things on the map are loaded.
Nov 7 2015, 5:28 pm
I am going to re-state my suggestion to lummox, and that is to move the initialization of map objects to ..() in world New.

This is what OOP is all about, the ability to have a child object want to do things before and after the parent object, encapsulation and modularity.

this way it would be

World/New() //called once world started
  config setup stuff
  ..() // initialize the map, create all atoms, etc.
  post map initialize code


Nov 12 2015, 1:16 pm
In response to Lummox JR
PJB3005 wrote:
You might be able to do this with the global variable initialisations like this:

> /var/datum/config/config = new
>
> /datum/config/New()
>     // Pre map initialisations go here.
>

I just found this and came to say it, darn someone beat me to it.

Lummox, how unpredictable is it? would var/__Init = new() come first? Alphabetical? Compile order, so if I put it in __Init.dm and it got compiled first?
Nov 13 2015, 3:51 pm
In response to Rushnut
I've messed around with that personally but I couldn't find any correlation to names or file order.
Nov 13 2015, 3:55 pm
File order should be the determining factor. If it's in the first file compiled, it should show up first.
Nov 13 2015, 4:18 pm
So you can open your .dme file and insert this line as high as you can (like, line 4):
// DM Environment file for <project>.dme.
// All manual changes should be made outside the BEGIN_ and END_ blocks.
// New source code should be placed in .dm files: choose File/New --> Code File.
var init/init = new

Then, anywhere else in your code, you can override:
init/New()
    <code goes here>

That code is guaranteed to run before any other global variable is initialized.
Page: 1 2