We can have Data Lumps, which would result External String Tables, and Extendable Mods. So, what are they?
Data Lumps:
Data lumps mean some new wad lumps that can assign Global and World variables to their values, but from external lumps.
Currently in the ACS scripts, we can define global or world variables and give them unique index numbers. After that, we should initialize those values by the help of loops and the like, in Open Scripts or somewhere else.
However, if we could have these data lumps, we could initialize these values with a single ACS function and via the external data lumps, and do much more.
We can have a new ACS function that would load the contents of a data lump into memory, and then, fill in the actual values of Global and World variables, and we can call this function once when the player enters a hub, or when we need to change a lot of Global or World data.
These data lumps would simplify the job of filling big global or world arrays, but they would have another impact on our mod making styles, i.e. they would enable us to make some greatly extendable and tweak-able projects as well, projects that would let other people tweak them, as they like. How come?
These data lumps can be placed between DT_START and DT_END markers, and like SNDINFO, they can be incremental, i.e. newer wad files can contain data lumps that would override some data from older wads. Thus, we can have Patch wads that would correct or tweak some data from older wads.
For instance, a data lump that is called DATA17 can be something like this:
//--[[
Global {
// int 1:Foo1[];
int (1)[63]=0 // defined first to allocate the whole memory just once
int (1) = {2,17,65,32,135,3243,22,33,3456,234} // 0 --> 9
int (1)[32] = {234,345,2,54} // 32 --> 35
...
}
World {
...
}
//--]]
In addition, a newer wad can contain another DATA17 lump like this:
//--[[
Global {
int (1)[5] = {11,735} // 5,6
}
//--]]
As you can see, the second lump could override and change a part of the data defined in the first lump. This feature can be useful in many ways, which I would describe later.
External String Tables:
Hopefully, we can use the Global or World string arrays as string tables and by the help of these data lumps, we can have external (replaceable) string tables.
For instance, someone can make a ZDoom mod and place all the message strings in a global string array, and initialize it with a data lump called LOC_TEXT, like:
//--[[
Global {
// str 1:Buttons[]
str (1) = {Yes., No., OK., Return., Why?, ...}
// str 1:Mess[]
str (2) = {
Maybe later.,
Alright lets go.,
Where is it?,
Move it, we are late already.,
...}
}
//--]]
Then maybe later, another person would make a German patch for the project, i.e. translate all these messages into German, place them inside another LOC_TEXT lump, and place that lump inside a patch wad, like Proj1_German.wad, between the two markers.
After that, if we add the new wad after the original wad, we would have a German version of that ZDoom mod.
Extendable mods:
This is only the beginning, because we can do many other things with this feature, for instance:
Mod makers can place some key data and configurable variables in their initiating data lumps and let their users know about their functionalities, and users could add some patch wads that would change these values to their liking.
Thus, we can make some greatly extendable mods that would let the users change them as they like or add their extensions for them.
We can define some global or world arrays, which by the help of some open scripts, would configure some aspects of our levels, like monster or resource placements, or game flow, or level part access, or even environment and the mood of the level, (different skyboxes, and light settings ).
And then we can initialize these arrays via a data lump and give-out the definitions of the configuration data arrays along with the wad, and this would let the players tweak the levels to their liking, before they play it, or play it several times, and each time would be a different experiment, depending on their tweaks.
They can swap these configurations around and share their personal experiences of our levels.
Again, we can have mods that would let other people make levels and add them to the mod, as they like.
Elidor:
An example of that would be my project Elidor, which I will describe later in the editing forum, but for now:
Elidor would have some code banks that would be made of some integer arrays, which would define all the conversations and game flow on the levels, and if those could be defined in those incremental data lumps, then anybody could tweak them with some patch wads.
This would result in great extendibility, for instance, people could make their own levels and change a conversation or two, and in some conversation results, jump into their own addon levels.
I can make decorative doors that would open to nowhere, but these doors could be extended in future addon patches to teleport the players to other levels, maybe made by someone else...
There would be lots of computer terminals throughout the levels, and some of them may have a game or two, maybe an ACS Tetris or Space-invaders, some game may shut down the RPG engine entirely and jump into a normal level for a pure shooter game, and in return restore RPG engine to its previous state.
I can retexture some old levels to the new textures and call them via a computer terminal for a shooter game bonus, and hide them around the levels, and other people can add their addon games to these as well.
If you are into ACS yourselves, you can add your episodes and adventures to the main plot, and if they do not interfere with the main plot, or enhance it, then they may be included in the next version...
Moreover, by the help of these data lumps, each level could have information accessible by ACS to be shown in some situations, maybe level name, author, release date, tips and info, and so on...
For instance, if the player presses a certain key in the game, this info would be shown to him, and he would know the name of the place, its author and optional tips.
Think about the possibilities...
