Zandronum

I am scripting a lot for the wad I am working on and I heard that Zandronum does not support acs_namedexecute , so is there any way to have over 999 number of scripts?

No. But you can save space by turning some scripts into functions instead.

Also, the there is a maximum variable limit of 128. Remember this.

Also I think there's a variable limit of 20 local variables per script. Not sure about the ones defined outside of a script.

Special scripts (ENTER, OPEN, etc) can be declared as named, actually, even right now. so you can use their numbers for other scripts. You can only do that to special scripts, because otherwise you won't be able to call them.

Ehm
#define Blood_Script 1

script Blood_Script OPEN{
...
}
Now you have a named script that can be compiled on zandronum
Also I don't think there's a need for 1000 scripts, ofc you can reuse a lot of it, just use your brain a bit

Wow every single one of you provided some nice information!

ibm5155 wrote: Also I don't think there's a need for 1000 scripts, ofc you can reuse a lot of it, just use your brain a bit

Yeah there is. Making multiple mods compatible with each other.

Konda wrote:

Code: Select all

script 1 (int scriptnum)
{
  Switch(scriptnum)
  {
    case 1:
      //Script 1
      break;
    case 2:
      //Script 2
      break;
    [...]
    case 65536:
      //Script 65536
      break;
  }
}

You can only have 128 cases per switch block, by the way.

Ijon Tichy wrote:

Konda wrote:

Code: Select all

script 1 (int scriptnum)
{
  Switch(scriptnum)
  {
    case 1:
      //Script 1
      break;
    case 2:
      //Script 2
      break;
    [...]
    case 65536:
      //Script 65536
      break;
  }
}

You can only have 128 cases per switch block, by the way.

Interesting, I never knew about this one.

Well 999 * 128 = 127,872. That should do!

ZzZombo wrote: Special scripts (ENTER, OPEN, etc) can be declared as named, actually, even right now.

Code: Select all

script "MyMod_OPEN" OPEN
{
//stuff
}

so you can use their numbers for other scripts. You can only do that to special scripts, because otherwise you won't be able to call them.

Are you sure that this really works properly and that "MyMod_OPEN" is not just converted to its internal ACS string number?

With bcc.exe, I'm not sure, but why would latest acc.exe do that? Both produced .WADs that worked correctly in the end.

Hi there, you can also use this: I never tested it above 100, but it gives you a lot of choice for a single script.

FYI you are the third one after ibm5155 and Konda to suggest this.

fr blood wrote: Hi there, you can also use this:

Code: Select all

horrible code

I never tested it above 100, but it gives you a lot of choice for a single script.

That is not only ugly but also very inefficient because the ACS VM will wind up testing all those conditions separately with O(n) complexity.

an else if would be welcome on blood code

You can also save script numbers by converting some scripts into functions. However you can't convert any script with delay() or tagwait() or anything that causes a delay, into a function. You also can't call functions from Decorate or via map specials. Only from an actual script you can call a function. But it's still an improvement.

I suppose you can also use switch blocks inside switch blocks to surpass the 128 cases limit, like this: Or if that's not going to work, then don't use Switchblockception: :v

The complexity of that would be O(n/128) which is better than what ibm suggested (unless the switch statements operate exactly like the if/else statements). This is basically how to write horrible hacks 101.

I always wondered, what is the reason for functions to not allow Delay in them? Does it break internally or what?

Ivan wrote: I always wondered, what is the reason for functions to not allow Delay in them? Does it break internally or what?

From a logical standpoint, functions' purpose is calculation (for example, abs function). So it wouldn't make much sense if it had delays in it. However, the void functions don't return anything so they're pretty much the same as scripts, so I don't know why they're not allowed to have delays in them. I am not sure, but I think delays are not allowed in functions for technical reasons, not logical reasons.

Ivan wrote: I always wondered, what is the reason for functions to not allow Delay in them? Does it break internally or what?

Well you do have acs_executewait but it takes up a precious script slot.