0002645: New ACS functions - GetWeaponPWO, GetWeaponHasPWO

Notes
(0014454) throwaway (reporter) 2016-02-19 06:17	Y'know what, hell with it. I'll take a crack at it myself.

(0014456) throwaway (reporter) 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 (reporter) 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 (developer) 2016-02-19 13:32	Why do you need the PWO info in ACS?

(0014460) throwaway (reporter) 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 (developer) 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 (reporter) 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 (developer) 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 (reporter) 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 (reporter) 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).

Only registered users can voice their support. Click here to register, or here to log in.
Supporters:	No one explicitly supports this issue yet.
Opponents:	No one explicitly opposes this issue yet.

Issue History
Date Modified	Username	Field	Change
2016-02-19 06:01	throwaway	New Issue
2016-02-19 06:17	throwaway	Note Added: 0014454
2016-02-19 07:14	throwaway	Note Added: 0014456
2016-02-19 07:16	throwaway	Note Edited: 0014456	View Revisions
2016-02-19 07:28	throwaway	Note Added: 0014457
2016-02-19 07:29	throwaway	Note Edited: 0014457	View Revisions
2016-02-19 07:31	throwaway	Note Edited: 0014457	View Revisions
2016-02-19 07:33	throwaway	File Added: test.pk3
2016-02-19 07:33	throwaway	Note Edited: 0014457	View Revisions
2016-02-19 07:37	throwaway	Note Edited: 0014457	View Revisions
2016-02-19 07:41	throwaway	Note Edited: 0014457	View Revisions
2016-02-19 07:52	throwaway	Note Edited: 0014457	View Revisions
2016-02-19 08:01	throwaway	Note Edited: 0014457	View Revisions
2016-02-19 13:32	Edward-san	Note Added: 0014458
2016-02-19 18:10	throwaway	Note Added: 0014460
2016-02-19 18:14	throwaway	Note Edited: 0014460	View Revisions
2016-02-19 19:07	Dusk	Note Added: 0014461
2016-02-19 20:42	throwaway	Note Added: 0014462
2016-02-19 20:44	throwaway	Note Edited: 0014462	View Revisions
2016-02-21 20:16	Dusk	Note Added: 0014468
2016-02-21 20:16	Dusk	Status	new => feedback
2016-02-22 08:09	throwaway	Note Added: 0014475
2016-02-22 08:09	throwaway	Status	feedback => new
2016-02-22 08:14	throwaway	Note Edited: 0014475	View Revisions
2016-03-01 04:55	StrikerMan780	Note Added: 0014520

Relationships