ZDoom

I apologize in advance for such a huge pile of confusion, but I am stumped on this issue completely...

My problem? ACS doesn't allow for multi-dimensional arrays. Thanks to this, a strange system I've been working on is now in a state of panic. For you see, I cannot think of a simple way to achieve what I'm doing without this.

Basically, I have a three-dimensional array that contains data for several text-display terminals in the map. Each entry in the array has three levels: the terminal being accessed, what screen the terminal is displaying (hitting "use" cycles through the different screens on a single terminal), and the line of text being displayed. Yes, there is a reason for each line being defined seperately. Bear with me here.

The array setup I'd like to use would look something like this hacked sample: ...and so on and so forth. You get the drift.

Now, as you see, this would work flawlessly on a map scope, but my intention was to have the strings defined in a script library, to be accessed through any map at any time. And thus, my system cannot work because global variables don't support more than one dimension. I'm sure there's some type of strange technical limitation which prevents ZDoom from supporting such a feature, so I will instead take another route...

Can any kind soul provide me with a simple method to "simulate" such a system using only single-dimensional arrays? I'd hate to see this idea of mine go down the drain. If I can get this system working, the methods of implementing the screens in-map would be far simpler and not nearly so hellish to set up. However, that means I'd have to overcome this obstacle... how fitting.

Thanks for at least trying to make sense of this strange "request"...

For globals, you'd have to order them one by one.
Then you could assemble them into a map array like this if you must have a three dimensional structure.
If you needed to store anything back into the global array...
that should work.

I sized the array based on what you listed in your example. Since there were two terminals the first size is 2, two screens so the second size is 2, and three lines, so the last size is 3. If you continue on in that pattern, you should just be able to increase the first size in the array and make sure you increase the value in your loop test expression (i1 < 2) in the first for loop to match, and you shouldn't need to change anything else. If you change the X by 2 by 3 pattern in the global array, this is how you get your multipliers, for the first one (i1 * x) multiply the second and third sizes, and the second mulitplyer (i2 * x) is the third size of the array.

Anyway, didn't you volunteer to help make sprites for a certain project?

ACS does support multidimensional arrays, but apparently not as a global.

PS: Why not use code like
Print(s:"Terminal ", d:TerminalNum, s:", Screen ", d:ScreenNum, s:", Line ",d:LineNum);
where TerminalNum, ScreenNum, and LineNum are variables?

Agent ME wrote:ACS does support multidimensional arrays, but apparently not as a global.

Setzer wrote:Now, as you see, this would work flawlessly on a map scope

I'm pretty sure he understood that already. This is the case with any array above map scope.

Agent ME wrote: PS: Why not use code like
Print(s:"Terminal ", d:TerminalNum, s:", Screen ", d:ScreenNum, s:", Line ",d:LineNum);
where TerminalNum, ScreenNum, and LineNum are variables?

Because I would say Setzer is planning to do a little bit more that just print out terminal names.

Thank you for all your help, but as it always seems to work, a solution hit me shortly after creation of this thread. Solar's solution, while very ingenious, would have been difficult to manage due to my usage of very large amounts of data. I wound up instead using a row of switch statements to determine which terminal and screen are being accessed, and while it's a bit messier than I would have liked, it works admirably. Thanks again for trying to assist me anyhow, despite being left in the dark completely.

And I had intended to keep this secret, but I am starting a thread soon enough so I may as well reveal my purpose.

Yes, this is a fully-working in-game shot. I still have a few kinks in the system but it turned out rather nice. Props to those individuals who recognize the source of "inspiration". No, I am not planning a direct remake, but I do have ideas. Great ones.

Ohhh, pretty!

Setzer wrote:Solar's solution, while very ingenious, would have been difficult to manage due to my usage of very large amounts of data.

It's not at all difficult to manage large amounts of data that way. I programmed a near identical system a few years back to handle the exact problem you're having now and it handles 1120 distinct values which are frequently updated. If required, it could quite easily scale to much more.

Setzer wrote:Yes, this is a fully-working in-game shot. I still have a few kinks in the system but it turned out rather nice. Props to those individuals who recognize the source of "inspiration". No, I am not planning a direct remake, but I do have ideas. Great ones.

It looks intresting. But, please fix the horrible dithering, jeez.

Well, it is apparent you have never played Marathon, then. The demo screen is simply a direct rip from the game, pictures and text. The original image was subject to the same problems, so take it up with Bungie.
Before anyone asks, custom content is on the way, but I wanted to overcome the coding obstacles first before writing the project's terminal progression.

No need to be trashy.