0000927: ZDaemon ACSF Functions

Notes
(0004019) Torr Samaho (administrator) 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 (administrator) 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 (administrator) 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 (administrator) 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 (administrator) 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 (developer) 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 (administrator) 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 (administrator) 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 (developer) 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 (administrator) 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 (developer) 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 (administrator) 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 (developer) 2012-07-22 13:30	I myself thought to include TEAM_NumTeams but let it ignore the "team" argument.

(0004040) Torr Samaho (administrator) 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 (developer) 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 (administrator) 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 (developer) 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 (developer) 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 (administrator) 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 (developer) 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 (administrator) 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 (developer) 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 (administrator) 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 (developer) 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 (administrator) 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 (developer) 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 (administrator) 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 (developer) 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 (administrator) 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 (developer) 2012-08-04 10:01	Changes merged to a new head.

(0004242) Torr Samaho (administrator) 2012-08-04 19:22	Thanks! Pulled.

(0004245) Dusk (developer) 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 (developer) 2012-08-04 21:16	Is there a build I can try this on?

(0004261) Torr Samaho (administrator) 2012-08-05 09:57	Here you go.

(0004785) Watermelon (developer) 2012-09-23 21:04	Should any of these be clientside or all on the server side?

(0004786) Dusk (developer) 2012-09-23 21:53	All but TPROP_ReturnTics and Assister should work in client-side scripts.

(0005739) Torr Samaho (administrator) 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.

This issue is already marked as resolved. If you feel that is not the case, please reopen it and explain why.
Supporters:	ZzZombo Disguise Watermelon
Opponents:	No one explicitly opposes this issue yet.

Issue History
Date Modified	Username	Field	Change
2012-07-17 21:51	Blzut3	New Issue
2012-07-21 18:34	Torr Samaho	Note Added: 0004019
2012-07-21 18:35	Torr Samaho	Note Edited: 0004019	View Revisions
2012-07-21 18:35	Torr Samaho	Assigned To	=> Torr Samaho
2012-07-21 18:35	Torr Samaho	Status	new => assigned
2012-07-21 18:35	Torr Samaho	Note Revision Dropped: 4019: 0002180
2012-07-21 20:07	Blzut3	Note Added: 0004020
2012-07-21 20:18	Torr Samaho	Note Added: 0004021
2012-07-21 20:25	Blzut3	Note Added: 0004022
2012-07-21 20:56	Torr Samaho	Note Added: 0004023
2012-07-22 00:26	Dusk	Note Added: 0004024
2012-07-22 00:28	Dusk	Note Edited: 0004024	View Revisions
2012-07-22 03:14	Blzut3	Note Added: 0004026
2012-07-22 09:00	Torr Samaho	Note Added: 0004028
2012-07-22 09:01	Torr Samaho	Assigned To	Torr Samaho => Dusk
2012-07-22 10:45	Torr Samaho	Note Edited: 0004028	View Revisions
2012-07-22 11:42	Dusk	Note Added: 0004032
2012-07-22 11:50	Torr Samaho	Note Added: 0004033
2012-07-22 12:39	Dusk	Note Added: 0004035
2012-07-22 12:44	Dusk	Note Edited: 0004035	View Revisions
2012-07-22 12:45	Torr Samaho	Note Added: 0004036
2012-07-22 13:30	Dusk	Note Added: 0004038
2012-07-22 14:10	Torr Samaho	Note Added: 0004040
2012-07-22 14:18	Dusk	Note Added: 0004041
2012-07-22 14:21	Dusk	Note Edited: 0004041	View Revisions
2012-07-22 14:22	Dusk	Note Edited: 0004041	View Revisions
2012-07-22 14:23	Dusk	Note Edited: 0004041	View Revisions
2012-07-22 14:23	Dusk	Note Edited: 0004041	View Revisions
2012-07-22 14:24	Dusk	Note Edited: 0004041	View Revisions
2012-07-22 14:24	Dusk	Note Edited: 0004041	View Revisions
2012-07-22 14:31	Dusk	Note Edited: 0004041	View Revisions
2012-07-22 16:22	Blzut3	Note Added: 0004042
2012-07-22 16:34	Watermelon	Note Added: 0004043
2012-07-22 16:36	Watermelon	Note Edited: 0004043	View Revisions
2012-07-22 17:11	Dusk	Note Added: 0004044
2012-07-22 17:14	Dusk	Note Edited: 0004044	View Revisions
2012-07-22 17:14	Dusk	Note Edited: 0004044	View Revisions
2012-07-22 17:16	Dusk	Note Edited: 0004044	View Revisions
2012-07-22 18:22	Dusk	Note Edited: 0004044	View Revisions
2012-07-22 18:46	Torr Samaho	Note Added: 0004050
2012-07-22 19:02	Dusk	Note Added: 0004051
2012-07-22 19:27	Dusk	Note Edited: 0004051	View Revisions
2012-07-22 20:00	Dusk	Note Edited: 0004051	View Revisions
2012-07-22 20:00	Dusk	Note Edited: 0004051	View Revisions
2012-07-22 20:31	Dusk	Note Edited: 0004051	View Revisions
2012-07-22 20:42	Dusk	Note Edited: 0004051	View Revisions
2012-07-27 06:21	Torr Samaho	Note Added: 0004093
2012-07-27 06:22	Torr Samaho	Note Edited: 0004093	View Revisions
2012-07-27 06:23	Torr Samaho	Note Edited: 0004093	View Revisions
2012-07-27 10:45	Dusk	Note Added: 0004098
2012-07-27 10:47	Dusk	Note Edited: 0004098	View Revisions
2012-07-27 17:38	Torr Samaho	Note Added: 0004105
2012-07-30 22:25	Dusk	Note Added: 0004153
2012-07-30 22:25	Dusk	Note Edited: 0004153	View Revisions
2012-07-30 22:28	Dusk	Note Edited: 0004153	View Revisions
2012-07-30 22:51	Dusk	Note Edited: 0004153	View Revisions
2012-07-30 22:52	Dusk	Note Edited: 0004153	View Revisions
2012-07-30 22:53	Dusk	Note Edited: 0004153	View Revisions
2012-07-30 22:54	Dusk	Note Edited: 0004153	View Revisions
2012-07-30 22:55	Dusk	Note Edited: 0004153	View Revisions
2012-07-31 20:30	Torr Samaho	Note Added: 0004171
2012-08-02 13:35	Dusk	Note Added: 0004192
2012-08-02 13:36	Dusk	Note Edited: 0004192	View Revisions
2012-08-02 20:04	Torr Samaho	Note Added: 0004211
2012-08-03 00:42	Dusk	Note Added: 0004217
2012-08-03 00:48	Dusk	Relationship added	related to 0000941
2012-08-03 05:43	Torr Samaho	Note Added: 0004227
2012-08-04 10:01	Dusk	Note Added: 0004241
2012-08-04 10:09	Dusk	Status	assigned => needs review
2012-08-04 19:22	Torr Samaho	Note Added: 0004242
2012-08-04 19:22	Torr Samaho	Status	needs review => needs testing
2012-08-04 20:40	Dusk	Note Added: 0004245
2012-08-04 20:40	Dusk	Note Edited: 0004245	View Revisions
2012-08-04 20:41	Dusk	Note Edited: 0004245	View Revisions
2012-08-04 20:56	Dusk	Note Edited: 0004245	View Revisions
2012-08-04 20:57	Dusk	Note Edited: 0004245	View Revisions
2012-08-04 21:03	Dusk	Note Edited: 0004245	View Revisions
2012-08-04 21:16	Watermelon	Note Added: 0004246
2012-08-05 09:57	Torr Samaho	Note Added: 0004261
2012-09-23 21:04	Watermelon	Note Added: 0004785
2012-09-23 21:53	Dusk	Note Added: 0004786
2013-01-12 20:22	Torr Samaho	Note Added: 0005739
2013-01-12 20:23	Torr Samaho	Status	needs testing => resolved
2013-01-12 20:23	Torr Samaho	Resolution	open => fixed
2013-01-12 20:23	Torr Samaho	Fixed in Version	=> 1.0
2013-06-30 20:46	Dusk	Relationship added	parent of 0000366
2018-09-30 19:51	Blzut3	Status	resolved => closed