2026-10-07 16:27 UTC

View Issue Details [ Jump to Notes ]
IDProjectCategoryView StatusLast Update
0004122Zandronum[All Projects] Suggestionpublic2026-09-20 14:57
ReporterTrillster 
Assigned ToKaminsky 
PrioritynormalSeverityminorReproducibilityalways
StatusresolvedResolutionfixed 
Product Version3.1 
Target Version3.2Fixed in Version3.2.1 
Summary0004122: SetPlayerSkin and skin related functions
DescriptionMega Man 8-Bit Deathmatch uses ConsoleCommand for `skin` in its offline campaign skin selector. ConsoleCommand has also been used in that way for many mods in online situations (TF2-esque Spy classes), so there is a definite interest in being able to manipulate this on players.

In addition, there has been interest in being able to retrieve the name of a player's current skin to compare it to some known string. Currently, we can only get an ID which is variable to change when more skins are loaded, which makes checking it very tricky.

Additionally, some function(s) to get a list of current loaded skins would be helpful as well, perhaps designed in the same way as GetMapRotationInfo. We could use this to expand our skin selector to support custom skins then.
Attached Files

-Relationships
child of 0001070newDusk Phasing out the dangerous ConsoleCommand for various additional/improved ACS commands 
+Relationships

-Notes
Kaminsky

~0023085

Kaminsky (developer)

I created a merge request that adds new ACS functions to set and get a player's skin by name: https://foss.heptapod.net/zandronum/zandronum-stable/-/merge_requests/33
Kaminsky

~0023086

Kaminsky (developer)

The merge request got approved and these commits got pushed:

- https://foss.heptapod.net/zandronum/zandronum-stable/-/commit/40d2ac7592d92c9cd787e28e99a6bc36eb557ddb
- https://foss.heptapod.net/zandronum/zandronum-stable/-/commit/6c3e59d01b2ef4d0619f4e1603479f7c152f9487
Trillster

~0023088

Trillster (reporter)

Last edited: 2024-02-26 00:43

View 2 revisions

Although out of the scope of phasing out ConsoleCommand, I do still think some sort of GetMapRotationInfo-esque function would pair quite nicely with these two new functions.

It would help out MM8BDM's custom skin selector in particular to be able to get a list and count of skins that are valid for the player's current class and maybe even details for each skin such as its face icon. This can technically be accomplished with LumpOpen already, but it's a rather tedious implementation.

That aside, below are some notes regarding the new functions.

GetPlayerSkin
- If called in a CLIENTSIDE script, it won't respect the client's `cl_skins` value.
- If called in either CLIENTSIDE or non-CLIENTSIDE scripts, it won't respect the behavior of the +NOSKIN actor flag.
-- Note that `weapon.preferredskin` and SetPlayerSkin take precedence over +NOSKIN (which is preferable behavior!) so GetPlayerSkin as a result should return any forced skins via these means, but in the instance of those not being in play, it should just display "Base".

I'd much appreciate if these kinks could be worked out, because I think this function is most useful in CLIENTSIDE contexts, for example, to change visual effects depending on the skin that players are using, so it should respect which skins the client has enabled via console variable.

SetPlayerSkin
- SetPlayerSkin is capable of setting skins which the server does not have.
-- This can cause incorrect results with GetPlayerSkin when combined with the overrideWeaponSkin parameter. If you force the skin to a skin that the server does not own, the weapon skin will be the "visible" skin despite clients with the skin seeing the forced skin.
- Similar behavior can happen in the opposite situation of a server having an optional wad skin that the client does not have.
-- If the client is forced to be a skin that they do not own via SetPlayerSkin, their `weapon.preferredskin` skin will show on their end, despite the visible skin being the skin they don't own.

Those notes aside, I think this SetPlayerSkin behavior is good enough, since I worry that a more "accurate" approach of using "Base" if the context isn't aware of the skin would make the function worse to use overall.

Kaminsky

~0023286

Kaminsky (developer)

Thanks for the valuable feedback! I created a new MR to address your points on "GetPlayerSkin": https://foss.heptapod.net/zandronum/zandronum-stable/-/merge_requests/38

This change should ensure that "Base" gets returned if a player's skins is disabled by the client's "cl_skins" CVar or if a player's class has the +NOSKIN actor flag enabled.

Also, regarding "SetPlayerSkin": I also think keeping the current behaviour is the best way to go. The server and client(s) can load different skins, some of which the other might not have, so it's not necessarily "incorrect" if the function is used to change the player's skin to something that only one or the other might see. There's no guarantee that "GetPlayerSkin" returns the same result for the server and every client either.
Ru5tK1ng

~0023297

Ru5tK1ng (updater)

Topic was merged: https://foss.heptapod.net/zandronum/zandronum-stable/-/commit/586b83c52c811643cfc860e175e1b5d6c6699714
BarrelsOFun

~0023317

BarrelsOFun (reporter)

Last edited: 2024-03-10 06:07

View 6 revisions

Building off of the idea of being able to get a skin's face Icon, a 'GetSkinInfo' would probably be better, as it would also allow function for parameters that are otherwise unused in SKININFO such as 'color' and potentially allow for custom parameters.

Preferably it would use GetPlayerSkin or Skin Name/Number outright (such as from an array of all of the skins) as the first argument, and the desired parameter for the second.

ex: GetSkinInfo(GetPlayerSkin(0,GETPLAYERSKIN_VISIBLE),"face")
or GetSkinInfo(MaxSkins[i],"author")

Kaminsky

~0024238

Kaminsky (developer)

This commit added the GetSkinProperty ACS function to Zandronum (and also changed GetPlayerSkin to return the skin's index instead of its name): https://foss.heptapod.net/zandronum/zandronum-stable/-/commit/f7ca3ef19212393f77bd50c1518e9d132f3a6931

Support for custom skin properties that can be retrieved with the new function were also added here: https://foss.heptapod.net/zandronum/zandronum-stable/-/commit/7304a396a2888c76b0ad9b3482fba1a45187c8bb
BinaryCode

~0024778

BinaryCode (reporter)

These functions worked fine from testing. Surprised this isn’t closed already lmao
+Notes

-Issue History
Date Modified Username Field Change
2023-04-05 13:29 Trillster New Issue
2023-04-05 13:46 WaTaKiD Relationship added child of 0001070
2024-02-25 21:13 Kaminsky Note Added: 0023085
2024-02-25 21:13 Kaminsky Assigned To => Kaminsky
2024-02-25 21:13 Kaminsky Status new => needs review
2024-02-25 21:13 Kaminsky Target Version => 3.2
2024-02-25 23:03 Kaminsky Note Added: 0023086
2024-02-25 23:03 Kaminsky Status needs review => needs testing
2024-02-26 00:41 Trillster Note Added: 0023088
2024-02-26 00:43 Trillster Note Edited: 0023088 View Revisions
2024-02-29 20:20 Ru5tK1ng Status needs testing => feedback
2024-03-03 06:37 Kaminsky Note Added: 0023286
2024-03-03 06:37 Kaminsky Status feedback => needs review
2024-03-03 22:25 Ru5tK1ng Note Added: 0023297
2024-03-03 22:25 Ru5tK1ng Status needs review => needs testing
2024-03-09 08:15 BarrelsOFun Note Added: 0023317
2024-03-09 08:17 BarrelsOFun Note Edited: 0023317 View Revisions
2024-03-09 08:20 BarrelsOFun Note Edited: 0023317 View Revisions
2024-03-09 22:34 BarrelsOFun Note Edited: 0023317 View Revisions
2024-03-09 22:34 BarrelsOFun Note Edited: 0023317 View Revisions
2024-03-10 06:07 BarrelsOFun Note Edited: 0023317 View Revisions
2025-03-06 13:42 Kaminsky Note Added: 0024238
2026-09-15 17:20 BinaryCode Note Added: 0024778
2026-09-20 14:57 Kaminsky Status needs testing => resolved
2026-09-20 14:57 Kaminsky Resolution open => fixed
2026-09-20 14:57 Kaminsky Fixed in Version => 3.2.1
+Issue History