ZDoom

This had already been added for ZScript because internal game code needed it.

YES, that would be amazing. Compiling ACS is one of the only major headaches I have with modding.

8-)

Personally I would like to see ZDoom come with an internal ACS compiler, if nothing more than to allow for projects to ship entirely in Text format (UDMF, ACS source, DECORATE, etc) sans assets such as models, images, etc. This also keeps them DVCS (Hg/Git) friendly.

A global library does sound like a good idea, though, but savegame compatibility could be an issue.

There are times when I wonder if ZDoom should ship with an internal ACS library which handles a lot of these cross-integrations. IMO using ACS itself is a non-issue, compared to everyone having to re-write the same code for basic functions they need.

There's a minor precedent to this: Script 0 (used internally for Strife functions). Of course, that doesn't need to be changed often (if ever), and a global library that's getting periodically updated might present more save compatibility problems. I'd need a little more input on that before I'd call it a good idea.

Exactly what Eruanna stated, though for now i settled with using the method explained by amv2k9, a way to do this with just decorate would be good for clean code, though i'm sure someone else with more experience than me would be able to name another case were a decorate-only check would be useful.

I'm thinking Haze wants this to be a purely Decorate solution, not something you work around with ACS.

ACS is something I think some modders prefer to avoid, mostly because of the extra steps required to get code working and tested. If you don't streamline your ACS development environment, it's a pain in the ass to even use it.

It also used to suffer problems from being a number-only system, before the ability was added to use named scripts, which ran a huge risk of number collision if you used the same library for every mod.

[quote="HazeBandicoot"]Pretty much the same as the acs [url=http://zdoom.org/wiki/GameType]GameType[/url], unless this is already possible...[/quote]Use [wiki]CallACS[/wiki] (aka ACS_NamedExecuteWithResult) in [wiki]A_JumpIf[/wiki], to call a script that uses [wiki]GameType[/wiki].

Actor ManaSpawner : CustomInventory
{
  Inventory.PickupSound "misc/p_pkup"
  States
  {
  Spawn:
    MAN1 A 1 NoDelay {
						If(GameType () != GAME_SINGLE_PLAYER)
						{
							Return State("MPSpawn");
						}
						Else
						{
							Return State("");
						}
					}
	MAN1 A 1 A_JumpIf(CheckClass("FighterPlayer",AAPTR_PLAYER1), "SpawnMana2")
  SpawnLoop:
	MAN1 A 1
    Loop
  SpawnMana2:
	MAN2 A 1
	Loop
  MPSpawn:
	MAN3 A 1
	Loop
  PickUp:
	TNT1 A 1 ACS_NamedExecuteAlways("AmmoSpawner1")
	Stop
  }
}

Pretty much the same as the acs [url=http://zdoom.org/wiki/GameType]GameType[/url], unless this is already possible and i'm just being dump :P .

This could allow actors to do different stuff for multiplayer games, an example:
[code]
Actor ManaSpawner : CustomInventory
{
Inventory.PickupSound "misc/p_pkup"
States
{
Spawn:
MAN1 A 1 NoDelay {
If(GameType () != GAME_SINGLE_PLAYER)
{
Return State("MPSpawn");
}
Else
{
Return State("");
}
}
MAN1 A 1 A_JumpIf(CheckClass("FighterPlayer",AAPTR_PLAYER1), "SpawnMana2")
SpawnLoop:
MAN1 A 1
Loop
SpawnMana2:
MAN2 A 1
Loop
MPSpawn:
MAN3 A 1
Loop
PickUp:
TNT1 A 1 ACS_NamedExecuteAlways("AmmoSpawner1")
Stop
}
}
[/code]

This haphazradly written actor jumps to a different state depending on player 1, but they all run the same script to give ammo based on the player that picks it up (Cleric and Mage get Blue Mana, Fighter gets Green Mana), with the GameType check it would first jump to a MPSpawn state, which would allow a different sprite, pretty much simplifying what Samsara already does, for example.

I'm sure there are other uses, like a monster or friendly monster acting differently depending on the gametype, custom boss monsters accounting for the possibility of multiple players to do different attacks and such.

I hope this is possible.