MantisBT - Zandronum |
| View Issue Details |
|
| ID | Project | Category | View Status | Date Submitted | Last Update |
| 0001797 | Zandronum | [All Projects] Bug | public | 2014-05-07 05:10 | 2015-11-29 22:14 |
|
| Reporter | TerminusEst13 | |
| Assigned To | | |
| Priority | normal | Severity | minor | Reproducibility | always |
| Status | confirmed | Resolution | backport later | |
| Platform | Microsoft | OS | Windows | OS Version | 98/ME |
| Product Version | 1.2 | |
| Target Version | | Fixed in Version | | |
|
| Summary | 0001797: Weapons replaced with CustomInventory items do not respect sv_noweaponspawn and always show in Multiplayer spawns. |
| Description | See topic.
For mods which replace the weapon pickups with CustomInventory items to give a minor amount of scripting for their pickups, this effectively renders sv_noweaponspawn useless. Whether or not the flag is disabled or enabled, the Multiplayer weapon spawns set by the map are always triggered.
For earlier maps, like Doom 2/Heretic/etc, this is kind of an annoying thing since it effectively gives players a full loadout upon entering map02, rendering the rest of the early mapset trivial. The only option available is sv_coop_spactorspawn, which removes extra monsters from the equation and still makes things pretty trivial.
Perhaps a +RESPECTMULTIPLAYERSPAWN flag for Custom Inventory that checks to see if the spawn has a Multiplayer flag attached? |
| Steps To Reproduce | 1: Host a Doom 2 server with a mod that replaces weapon spawns with CustomInventory. (Examples: Samsara or Cyberrunner)
2: Enable sv_noweaponspawn
3: Marvel at how Map01 is still chock full of weapons. |
| Additional Information | |
| Tags | No tags attached. |
| Relationships | | has duplicate | 0002405 | closed | | Weapons replaced by CustomInventories don't respect "Don't spawn multiplayer weapons in coop games" flag |
|
| Attached Files |  Screenshot_Doom_20140507_010947.png (226,972) 2014-05-07 05:10
https://zandronum.com/tracker/file_download.php?file_id=1208&type=bug
|
|
| Issue History |
| Date Modified | Username | Field | Change |
| 2014-05-07 05:10 | TerminusEst13 | New Issue | |
| 2014-05-07 05:10 | TerminusEst13 | File Added: Screenshot_Doom_20140507_010947.png | |
| 2014-05-07 18:02 | jam | Note Added: 0008733 | |
| 2014-05-07 20:50 | jam | Note Edited: 0008733 | bug_revision_view_page.php?bugnote_id=8733#r4722 |
| 2014-05-07 21:02 | jam | Note Edited: 0008733 | bug_revision_view_page.php?bugnote_id=8733#r4723 |
| 2014-05-07 21:03 | jam | Note Edited: 0008733 | bug_revision_view_page.php?bugnote_id=8733#r4724 |
| 2014-05-07 22:13 | TerminusEst13 | Note Added: 0008735 | |
| 2014-05-09 14:26 | jam | Note Added: 0008756 | |
| 2014-05-09 14:26 | jam | Note Edited: 0008756 | bug_revision_view_page.php?rev_id=4744 |
| 2014-05-09 14:27 | jam | Note Deleted: 0008756 | |
| 2014-05-09 14:27 | jam | Note Added: 0008757 | |
| 2014-06-15 16:35 | Watermelon | Note Added: 0009452 | |
| 2014-06-15 16:35 | Watermelon | Status | new => feedback |
| 2014-07-20 11:31 | ZzZombo | Note Added: 0010010 | |
| 2014-07-20 15:56 | Edward-san | Note Added: 0010011 | |
| 2014-07-20 16:42 | TerminusEst13 | Note Added: 0010013 | |
| 2014-07-20 16:42 | TerminusEst13 | Status | feedback => new |
| 2014-07-21 09:18 | ZzZombo | Note Added: 0010024 | |
| 2014-07-21 14:59 | Popsoap | Note Added: 0010027 | |
| 2014-07-21 15:00 | Popsoap | Note Edited: 0010027 | bug_revision_view_page.php?bugnote_id=10027#r5381 |
| 2014-07-22 06:16 | ZzZombo | Note Added: 0010032 | |
| 2014-07-22 07:21 | TerminusEst13 | Note Added: 0010033 | |
| 2014-07-22 11:23 | ZzZombo | Note Added: 0010034 | |
| 2014-07-23 05:53 | TerminusEst13 | Note Added: 0010041 | |
| 2014-07-23 05:53 | TerminusEst13 | Note Edited: 0010041 | bug_revision_view_page.php?bugnote_id=10041#r5390 |
| 2014-07-23 12:45 | Ivan | Note Added: 0010042 | |
| 2014-07-23 12:58 | ZzZombo | Note Added: 0010043 | |
| 2014-07-23 13:00 | ZzZombo | Note Edited: 0010043 | bug_revision_view_page.php?bugnote_id=10043#r5392 |
| 2014-07-23 16:32 | Popsoap | Note Added: 0010044 | |
| 2014-07-23 16:42 | TerminusEst13 | Note Added: 0010045 | |
| 2014-07-27 16:41 | Popsoap | Note Added: 0010059 | |
| 2014-07-27 16:42 | Popsoap | Note Edited: 0010059 | bug_revision_view_page.php?bugnote_id=10059#r5407 |
| 2014-07-28 00:11 | ZzZombo | Note Added: 0010060 | |
| 2014-07-28 00:13 | ZzZombo | Note Edited: 0010060 | bug_revision_view_page.php?bugnote_id=10060#r5409 |
| 2014-07-28 00:26 | TerminusEst13 | Note Added: 0010061 | |
| 2014-07-28 00:48 | Popsoap | Note Added: 0010062 | |
| 2015-08-17 17:47 | WaTaKiD | Relationship added | has duplicate 0002405 |
| 2015-08-17 18:14 | WaTaKiD | Status | new => confirmed |
| 2015-08-17 18:14 | WaTaKiD | Resolution | open => backport later |
| 2015-08-17 20:25 | Ivan | Note Added: 0013226 | |
| 2015-11-29 22:14 | WaTaKiD | Note Added: 0013920 | |
|
Notes |
|
|
(0008733)
|
|
jam
|
2014-05-07 18:02
(edited on: 2014-05-07 21:03) |
|
I'll try this one out. Feel free to fix it if you already know how though :)
EDIT: I may have fixed it, but I need to know a couple more things:
1) Does this apply to weapons only, or items too? Coz there are extra item pickups w/o sv_noweaponspawn which is spawned too.
I'm assuming this is not only a weapon problem, but items too. Since even the items haven't respected sv_noweaponspawn (meaning they are also custominventory items)
|
|
|
|
|
|
I believe it does affect items as well. I'm not 100% absolutely sure, due to not having a lot of maps on hand where extraneous items are spawned in multiplayer instead of just weapons, but it seems in Heretic at least there are a ton of extra items. |
|
|
|
(0008757)
|
|
jam
|
|
2014-05-09 14:27
|
|
|
Fixing this would mean modifying zdoom code, this might cause conflicts while porting to newer versions of zdoom. We might have to modify zdoom's source and push there instead :/ |
|
|
|
|
|
Can you see if zdoom wants to fix this? After that result, we can go from there |
|
|
|
|
|
I'd WONTFIX this. Those items could use an ACS script to check for gamemode and the CVAR, and act accordingly. Even if authors don't bother a patch .WAD can be created. |
|
|
|
|
|
Did someone report to zdoom? |
|
|
|
|
ZzZombo: That would change...absolutely nothing. There is currently no way for a cvar to check if a specific weapon spawn is for multiplayer and thus shouldn't spawn yet/in that area.
Edward-san: Sorry, I forgot. I'll do so right away. |
|
|
|
|
|
What do you mean? What the map author completely don't know what did he insert into the map? He knows well what items will appear in multiplayer, so he just have to check the gamemode and the CVAR. |
|
|
|
(0010027)
|
|
Popsoap
|
2014-07-21 14:59
(edited on: 2014-07-21 15:00) |
|
Quote from "ZzZombo"
What do you mean? What the map author completely don't know what did he insert into the map? He knows well what items will appear in multiplayer, so he just have to check the gamemode and the CVAR.
The point of the feature is to work with any map, not just ones designed specifically to have this work. And I'm pretty sure the solution you posted wouldn't even work in the intended manner because the initial item placement is handled during initialization of the map.
|
|
|
|
|
|
Just try it before jumping to conclusions, sir. |
|
|
|
|
Please refer to the picture in the OP.
Those areas are multiplayer-only spawns, which spawn weapons in multiplayer game modes. With sv_noweaponspawn, these areas do not spawn weapons.
Compare this with the shotgun outside or the rocket launcher in the little cubby, which are not multiplayer-only spawns and always spawn weapons whether sv_noweaponspawn is on or off.
If I do a cvar check and make all weapons not spawn when sv_noweaponspawn is on, that completely removes the weapons from the multiplayer-only weapon spawns AS WELL AS the weapons from the not-multiplayer-only weapon spawns.
The problem is that sv_noweaponspawn is supposed to remove only the multiplayer-only weapon spawns, not all weapon spawns on the map.
Because custominventory weapon pickups don't register as weapons, sv_noweaponspawn does not remove the multiplayer-only weapon spawns. |
|
|
|
|
|
|
|
|
'https://www.dropbox.com/s/ivvtvjq6sl2jk6z/te13-custominventorynoweaponspawnexperiment.pk3 [^]'
Tried it, and as expected, absolutely nothing changes.
For the sake of testing, all weapons sans the Chainsaw and BFG9000 have been replaced with custominventory pickups. BFG9000 only appears as a multiplayer-only spawn weapon and the Chainsaw appears normally, so those acted as the control for this experiment.
I adjusted the script to check for co-op instead (since this is a co-op issue and not a deathmatch issue), and when the map loads up with sv_noweaponspawn 0, all weapons spawn normally. When the map loads up with sv_noweaponspawn 1, the BFG9000 is gone and the Chainsaw still spawns...but the custominventory pickups are still spread across the map.
|
|
|
|
(0010042)
|
|
Ivan
|
|
2014-07-23 12:45
|
|
|
I can also confirm that this exists on weapons dropped with Randomspawners as well, thanks to WaTaKid. Should definitely be fixed. |
|
|
|
(0010043)
|
|
ZzZombo
|
2014-07-23 12:58
(edited on: 2014-07-23 13:00) |
|
I don't know why I even bothered to check your code, I absolutely expected you will fail to code it properly, and indeed, you even code awfully in Decorate (SGN2 1 loop instead of SGN2 -1 stop yeah, let's waste CPU cycles doing unnecessary animation loops for every replaced actor).
First:TNT1 A 0 ACS_ExecuteAlways(873,0,args[1])
You had to set args[0] to either 0 (don't remove) or 1 (remove), and always supply args[0] (don't even touch other args, do you get it?) to the script. Also args are supposed to be set from map editor, not in the actor definition, because they will always override map supplied values.
|
|
|
|
|
Quote from "ZzZombo"
I don't know why I even bothered to check your code, I absolutely expected you will fail to code it properly
And I expected you to fail to understand the point of the suggestion in the first place.
Quote from "ZzZombo"
You had to set args[0] to either 0 (don't remove) or 1 (remove), and always supply args[0] (don't even touch other args, do you get it?) to the script. Also args are supposed to be set from map editor, not in the actor definition, because they will always override map supplied values.
I was giving you the benefit of the doubt and praying that args[0] corresponded to this. |
|
|
|
|
"Also args are supposed to be set from map editor, not in the actor definition, because they will always override map supplied values."
If we need to edit the map's Things or create new maps in order for this to work, then it's not really a solution at all. |
|
|
|
(0010059)
|
|
Popsoap
|
2014-07-27 16:41
(edited on: 2014-07-27 16:42) |
|
|
|
|
(0010060)
|
|
ZzZombo
|
2014-07-28 00:11
(edited on: 2014-07-28 00:13) |
|
|
|
|
|
Quote
OK, done. I added a new flag, called WEAPONSPAWN that can be placed on the replacing actors.
It is in and implemented! Neat!
Quote
Please note that this will have no effect on DF_WEAPONS_STAY, because CustomInventory items by their very nature cannot deal with that!
No worries, have it check and then have the Pickup state jump to either Fail or Stop depending on what the setting is. Neat!
How is this "not really"? |
|
|
|
|
Quote from "ZzZombo"
Nop, not really.
The DF_WEAPONS_STAY flag is easy to account for. It isn't what was requested in the first place anyway. |
|
|
|
(0013226)
|
|
Ivan
|
|
2015-08-17 20:25
|
|
|
Is there any chance of having this commit'http://zdoom.org/Changelog/6d4eb7f6/files [^]' backported for 3.0? It's only 2 months off from the 3.0 target's last changeset, being May 2014. (This is July 2014) I believe people here have made a reasonable case for it's inclusion. It not only provides incredible ways to actually work around certain limitations with weapon pickups (case by case distribution of specific weapons on specific situations being one) it also expands what a pickup can do. |
|
|
|
|
|