MantisBT - Zandronum
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0002645Zandronum[All Projects] Suggestionpublic2016-02-19 06:012016-03-01 04:55
Reporterthrowaway 
Assigned To 
PrioritynormalSeverityfeatureReproducibilityN/A
StatusnewResolutionopen 
PlatformOSOS Version
Product Version3.0-beta 
Target VersionFixed in Version 
Summary0002645: New ACS functions - GetWeaponPWO, GetWeaponHasPWO
DescriptionRight now, getting PWO for a weapon reliably through ACS is impossible, because GetCVar has no way of signalling that a CVar doesn't exist. Plus, checking for each game's PWO CVar is clunky.

How these functions would work:

GetWeaponPWO(str weaponName): Returns the PWO value for the weapon set by the player. If the PWO value doesn't exist, return LONG_MIN.

GetWeaponHasPWO(str weaponName): Returns true if the weapon has a PWO entry, and false otherwise.

This only really needs to work on the client, but if the server knows the PWO values for clients, then I guess it could run on the server too. Doesn't matter too much - the client can always use RequestScriptPuke to send PWO values if necessary.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files? test.pk3 (656) 2016-02-19 07:33
/tracker/file_download.php?file_id=1748&type=bug
Issue History
Date ModifiedUsernameFieldChange
2016-02-19 06:01throwawayNew Issue
2016-02-19 06:17throwawayNote Added: 0014454
2016-02-19 07:14throwawayNote Added: 0014456
2016-02-19 07:16throwawayNote Edited: 0014456bug_revision_view_page.php?bugnote_id=14456#r8741
2016-02-19 07:28throwawayNote Added: 0014457
2016-02-19 07:29throwawayNote Edited: 0014457bug_revision_view_page.php?bugnote_id=14457#r8743
2016-02-19 07:31throwawayNote Edited: 0014457bug_revision_view_page.php?bugnote_id=14457#r8744
2016-02-19 07:33throwawayFile Added: test.pk3
2016-02-19 07:33throwawayNote Edited: 0014457bug_revision_view_page.php?bugnote_id=14457#r8745
2016-02-19 07:37throwawayNote Edited: 0014457bug_revision_view_page.php?bugnote_id=14457#r8746
2016-02-19 07:41throwawayNote Edited: 0014457bug_revision_view_page.php?bugnote_id=14457#r8747
2016-02-19 07:52throwawayNote Edited: 0014457bug_revision_view_page.php?bugnote_id=14457#r8748
2016-02-19 08:01throwawayNote Edited: 0014457bug_revision_view_page.php?bugnote_id=14457#r8749
2016-02-19 13:32Edward-sanNote Added: 0014458
2016-02-19 18:10throwawayNote Added: 0014460
2016-02-19 18:14throwawayNote Edited: 0014460bug_revision_view_page.php?bugnote_id=14460#r8751
2016-02-19 19:07DuskNote Added: 0014461
2016-02-19 20:42throwawayNote Added: 0014462
2016-02-19 20:44throwawayNote Edited: 0014462bug_revision_view_page.php?bugnote_id=14462#r8753
2016-02-21 20:16DuskNote Added: 0014468
2016-02-21 20:16DuskStatusnew => feedback
2016-02-22 08:09throwawayNote Added: 0014475
2016-02-22 08:09throwawayStatusfeedback => new
2016-02-22 08:14throwawayNote Edited: 0014475bug_revision_view_page.php?bugnote_id=14475#r8758
2016-03-01 04:55StrikerMan780Note Added: 0014520

Notes
(0014454)
throwaway   
2016-02-19 06:17   
Y'know what, hell with it. I'll take a crack at it myself.
(0014456)
throwaway   
2016-02-19 07:14   
(edited on: 2016-02-19 07:16)
Actually, I just noticed that ORDERDEF got removed. Does that remove the need for GetWeaponHasPWO, or are there any edge cases where Zandronum wouldn't have a PWO value for a weapon?

edit: Never mind that question: KEYCONF-defined weapons don't have PWO entries.
(0014457)
throwaway   
2016-02-19 07:28   
(edited on: 2016-02-19 08:01)
Well that was easy enough to add.

Instead of returning LONG_MIN on an unknown weapon for PWO, however, GetWeaponPWO just returns 0, because meh.

Non-weapons return 0 in both functions - didn't even have to do anything special for them.

'https://gist.github.com/anonymous/ae788f2b290ca81dd0e0 [^]'

This is what I added to zspecial.acs:

    -130:GetWeaponPWO(1),
    -131:GetWeaponHasPWO(1),

And I'll upload a test PK3 I used to see if this works. (edit again: done, see test.pk3)

This only works when running on a client (or in single player, obviously), though - it just reports the server's PWO definitions if run serverside, and I'd rather not figure out how to sync that stuff from the client to the server.

Also I'm sure it returns whatever the host's PWO values are if run for bots, but what else would be done in that case? Always return 0 in GetWeaponPWO?
(0014458)
Edward-san   
2016-02-19 13:32   
Why do you need the PWO info in ACS?
(0014460)
throwaway   
2016-02-19 18:10   
(edited on: 2016-02-19 18:14)
I need it to accurately replicate the switchonpickup CVar with my pickup system. It doesn't handle switchonpickup 1 too elegantly (it stores all the SelectionOrder values in a big array), but it works. There's currently no way to replicate switchonpickup 3, but those two functions make it possible.

And GetWeaponHasPWO is needed to replicate pwo_switchtounknown.

Also, I can see uses for it with ACS HUDs, namely keeping weapons in order on it.
(0014461)
Dusk   
2016-02-19 19:07   
Perhaps we need a CheckWeaponSwitch(str class) function then, to test whether the player would switch to a weapon if he picked it up.

Of course this in turn begs the question, why would you need that?
(0014462)
throwaway   
2016-02-19 20:42   
(edited on: 2016-02-19 20:44)
That is incredibly specific, and therefore would only get used in the "doing weapon pickup in ACS" scenario.

As for why the weapon pickup is done in ACS, it's because the pickup varies its behaviour (item given from pickup, pickup message (if any), states displayed) depending on the pickup class of the player/client viewing the pickup. Like Samsara's system, but more generalized.
(0014468)
Dusk   
2016-02-21 20:16   
So essentially you'd like to change the item's pickup behavior. Can't you do exactly that with CustomInventory? Why do you need ACS at all here?
(0014475)
throwaway   
2016-02-22 08:09   
(edited on: 2016-02-22 08:14)
CustomInventory alone can't change the pickup message convincingly (you can't check msg0color in DECORATE, which is needed to make the pickup message the right color - replacing all "\c-" with the right color code is needed too), and definitely can't handle dynamic pickup messages. It can't handle CVars like sv_weaponstay. It can't use data like the actor's class name (although CheckClass in ZDoom could do this), current weapon held, how many maps you've had a weapon, custom CVars, client settings, or really *any* arbitrary behaviour, to determine exactly what pickup you get.

Dropped items would be significantly more annoying to handle - I couldn't just set a "dropped" variable to true and have the weapon pickup function automatically take away half the ammo. I'd have to do it manually, and manually update it if I change how much ammo, or what ammo, the weapon gives. More pain.

It definitely wouldn't be able to handle the extended health and armor pickup behaviour I added. The armor code lets you simulate things like Quake 2's armor system, lets the equivalent of BasicArmorPickups only give part of its full protection value (which BasicArmorPickup can't do), and lets armor bonuses go either to their max or your armor's max, whichever is higher. The health pickup behaviour lets it easily scale with your max health, and lets you modify how much healing you get based on where your current health count is.

And most importantly, it wouldn't be able to change the way it displays for each client individually. You absolutely need clientside scripts for that - there's no getting around it. And it just so happens that it's a natural extension of the pickup system, since everything needed for the clientside display's handled by the rest of the system.

Plus, this keeps everything in one easy-to-edit place. Even if DECORATE alone could handle all that, you'd have to copy and paste all the necessary code in for every... single... item. And update them all manually if you find a bug in the logic. User variables can't be strings, after all, and actor names are strings, so even with clever use of state jumps that would turn the DECORATE into an unreadable mess, you wouldn't be able to compartmentalize everything.

Only very recently in ZDoom, with the addition of the new state blocks, would it be feasible to implement even the easy half of this pickup system in DECORATE. Even then, you'd still have to copy-paste the blocks everywhere, because DECORATE still has no concept of user-defined functions. The closest it gets is inherited states.

It'd be a development and maintenance nightmare. There is no way in hell I'd do this with just CustomInventory and DECORATE. Making a system that handles everything, then adding entries to a bunch of arrays is much nicer to work with.
(0014520)
StrikerMan780   
2016-03-01 04:55   
Definitely want this. All weapon pickups in my mod use ACS to give the appropriate weapons to different player classes. However, I have to either force weapon switch, or have none at all. (I went with the latter for now).