190 posts not shown on this page because they were spam
190? How is this possible?
now it's 24 posts not shown on this page because they were spam funky
the first time it's because you clicked on the "new 190" link. The second time you clicked on the "last 25" link.
Kill Count Bug (and How To Fix It)
dumptruck, I've found an obscure bug which affects the kill count if a map includes trigger-spawned Rotfish. I was going to email you about this, but I think an explanation of this bug might be useful for others, because it illustrates something about the engine which isn't obvious. So, I thought I'd post this here, where others can see it.
I noticed the issue in the map pd_ionous, but it should affect any map with trigger-spawned Rotfish.
The bug is that the "total monsters" count becomes incorrect after a trigger-spawned Rotfish is triggered, but the incorrect count only becomes visible to the player if they save their game, then load the saved game.
To see the bug while playing pd_ionous: simply play up to the point where the three Rotfish have been triggered and have appeared, then save and load. Assuming you're playing on Normal skill, the "total monsters" count in the status bar should be 19 when you save, but after loading, the count will jump to 22. But there really are only 19 monsters, so it becomes impossible to get 100% kills.
The tl;dr solution is to increment the total_monsters global in swimmonster_start() instead of in swimmonster_start_go(). But I expect it's not obvious why that fixes the issue, or even why the issue happens at all, so I'll explain.
There are two things going on here:
Thing #1: Why the total_monsters global becomes incorrect when a trigger-spawned Rotfish is triggered
This comes down to the way progs_dump currently fixes the old Rotfish kill count bug that was present in id's original code. The old bug existed because total_monsters got incremented twice for every Rotfish, once in swimmonster_start(), and again in swimmonster_start_go().
progs_dump currently fixes this by removing the increment from swimmonster_start(), and leaving the one in swimmonster_start_go(). However, this creates an inconsistency with walking/flying monsters, because those monsters increment total_monsters in walkmonster/flymonster_start(), and not in walkmonster/flymonster_start_go().
In the usual case where a Rotfish is spawned normally, this inconsistency doesn't make a difference.
But the inconsistency causes a problem when a Rotfish is trigger-spawned. In this case, total_monsters gets incremented twice per Rotfish:
1) The first time is on map start. monster_fish() calls swimmonster_start(), which calls monster_teleport(), which increments total_monsters.
2) The second time is when the Rotfish is triggered. monster_teleport_delay() sets self.think to monster_teleport_go(). When this is called, it calls self.think1(), which is swimmonster_start_go(), which increments total_monsters again.
Thing #2: Why the change to total_monsters only becomes visible to the player after they load a saved game
This comes down to the way the engine divides things between the server and client.
This applies even when a player is playing locally (i.e. when the Quake executable is acting as both the server and the client).
The progs.dat code runs on the server-side. Variables such as total_monsters are also on the server-side, and the client-side does not have direct knowledge of them.
When a player spawns for the first time, or loads a saved game, the server sends the value of total_monsters to the client, so that the client can display that number in the status bar (and during the intermission).
However, if total_monsters changes on the server after that, the server does not automatically inform the client that the value has changed. This is the thing that isn't obvious. It's why, in this case, the player doesn't immediately see that total_monsters has changed after a Rotfish is triggered, even though the variable has changed on the server-side.
Loading a saved game forces the server to send the current value of total_monsters to the client. This is why the bug becomes visible to the player after they load.
(As an aside, which isn't relevant in this case, but might help someone: if a mod actually wants to update total_monsters mid-game, and wants to notify clients of the change, the answer is to send a SVC_UPDATESTAT message to the clients. Both of the mission packs, and various mods, include code showing how to do this.
But this isn't relevant to the issue I've explained here, because the code obviously isn't supposed to increment total_monsters mid-game.)
But, yes, the solution in this case is just to increment total_monsters in swimmonster_start() instead of in swimmonster_start_go().
dumptruck, I hope the above makes sense? If anything is unclear, please let me know.
Good catch. All of the above makes total sense. Thank you for such a detailed explanation.
No problem. progs_dump is a really good resource for mappers. Happy to give whatever help I can.
I've identified some other bugs, which don't require as much explanation as the above, all of which seem fixable.
I'd like to send suggestions as to how to fix them -- what's the best way to do this? Should I do the whole GitHub thing where I send you a pull request for each fix? Or would it be better if I just email you with descriptions and code snippets?
I am traveling soon so I may not merge them for a week or longer. Thanks.
Cool -- it'll probably be a good few days before I'm in a position to start uploading to GitHub in any case. Hope you have pleasant travels.
progs_dump devkit version 1.1.1
is available with lots of bug fixes thanks to QuakeC MVP iw
DOE's multi-floor elevators have been added with bug fixes and improvements. A demo map is included.
If you are currently working with 1.1.0, I highly recommend porting your mod over to this version.
* Added func_elvtr_button and ELEVATOR functionality to func_new_plat (iw)
* Fix Fiends never going into their pain animation (iw)
* Fix a critical bug involving func_elvtr_button (iw)
* Address various FTEQCC warnings (iw)
* Fix kill count bug with trigger-spawned Rotfish (iw)
* Fixed qc syntax errors in monsters.qc (iw)
* Fix various issues involving gravity and ladders (iw)
* Make trigger_ladder ignore bad (up/down) angles (iw)
* Fix items not respawning in deathmatch mode (iw)
* Fix a "friendly monster" bug in trigger spawned monsters (iw)
* Fix pain_target never firing in some cases (iw)
* Fix item_health collision with BSP model entities (iw)
* Fix the weapon_shotgun spawnflag test (iw)
* Allow "wait" to be set for elevators (iw)
* other tweaks to DOE elevator code in doeplats.qc (iw)
* pd_elevator demo level (iw)
Source is included and can also be found on GitHub
@Preach - you may want to take a look at the commit re: the trigger spawned Rotfish. iw found an interesting issue and the solution is well documented.
The next release of pd_ will focus on adding coop spawnflags and possibly new coop features.
Sorry I meant this commit here.
Ummm not sure about that - what would you use them for?
Just A Thought...
Decoration for things like a group of fishes. It was my struggle when I made beez. They were bounded by a bouncing box. Or a turning satellite.
New Video Series For Pd_
Here's a playlist
for a new series of videos on progs_dump. Will explore the features and show how to set them up. Also will examine mods and packs that use the devkit. Aimed at new mappers but good info dumps for the experienced mapper as well.
3 videos now and more to come.
progs_dump Version 1.1.2 is live
Download it here
This release includes a new sample map pd_lightning
, that displays the lightning trap entities in more detail in addition to the trap_shooter_triggered entity.
Here's the changelog:
* Added newflags.qc (iw)
* Added new spawnflags (iw)
4096 Not in Coop
8192 Not in Single Player
32768 Not on Hard Only
65536 Not on Nightmare Only
* Fixed collision issues in trap_shooter, trap_spikeshooter, trap_switched_shooter
* Added workaround for if(string) engine bug (iw)
* Added function SUB_UseAndForgetTargets() to subs.qc (iw)
* Fixed sight_target firing targets multiple times (iw)
* Fixed pain_target not using targetname2/3/4 (iw)
* Fixed messages not displaying with sight_trigger (iw)
* Make weapons fire their targets in Coop and DM2 modes (iw)
* Prevent keys firing multiple targets multiple times in Coop (iw)
* Fixes to func_bob (iw)
* Fixed messages not displaying with func_counter (iw)
* Fixed "delay" making func_counter not work (iw)
* Added SUB_DislodgeRestingEntities to subs.qc (iw)
* Fixed func_breakable debris sometimes floating (iw)
* Added pd_lightning demo map
* Fixed func_laser audio issue when used with func_counter
* Added GNU License and source to my_mod directory
More updates will be coming in the weeks ahead but we wanted these bug fixes available as soon as possible.
A HUGE thank you to iw for all his hard work improving this mod!
In my enthusiastic rush to get version 1.1.2 of the devkit out the door I neglected to document the new spawflags iw has generously coded in. Here are the comments from the newflags.qc for everyone's reference. I will update the manual with this same info soon and share it.
NEW SPAWNFLAGS FOR ALL ENTITIES
This file was created for progs_dump by Ian "iw" Walshaw, August 2019.
It defines functions which can be called to implement the following new
4096 Not in Coop
8192 Not in Single Player
32768 Not on Hard Only
65536 Not on Nightmare Only
(Spawnflag 16384 is not used here because it's already used for
something else in progs_dump.)
The new spawnflags complement and complete the set of built-in
spawnflags provided by the engine, which of course are:
256 Not on Easy
512 Not on Normal
1024 Not on Hard or Nightmare
2048 Not in Deathmatch
In conjunction with the old spawnflags, the new spawnflags make it
possible to exclude any entity from any combination of game modes and/or
"Not in Coop" and "Not in Single Player"
These spawnflags were inspired by Quoth 2 (Kell and Necros, 2008), which included two additional spawnflags for all entities: "Not in Coop" and
"Coop Only". In contrast to Quoth 2, the spawnflags implemented here
are "Not in Coop" and "Not in Single Player", for symmetry with the
built-in "Not in Deathmatch" spawnflag.
"Not on Hard Only" and "Not on Nightmare Only"
The set of built-in spawnflags doesn't allow a mapper to treat the Hard
and Nightmare skill levels differently, because it only includes one
spawnflag, 1024, which excludes an entity from both Hard and Nightmare.
The new "Not on Hard Only" and "Not on Nightmare Only" spawnflags allow
the mapper to exclude an entity from one of these skill levels without
affecting the other.
New Episode Of The Progs_dump Series
Here's a new video
that covers some of the big fixes and features of the latest version 1.1.2
This goes into detail on the lightning trail entities (ltrail) from Quake's 2nd mission pack, Dissolution of Eternity.
NOTE: As I type this, the video is still uploading. Should be up within an 1/2 hour of this post.