Oni (folder)/GameDataFolder/IGMD/global

Oni global script folder

"global" is a "secret subfolder" of IGMD : a regular installation of Oni doesn't have it at all.

But you can create it and use it and it's actually very rewarding. It's a very special folder.

What's so special about it?

The global folder is visible from every one of Oni's levels. Rather, the scripts (files with extension BSL) in the global folder are always processed at the same time as the level logic of a particular level, when that particular level is loaded.

How do I use it?

Is there really a short way to describe it? Oh well...

---

Let's say you want Oni to do the exact same thing every time you load a save point. Like, you've just learned about how the dmsg command works, and you want the message "Thank you for playing Oni!" to be displayed after a level loads. Then the trivial solution is to go in every level's folder, open the file where func void main(void) is declared and modify it as follows :

func void main(void) {
    dmsg "Thank you for playing Oni!"
#   WHATEVER ELSE THERE IS
}

OK. You've done that for all 14 levels. But now, let's say you've learned about how to add colors to debug messages, and you want the whole message to be red, except for the word Oni which shall be blue.

What then? Open every level's "main file" again and replace "Thank you for playing Oni!" with "[r.Thank you for playing ][b.Oni][r.!]"? 14 times?

No. You use the global folder

func pre

Go to the global folder and create a file called pre.bsl. Open it and give it the following content :

func pre {
    dmsg "[r.Thank you for playing ][b.Oni][r.!]"
}

Then go and open the 14 files where you had dmsg "Thank you for playing Oni!", and replace that line with pre, getting :

func void main(void) {
    pre
#   WHATEVER ELSE THERE IS
}

This is an inline call to the pre function we have just set up in the global folder. The function pre is "globally recognized".

Why call it pre?

Because everything in func main is level-specific settings and/or logic, so if you want something to happen exactly the same way every time you load a level, the only place to add that something is at the very start of func main, that is, before all the level-specific content. Which is why I've been calling it pre. Oh, you can name it shpadoinkle if you like... but that choice is a bit harder to justify. geyser

• Let's build a snowman, we can make him our best friend, we could name him Bob... or we could name him Beowulf! We could make him tall, or we could make him not so tall... Snowman!

Why make it inline? (WARNING : EXPERT STUFF)

Because in that case, it's as if the content of func pre got pasted at the start of func main which is perfectly OK for some purposes (like the dmsg "[r.Thank you for playing ][b.Oni][r.!]" call in the example above). Three things to consider :

1. You can always fork what you want to be forked inside func pre. And it will be exactly the same as if you placed the forked call directly inside func main.
2. If you put fork pre instead of pre in func main, you can no longer consider that you're "just adding stuff to the beginning of func main". You can make an inline call into a forked call, but not the other way round.
3. In some cases, you may want to be sure some part of func pre is executed rigorously before func main. And that's something you can not guarantee with a forked call.

Sure you can't put anything you want in an inline-called func pre, like a sleep statement, or a call to chr_wait_animtype. It's up to you to bear in mind that what you're looking at is in fact just a part of every level's func main.