MantisBT - Zandronum
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0000927Zandronum[All Projects] Suggestionpublic2012-07-17 21:512018-09-30 19:51
ReporterBlzut3 
Assigned ToDusk 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version1.0 
Summary0000927: ZDaemon ACSF Functions
DescriptionA few days ago I saw this commit over at ZDoom:'http://zdoom.org/Changelog/3757/files [^]'

Apparently ZDaemon added ACSF_ functions for GetTeamScore and SetTeamScore. The former would be useful as current Zandronum only has GetTeamScore as an instruction which conflicts with newer ZDoom instructions.
Steps To Reproduce
Additional InformationI can't find any information about the functions anywhere on ZDaemon.org except for a post (http://forums.zdaemon.org/viewtopic.php?p=253106&sid=37eaf3c33cb1a96ce28c4506310973d4#253106) which seems to indicate what the arguments should be.

SetTeamScore (team, value)
GetTeamScore (team)
TagsNo tags attached.
Relationships
parent of 0000366closed  new CLIENTSIDE ACS type 
related to 0000941closed  Access player points (from CTF) with ACS 
Attached Files
Issue History
Date ModifiedUsernameFieldChange
2012-07-17 21:51Blzut3New Issue
2012-07-21 18:34Torr SamahoNote Added: 0004019
2012-07-21 18:35Torr SamahoNote Edited: 0004019bug_revision_view_page.php?bugnote_id=4019#r2181
2012-07-21 18:35Torr SamahoAssigned To => Torr Samaho
2012-07-21 18:35Torr SamahoStatusnew => assigned
2012-07-21 18:35Torr SamahoNote Revision Dropped: 4019: 0002180
2012-07-21 20:07Blzut3Note Added: 0004020
2012-07-21 20:18Torr SamahoNote Added: 0004021
2012-07-21 20:25Blzut3Note Added: 0004022
2012-07-21 20:56Torr SamahoNote Added: 0004023
2012-07-22 00:26DuskNote Added: 0004024
2012-07-22 00:28DuskNote Edited: 0004024bug_revision_view_page.php?bugnote_id=4024#r2183
2012-07-22 03:14Blzut3Note Added: 0004026
2012-07-22 09:00Torr SamahoNote Added: 0004028
2012-07-22 09:01Torr SamahoAssigned ToTorr Samaho => Dusk
2012-07-22 10:45Torr SamahoNote Edited: 0004028bug_revision_view_page.php?bugnote_id=4028#r2185
2012-07-22 11:42DuskNote Added: 0004032
2012-07-22 11:50Torr SamahoNote Added: 0004033
2012-07-22 12:39DuskNote Added: 0004035
2012-07-22 12:44DuskNote Edited: 0004035bug_revision_view_page.php?bugnote_id=4035#r2187
2012-07-22 12:45Torr SamahoNote Added: 0004036
2012-07-22 13:30DuskNote Added: 0004038
2012-07-22 14:10Torr SamahoNote Added: 0004040
2012-07-22 14:18DuskNote Added: 0004041
2012-07-22 14:21DuskNote Edited: 0004041bug_revision_view_page.php?bugnote_id=4041#r2191
2012-07-22 14:22DuskNote Edited: 0004041bug_revision_view_page.php?bugnote_id=4041#r2192
2012-07-22 14:23DuskNote Edited: 0004041bug_revision_view_page.php?bugnote_id=4041#r2193
2012-07-22 14:23DuskNote Edited: 0004041bug_revision_view_page.php?bugnote_id=4041#r2194
2012-07-22 14:24DuskNote Edited: 0004041bug_revision_view_page.php?bugnote_id=4041#r2195
2012-07-22 14:24DuskNote Edited: 0004041bug_revision_view_page.php?bugnote_id=4041#r2196
2012-07-22 14:31DuskNote Edited: 0004041bug_revision_view_page.php?bugnote_id=4041#r2197
2012-07-22 16:22Blzut3Note Added: 0004042
2012-07-22 16:34WatermelonNote Added: 0004043
2012-07-22 16:36WatermelonNote Edited: 0004043bug_revision_view_page.php?bugnote_id=4043#r2199
2012-07-22 17:11DuskNote Added: 0004044
2012-07-22 17:14DuskNote Edited: 0004044bug_revision_view_page.php?bugnote_id=4044#r2201
2012-07-22 17:14DuskNote Edited: 0004044bug_revision_view_page.php?bugnote_id=4044#r2202
2012-07-22 17:16DuskNote Edited: 0004044bug_revision_view_page.php?bugnote_id=4044#r2203
2012-07-22 18:22DuskNote Edited: 0004044bug_revision_view_page.php?bugnote_id=4044#r2204
2012-07-22 18:46Torr SamahoNote Added: 0004050
2012-07-22 19:02DuskNote Added: 0004051
2012-07-22 19:27DuskNote Edited: 0004051bug_revision_view_page.php?bugnote_id=4051#r2206
2012-07-22 20:00DuskNote Edited: 0004051bug_revision_view_page.php?bugnote_id=4051#r2207
2012-07-22 20:00DuskNote Edited: 0004051bug_revision_view_page.php?bugnote_id=4051#r2208
2012-07-22 20:31DuskNote Edited: 0004051bug_revision_view_page.php?bugnote_id=4051#r2209
2012-07-22 20:42DuskNote Edited: 0004051bug_revision_view_page.php?bugnote_id=4051#r2210
2012-07-27 06:21Torr SamahoNote Added: 0004093
2012-07-27 06:22Torr SamahoNote Edited: 0004093bug_revision_view_page.php?bugnote_id=4093#r2230
2012-07-27 06:23Torr SamahoNote Edited: 0004093bug_revision_view_page.php?bugnote_id=4093#r2231
2012-07-27 10:45DuskNote Added: 0004098
2012-07-27 10:47DuskNote Edited: 0004098bug_revision_view_page.php?bugnote_id=4098#r2235
2012-07-27 17:38Torr SamahoNote Added: 0004105
2012-07-30 22:25DuskNote Added: 0004153
2012-07-30 22:25DuskNote Edited: 0004153bug_revision_view_page.php?bugnote_id=4153#r2258
2012-07-30 22:28DuskNote Edited: 0004153bug_revision_view_page.php?bugnote_id=4153#r2259
2012-07-30 22:51DuskNote Edited: 0004153bug_revision_view_page.php?bugnote_id=4153#r2260
2012-07-30 22:52DuskNote Edited: 0004153bug_revision_view_page.php?bugnote_id=4153#r2261
2012-07-30 22:53DuskNote Edited: 0004153bug_revision_view_page.php?bugnote_id=4153#r2262
2012-07-30 22:54DuskNote Edited: 0004153bug_revision_view_page.php?bugnote_id=4153#r2263
2012-07-30 22:55DuskNote Edited: 0004153bug_revision_view_page.php?bugnote_id=4153#r2264
2012-07-31 20:30Torr SamahoNote Added: 0004171
2012-08-02 13:35DuskNote Added: 0004192
2012-08-02 13:36DuskNote Edited: 0004192bug_revision_view_page.php?bugnote_id=4192#r2299
2012-08-02 20:04Torr SamahoNote Added: 0004211
2012-08-03 00:42DuskNote Added: 0004217
2012-08-03 00:48DuskRelationship addedrelated to 0000941
2012-08-03 05:43Torr SamahoNote Added: 0004227
2012-08-04 10:01DuskNote Added: 0004241
2012-08-04 10:09DuskStatusassigned => needs review
2012-08-04 19:22Torr SamahoNote Added: 0004242
2012-08-04 19:22Torr SamahoStatusneeds review => needs testing
2012-08-04 20:40DuskNote Added: 0004245
2012-08-04 20:40DuskNote Edited: 0004245bug_revision_view_page.php?bugnote_id=4245#r2329
2012-08-04 20:41DuskNote Edited: 0004245bug_revision_view_page.php?bugnote_id=4245#r2330
2012-08-04 20:56DuskNote Edited: 0004245bug_revision_view_page.php?bugnote_id=4245#r2331
2012-08-04 20:57DuskNote Edited: 0004245bug_revision_view_page.php?bugnote_id=4245#r2332
2012-08-04 21:03DuskNote Edited: 0004245bug_revision_view_page.php?bugnote_id=4245#r2333
2012-08-04 21:16WatermelonNote Added: 0004246
2012-08-05 09:57Torr SamahoNote Added: 0004261
2012-09-23 21:04WatermelonNote Added: 0004785
2012-09-23 21:53DuskNote Added: 0004786
2013-01-12 20:22Torr SamahoNote Added: 0005739
2013-01-12 20:23Torr SamahoStatusneeds testing => resolved
2013-01-12 20:23Torr SamahoResolutionopen => fixed
2013-01-12 20:23Torr SamahoFixed in Version => 1.0
2013-06-30 20:46DuskRelationship addedparent of 0000366
2018-09-30 19:51Blzut3Statusresolved => closed

Notes
(0004019)
Torr Samaho   
2012-07-21 18:34   
(edited on: 2012-07-21 18:35)
I'll convert Zandronum's GETTEAMSCORE to ACSF and use the ACSF_GetTeamScore number from ZDoom for it. Since Zandronum's function was never really documented and had its number changed multiple times, this shouldn't break any mods.

BTW: Do we even need GETTEAMPLAYERCOUNT? It is also incompatible with ZDoom and should either be removed or converted to ACSF.
(0004020)
Blzut3   
2012-07-21 20:07   
Regarding GetTeamPlayerCount, I think it would be better converted to something along the lines of GetPlayerInfo. While I can't think of anything else the function could return at the moment, I do think such a function would be better in the long run.

In any case the function itself is useful since right now I think it's only possible to get the number of players on the blue and red team and I know the Overload mod has a part that says "we can only do this if there are two teams."
(0004021)
Torr Samaho   
2012-07-21 20:18   
Can't GetTeamPlayerCount be easily implemented in ACS using a loop over all players and GetPlayerInfo to get and compare the team of each player to a given one while doing the counting accordingly? A built-in function would be more convenient though.
(0004022)
Blzut3   
2012-07-21 20:25   
Good point. One possible complication there is that it would require the mod to assume a certain maximum number of players (which another ticket indicates may be bumped to 255). Getting around that with a GetMaximumPlayers() function or similar wouldn't really help since most uses for the maximum number of players is in array sizes.
(0004023)
Torr Samaho   
2012-07-21 20:56   
Since the code is already there anyway, I won't mind converting it. We just need to settle for a permanent syntax, i.e. what we decide now should not be altered again to stay compatible. What should be the name of the new function? Since we already have a TEAMINFO lump, GetTeamInfo may be misleading. Probably GetTeamProperty or something like this?

Regarding other useful stuff this function could return:
- number of player on a team with lives left (TEAM_CountLivingAndRespawnablePlayers)
- number of available teams (TEAM_GetNumAvailableTeams or TEAM_GetNumTeamsWithStarts)
- is a given team available (TEAM_CheckIfValid or TEAM_ShouldUseTeam)
- score of a team (although GetTeamScore already does this)
(0004024)
Dusk   
2012-07-22 00:26   
(edited on: 2012-07-22 00:28)
why such long names again?
TEAM_NumLivePlayers
TEAM_NumTeams (or TEAM_NumValidTeams)
TEAM_IsValid
TEAM_Score

also
TEAM_TextColor
TEAM_PlayerStartNum (who knows?)
TEAM_FlagItem
TEAM_SkullItem
TEAM_WinnerTheme
TEAM_LoserTheme

I'll go ahead and do this up if you want.
(0004026)
Blzut3   
2012-07-22 03:14   
I don't really think GetTeamInfo would be nearly as confusing as a few other things already in ZDoom (GAMEINFO vs the MAPINFO gameinfo block for example). But GetTeamProperty works for me.

Since some of the properties you mention don't exactly apply to any one specific team I guess the parameter order would be GetTeamProperty(prop[, team]).
(0004028)
Torr Samaho   
2012-07-22 09:00   
(edited on: 2012-07-22 10:45)
Quote from Dusk
why such long names again?

I just quoted the existing internal function names (and you know my habit of using long names ;)) to make clear what exactly the ACS function would return. The ACS property names the users can surely be shortened like you suggested, just don't change the existing internal function names. BTW: In the instances where I listed two function names these functions really behave differently and we need to decide which behavior we want to have or even add both.

Quote from Dusk
I'll go ahead and do this up if you want.

Sure, go for it. While you are at it, I'll add ConsolePlayerNumber(). EDIT: ConsolePlayerNumber() is ready.

Quote from Blzut3
Since some of the properties you mention don't exactly apply to any one specific team I guess the parameter order would be GetTeamProperty(prop[, team]).

GetTeamProperty(prop[, team]) sounds good to me.
(0004032)
Dusk   
2012-07-22 11:42   
I dunno.. only TEAM_NumTeams doesn't need the team value. But if that's what you want I'll do it that way.
(0004033)
Torr Samaho   
2012-07-22 11:50   
Nothing is set in stone yet. If you have a different proposal, just post it here and we'll discuss it.
(0004035)
Dusk   
2012-07-22 12:39   
(edited on: 2012-07-22 12:44)
My concern is this: is there a need to swap the parameter order and thus cause more confusion since this function appears to be akin to GetActorProperty just because one of the properties does not need the team value?

EDIT: Added: TEAM_Spread and TEAM_AssistPlayer as well since they were neatly on a silver plate..
(0004036)
Torr Samaho   
2012-07-22 12:45   
Good point. An alternative to me would be to say that "TEAM_NumTeams" is simply not a team property, remove it from the list and change the syntax to GetTeamProperty(team, prop). How does that sound?
(0004038)
Dusk   
2012-07-22 13:30   
I myself thought to include TEAM_NumTeams but let it ignore the "team" argument.
(0004040)
Torr Samaho   
2012-07-22 14:10   
The more I think about it, the more I'd say that TEAM_NumTeams doesn't really fit with the other properties. That's my purely personal opinion though. Blzut3, what do you think about this? Would also be nice if we could get some community input.
(0004041)
Dusk   
2012-07-22 14:18   
(edited on: 2012-07-22 14:31)
In other news, I got this function working on my end, not committed yet though as I'm running a few more tests. The loadout is:
enum
{
    TPROP_Name = 0,
    TPROP_Score,
    TPROP_IsValid,
    TPROP_NumLivePlayers,
    TPROP_NumTeams,
    TPROP_TextColor,
    TPROP_PlayerStartNum,
    TPROP_Spread,
    TPROP_AssistPlayer,
    TPROP_FragCount,
    TPROP_DeathCount,
    TPROP_ReturnTics,
    TPROP_Carrier,
    TPROP_FlagItem,
    TPROP_SkullItem,
    TPROP_WinnerTheme,
    TPROP_LoserTheme,
};

Using TPROP because TEAM_Score conflicts with the action special with the same name and I couldn't figure a better prefix. Maybe TEAMPROP..?

_Carrier and _AssistPlayer (maybe _CarrierPlayer for consistency?) return -1 if there is none.

_Score returns the effective score of the team. Frags in TeamDM, captures in CTF, wins in LMS.
(0004042)
Blzut3   
2012-07-22 16:22   
I'm fine with either parameter order. In terms of returning the number of teams, it really isn't needed since getcvar can get the value of sv_maxteams which works fine more or less.
(0004043)
Watermelon   
2012-07-22 16:34   
(edited on: 2012-07-22 16:36)
Damnit it ate my post, I'll just message Dusk on this, here are some better options:

TPROP_SpectatorTheme,
TPROP_PointCount, // Would this be like TPROP_Score?
TPROP_NumDeadPlayers,

EDIT:
TPROP_IsValid, // Valid team? relative to sv_maxteams
TPROP_Spread, // What does this return? (1st place - 2nd place)
TPROP_ReturnTics, // Returns?
TPROP_TextColor, // Returns 24 bit value into an int? or a string like 00FF00
(0004044)
Dusk   
2012-07-22 17:11   
(edited on: 2012-07-22 18:22)
Quote
TPROP_SpectatorTheme,

It might be that the default intermission theme already plays for spectators but that's just a hunch, I dunno.

Quote
TPROP_PointCount, // Would this be like TPROP_Score?

TPROP_Score returns the effective score so I believe so more or less.

Quote
TPROP_NumDeadPlayers,

You might be able to use a player team count (GetPlayerInfo (i, PLAYERINFO_TEAM)) with TPROP_NumLivePlayers to achieve this, though I gotta test that.
EDIT: Yeah, should work.

Quote
TPROP_IsValid, // Valid team? relative to sv_maxteams

Not necessarily - if this returns 1 the team is usable. If you have sv_maxteams 3 but no green starts, the green team is not valid

Quote
TPROP_Spread, // What does this return? (1st place - 2nd place)

The spread of the effective score - frag spread in TDM, flag spread in CTF, win spread in LMS.

Quote
TPROP_ReturnTics, // Returns?

How many tics a dropped item lasts until it gets auto-returned. 0 if it's not dropped.

Quote
TPROP_TextColor, // Returns 24 bit value into an int? or a string like 00FF00

It returns a color range, CR_BLUE for blue team for instance. You can use it in the color field in HudMessage.
(0004050)
Torr Samaho   
2012-07-22 18:46   
Dusk, is it possible that you forgot the include the property that made us consider introducing the new function in the first place, i.e. GETTEAMPLAYERCOUNT? ;) At least I don't see this in the list you posted.

BTW: With this and NumDeadPlayers you can calculate NumDeadPlayers easily (and don't need it as extra property or to use a loop with GetPlayerInfo (i, PLAYERINFO_TEAM).
(0004051)
Dusk   
2012-07-22 19:02   
(edited on: 2012-07-22 20:42)
Quote
Dusk, is it possible that you forgot the include the property that made us consider introducing the new function in the first place, i.e. GETTEAMPLAYERCOUNT? ;) At least I don't see this in the list you posted.

/me faints

Added TPROP_NumPlayers.

EDIT: I just thought that with TPROP_IsValid and GetCVar ("sv_maxteams") you can replicate the behavior of TPROP_NumTeams. So I don't think the property is really necessary either.

EDIT.2: OK that's out by now. Anything else before I push this to my repo?
EDIT.3: Committed up, I figured that since I'm gonna end up committing this stuff to a new head anyway, I can safely add/change/remove whatever and commit freely.
EDIT.4: Forgot to mention: I'm thinking about getting this tested in neurosphere before pulling gets to be considered so yeah.
(0004093)
Torr Samaho   
2012-07-27 06:21   
(edited on: 2012-07-27 06:23)
Some comments on the patch:

- TPROP_NumLivePlayers just needs to return TEAM_CountLivingAndRespawnablePlayers ( team ).

- I don't know if we need TPROP_FlagItem and TPROP_SkullItem. We could merge this into TPROP_TeamItem and return flag or skull actor name based on whether the gamemode has GMF_USEFLAGASTEAMITEM.

- TPROP_Score and TPROP_FragCount kinda overlap. If you provide functions to access specific counters (like frags) independently of the gamemode, IMHO you should add them for all counters, i.e. also for TEAM_GetWinCount and TEAM_GetScore (which is not the same as TPROP_Score).

Quote from Dusk
I'm thinking about getting this tested in neurosphere before pulling gets to be considered so yeah.

Good idea.
(0004098)
Dusk   
2012-07-27 10:45   
(edited on: 2012-07-27 10:47)
Hmm.. have TPROP_FragCount, TPROP_WinCount, TPROP_PointCount and TPROP_Score?
The former three return individual score counters while te third one gives the effective score - that is, the score needed to win the game?

Quote
We could merge this into TPROP_TeamItem and return flag or skull actor name based on whether the gamemode has GMF_USEFLAGASTEAMITEM.

Agreed on that..

Quote
Quote from Dusk
I'm thinking about getting this tested in neurosphere before pulling gets to be considered so yeah.

Good idea.

Also provides a good opportunity to test the other stuff that's in there as well..
(0004105)
Torr Samaho   
2012-07-27 17:38   
Quote from Dusk
Hmm.. have TPROP_FragCount, TPROP_WinCount, TPROP_PointCount and TPROP_Score?

Exactly. Either have all of them or just have TPROP_Score. But having TPROP_FragCount without TPROP_WinCount/TPROP_PointCount is inconsistent.
(0004153)
Dusk   
2012-07-30 22:25   
(edited on: 2012-07-30 22:55)
Aight I did some further work on this and ran a bit of online testing with bots (these debug commands sure come in handy since the bots have no clue which direction the flag is in so I can just teleport the team items into their bases)

Anyway: clients do not know return tics and assister player values. Former stays at 525 and doesn't count down, the latter should be known by clients but for some reason TEAM_GetAssistPlayer seems to return garbage. o_O I'm looking further into it right now.

EDIT: Return tics is fixed by letting clients execute TEAM_Tick to countdown the return tics (of course disallowing them from executing any return routines) and it seems to work without any side effects. The result isn't exactly perfect though.. that would be done by sending the level.time with SERVERCOMMANDS_SetReturnTicks and having the client do proper offsetting (realtics = serverreturntics - (clienttime - servertime)) methinks but I don't think it's important especially this close to release.
(0004171)
Torr Samaho   
2012-07-31 20:30   
The new version looks good to me. If you rebase/transplant and collapse the changesets I'll pull them. Would also be nice if you can do some minor cosmetic changes in team.cpp while your are moving the staff to the latest Zandronum changeset: There is a trailing tab in TEAM_GetPlayerStartThingNum and there is a tab between const char* and TEAM_GetItemName. I guess I should try to stop worrying about these minor indentation issues, but they catch me eye immediately each time I look at the diffs in KDiff3...

Regarding the client side problems: For now I'd say we should just live with the fact that some properties don't work on the clients and document this in the wiki.
(0004192)
Dusk   
2012-08-02 13:35   
(edited on: 2012-08-02 13:36)
> If you rebase/transplant and collapse the changesets I'll pull them.
I myself do it by taking the overall diff of the changes and committing them to a new head based on the latest one pulled from Zandronum.

Maybe we should add this function as is but note that returntics and assistplayer doesn't work properly in client-side scripts? That stuff can be fixed later on.
EDIT: heh.. just noted your comment about that
(0004211)
Torr Samaho   
2012-08-02 20:04   
Quote from Dusk
I myself do it by taking the overall diff of the changes and committing them to a new head based on the latest one pulled from Zandronum.

Feel free to use your favorite method to collect all changes in a single changeset that is based on the latest changeset from the Zandronum repo ;). BTW: Please also include a comment in zandronum-history.txt in this changeset.

Quote from Dusk
EDIT: heh.. just noted your comment about that

So we are thinking alike :).
(0004217)
Dusk   
2012-08-03 00:42   
Quote
There is a trailing tab in TEAM_GetPlayerStartThingNum and there is a tab between const char* and TEAM_GetItemName.

Fixed in this changeset, also added changelog entry.

I'll push this to a new head if it's good now.
(0004227)
Torr Samaho   
2012-08-03 05:43   
I think it's good now, so please push it to a new head. It's pretty complicated though to look at a combined diff of all GetTeamProperty related changes (and just those changes) since the corresponding changesets are scattered around your default branch.
(0004241)
Dusk   
2012-08-04 10:01   
Changes merged to a new head.
(0004242)
Torr Samaho   
2012-08-04 19:22   
Thanks! Pulled.
(0004245)
Dusk   
2012-08-04 20:40   
(edited on: 2012-08-04 21:03)
Alright so, for testers: to use this function you need to add:
-103:GetTeamProperty(2),

at the bottom of zspecial.acs, above __EndOfList__.

Into zdefs.acs:
#define TPROP_Name 0
#define TPROP_Score 1
#define TPROP_IsValid 2
#define TPROP_NumPlayers 3
#define TPROP_NumLivePlayers 4
#define TPROP_TextColor 5
#define TPROP_PlayerStartNum 6
#define TPROP_Spread 7
#define TPROP_Carrier 8
#define TPROP_Assister 9
#define TPROP_FragCount 10
#define TPROP_DeathCount 11
#define TPROP_WinCount 12
#define TPROP_PointCount 13
#define TPROP_ReturnTics 14
#define TPROP_TeamItem 15
#define TPROP_WinnerTheme 16
#define TPROP_LoserTheme 17


The function takes the form: GetTeamProperty (team, property), where property is one of the constants defined above.

NOTE: Carrier means the player who carries this team's flag/skull - it refers to an enemy player! Assister means the player who returned this team's flag/skull and is eligible for an assist - refers to a member of this team.

Return tics means the amount of tics before the team's item is automatically returned.

TPROP_Score returns the team's effective score. It's either TPROP_FragCount, TPROP_WinCount or TPROP_PointCount, whichever is needed to win the game. TPROP_Spread returns the spread (amount of score from the leading team) of effective score. TPROP_TextColor returns a color range, you can use this in the color field of HudMessage.

TPROP_TeamItem, TPROP_WinnerTheme and TPROP_LoserTheme are dynamic strings. After a tic, they are destroyed.

TPROP_TeamItem returns the actor name of the team's score item (BlueFlag for the blue team in CTF for instance). TPROP_WinnerTheme and TPROP_LoserTheme return the intermission themes of the team.

TPROP_NumLivePlayers means the amount of players who are either alive or can respawn. It becomes meaningful in LMS modes where one can determine the amount of players left in each team.
(0004246)
Watermelon   
2012-08-04 21:16   
Is there a build I can try this on?
(0004261)
Torr Samaho   
2012-08-05 09:57   
Here you go.
(0004785)
Watermelon   
2012-09-23 21:04   
Should any of these be clientside or all on the server side?
(0004786)
Dusk   
2012-09-23 21:53   
All but TPROP_ReturnTics and Assister should work in client-side scripts.
(0005739)
Torr Samaho   
2013-01-12 20:22   
The discussed ACS functions are included in 1.0, nobody complained that they don't work, so I'm closing this.