RadiusDebug - Actor radius (hitbox) tool (18/05/21 update!)

[Nash]

18th May 2021 Update
- Added menu option to toggle radius debug on several kinds of actors
- Fixed RadiusDebug.Disable(), it actually works now
- Added "actors infinitely tall" support
- Relicensed to MIT

Download in first post

To the 1 person who downloaded it: please redownload. I fixed a minor issue.

[Velaron]

When I try this on the latest version all it does is drop my FPS to single digits. Also would be useful to add some keywords like "hitbox" to the post, because I honestly couldn't find a mod like this because I was looking for the term hitboxes.

Actually, I managed to spot a single pink box for a frame, but after that the FPS just keeps dropping below 1 without me doing anything.

[Nash]

Added some words to help with the search engine.

I'll look into improving the performance improvement as soon as I can. Sorry about that!

[Sir Robin]

This is super useful! Thank you for creating and posting this.

I want to make it use a different color for non-solid actors. I'm looking at the files, I see the model file and the texture file but I don't see where they are associated. I'd like to create a second model def with a different color texture, then I can assign the proper model to the actor depending on whether it's solid or not. But I don't know how to do that.

As for optimization, a quick way to reduce work is to only do it when an input has changed. So I throw two new variables into class RadiusDebug:

Code: Select all

	double rLast;
	double hLast;

and then I do the sizing like this:

Code: Select all

			if (r!=rLast || h!=hLast)
			{
				A_SetSize(r, h, false);
			}
			rLast=r;
			hLast=h;

[Kzer-Za]

I'm looking at the files, I see the model file and the texture file but I don't see where they are associated. I'd like to create a second model def with a different color texture, then I can assign the proper model to the actor depending on whether it's solid or not.

Look at the modeldef.txt file. It references (includes) _models.txt in the very same folder as the model and skin file https://zdoom.org/wiki/MODELDEF

Concerning performance: must be something specific to the actor that Velaron was testing. I don't see any performance issues on my PC, which I assembled about 10 years ago, and even back then it was far from being top-tier.

Edit: looked more carefully at the _models.txt, and yes, it doesn't reference the skin file. Seems that the line assigning the skin can be omitted if it has the same name as the model, I didn't know that. Anyway, you need only to create a second definition, which is the copy of the first but with the skin line in it. Let's say, you create a second skin that is blue and name its file RadiusDebugBlue.png. Then the line should be Skin 0 "RadiusDebugBlue.png".

[Sir Robin]

Concerning performance: must be something specific to the actor that Velaron was testing. I don't see any performance issues on my PC, which I assembled about 10 years ago, and even back then it was far from being top-tier.

I didn't do any performance testing myself, I just saw in the comments it mentioned that the A_SetSize can be expensive, so I threw that in there.

you need only to create a second definition, which is the copy of the first but with the skin line in it. Let's say, you create a second skin that is blue and name its file RadiusDebugBlue.png. Then the line should be Skin 0 "RadiusDebugBlue.png".

Done! Color coded:
Red: Monsters
Yellow: Shootables
Green: Solids
Cyan: Pickups
Blue: Drops
Magenta: Everything else
White: Unused
I'm sure that a menu options panel could be created to customize that, but I'll leave that as an exercise for the next person.
here it is

and a screenie:

---

[Sir Robin]

If anyone is concerned with performance, I'd take a look at this:
In the event handler, every call to WorldThingSpawned past the first tic is calling UpdateRadiusDebugMode(). That function calls ClearRadiusDebug() and then DoRadiusDebug(radiusdebugmode) so it's essentially destroying all the radius debug models and rebuilding them every single time.
So when does WorldThingSpawned get called? Any time:
A hitscan weapon is fired and bullet puffs and/or blood splats are spawned
A projectile weapon is fired and a projectile is spawned
A projectile such as rockets are active which constantly spawn trail puffs
Any other spawns, for example pain elementals spawning skulls

So anytime any of those things happen, the entire set of radiusdeug models are destroyed and recreated. For people seeing performance issues, that's what I'd guess might be causing it. To verify, check your performance doing nothing vs something that constantly generates spawns, such as shooting chaingun, plasma rifle, or rocket launcher.

[Nash]

Yeah, that's exactly it. I just don't have free time right now (I'm on vacation). As I said a few posts up, I will be fixing it and uploading it as soon as I can!

[Sir Robin]

Yeah, that's exactly it. I just don't have free time right now (I'm on vacation). As I said a few posts up, I will be fixing it and uploading it as soon as I can!

No worries, enjoy your vacation! I was just pointing that out to anyone that wanted to look into the performance issues. I haven't tested it extensively but I'm not seeing any issues on my very-crappy-non-gamer system.

[Sir Robin]

I've been working on my Loot Markers, a mod that attaches map markers to certain actors and manages them. Functionally it's very similar to this mod, which attaches the radius debug cubes to actors and manages them. I decided to take a look at this mod, see if I could use what I learned in writing my mod to improve this one.
I ended up re-writing big chunks of it, and now hardly any of the original code is left. I took out the system of tracking the cubes with inventory items. I don't know why, but this seems to break some mods. So now there is just one big central cube manager in the event handler instead of a separate handler inventory item for each actor-cube relationship.
Next I worked on the flow - the original was clearing all the cubes and rebuilding them for every single item spawn call. That means the mod is doing a whole lot of unnecessary work, some times several times per tick. So I wrote a whole new system for managing the cubes, now a new one is spawned with each actor, and the whole set is only purged and rebuilt when you change modes or change levels. Drastic increase in performance, especially on levels with lots of spawning, like particle spawners, plasma enemies, rockets with trails, etc.
I added several different colors for the cubes, and the color is set depending on the actor:

• Magenta - general
• Red - Live monster
• Yellow - Shootable
• Green - Solid
• Cyan - Pickup
• White - Non-BlockMap item - projectiles, teleport landings, spawners, etc

I added a verbosity mode to the options menu. In verbose mode the mod reports every cube created or destroyed. You can use this to help debug spawning actors. It also shows the timestamp on each event, so you can see if things are spawning in the same frame or 1 frame away or whatever.
I added a feature to print a list of all the actors the debugger is currently tracking. The list is sorted based on the distance to the player. This is useful if you see a random radius debug cube and it's attached to an invisible actor so you have no idea what it's supposed to be. Just go near the cube and print the list. Since it's sorted by distance to the player, that phantom object should be somewhere near the top of the list. The list is also color-coded to match the colors of the cubes, to make it easier to figure out what's what.

A screenie of the colorful cubes:


A screenie of the cube list

The first line is the reference object, the player pawn, the line shows the absolute (x,y,z) position
The rest of the lines are objects tracked by the debug, showing the distance and relative (x,y,z) coordinates
Default list key is L, can be set in the top of the options menu

Download

[Nash]

Sir Robin: thank you for the improvements. Would there be any objections if I were to merge your changes into the main mod? With credits to you, of course.

[Sir Robin]

Sir Robin: thank you for the improvements. Would there be any objections if I were to merge your changes into the main mod? With credits to you, of course.

Thanks for asking, and please do. I'm not sure how licensing works but I think I maintained your MIT license by retaining the text and adding my name at the bottom. My general attitude is do what you want with the code just keep my name in the credits

[Nash]

Hey Sir Robin, can you add a mode that shows only Non-BlockMap items? The "all" option reveals them, but it's too noisy to be useful.

[Sir Robin]

done

[Nash]

Thank you! Unfortunately, it seems I misunderstood what "non-blockmap" is. What I was hoping was to see this stuff that's colored in magenta (but isolated):