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

[Nash]

RadiusDebug is a simple utility I use to see a visual representation of an Actor's radius - AKA hitbox - in the world. This works on any Actor - not just monsters. Basically, if a thing could hold inventory, it will work.

There are two ways to utilize this tool:

Method A



Go to the options menu to enable it for the entire level. There are several options to choose from.

Method B

Actors can have the radius (hitbox) models enabled individually, in either DECORATE or ZScript! Here are examples for both of them.

DECORATE:

Code: Select all

// Just give RadiusDebugMe to enable RadiusDebug on an Actor.
// Take RadiusDebugMe away from it to disable it.
// Simple!

Actor TestZombieman : Zombieman replaces Zombieman
{
    States
    {
        Spawn:
            TNT1 A 0 NoDelay A_GiveInventory("RadiusDebugMe")
            Goto Super::Spawn
    }
}

ZScript:

Code: Select all

class TestZombieman : Zombieman replaces Zombieman
{
    override void BeginPlay(void)
    {
        // This enables the radius debugger...
        RadiusDebug.Enable(self);

        // ... and this would disable it.
        // RadiusDebug.Disable(self);

        Super.BeginPlay();
    }
}

---

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

20th December 2018 Update:
- Proper height scale calculation
- Update size every tic so that Actor death height, and any other real-time changes will be reflected. This might be a little expensive, but because RadiusDebug is a development aid, I am not going to bother to optimize it

5th June 2018
- Initial release

Known Issues:

- Hardware renderer only. Unfortunately, some time after this mod was released GZDoom lost its ability to render models in software mode...
- When "actors are infinitely tall" is enabled, the bottom of the collision model doesn't touch the floor anymore. This is due to texture degradation from the extremely tall scaling.
- RadiusDebug is meant as a development aid and is therefore not really optimized for performance. Goes without saying; don't ship your mods with RadiusDebug. :P

Feel free to use this any way you like. No need to ask for my permission. Credits would be cool. Have fun!

Wanna chat about my mods? Join my studio's Discord server, Mischief Donut!


I spend an uncountable amount of hours making mods. Consider supporting me on Patreon for cool benefits!

[Enjay]

I just tried it with map20 in Doom2. It provides interesting and potentially useful information.

[Kinsie]

I've wished for this to be an engine feature for yeeeears now.

[dodopod]

I would suggest one small change. As you can see in the screenshots, monsters' heads tend to poke out the top of the radius box. According to the Doom Wiki:

However, height and width units do not quite agree. The 1-meter interpretation would imply that the Doomguy is one meter wide, or at least cannot pass through an opening narrower than one meter, which would be to exaggerate his muscularity. The discrepancy is likely related to the fact that pixels in Doom's original video modes were rectangular: because pixels were taller than they were wide, and each map unit was proportional in size to a pixel of an in-game texture, flat, or sprite, height units were larger than width units. A more realistic interpretation (if there is any such thing) is perhaps that one "width unit" (w) corresponds to 5/6 of a "height unit" (h).

So, it would be more accurate if you change the line

Code: Select all

Scale.Y = double(Height);

to

Code: Select all

Scale.Y = double(6 * Height) / 5;

Here's a comparison:

[camper]

It looks like 3d blocks, only without textures.

[Gez]

Now make a gun whose projectile uses A_RadiusGive to give RadiusDebugMe items, and you can call it RadiusRadiusDebug.

[Nash]

I would suggest one small change. As you can see in the screenshots, monsters' heads tend to poke out the top of the radius box. According to the Doom Wiki:

However, height and width units do not quite agree. The 1-meter interpretation would imply that the Doomguy is one meter wide, or at least cannot pass through an opening narrower than one meter, which would be to exaggerate his muscularity. The discrepancy is likely related to the fact that pixels in Doom's original video modes were rectangular: because pixels were taller than they were wide, and each map unit was proportional in size to a pixel of an in-game texture, flat, or sprite, height units were larger than width units. A more realistic interpretation (if there is any such thing) is perhaps that one "width unit" (w) corresponds to 5/6 of a "height unit" (h).

So, it would be more accurate if you change the line

Code: Select all

Scale.Y = double(Height);

to

Code: Select all

Scale.Y = double(6 * Height) / 5;

Here's a comparison:

This only works correctly if the project's PixelRatio is at "Doom" settings (1.2). For projects with PixelRatio 1.0, your fix looks wrong on them.

level.pixelstretch can be used to retrieve said setting. Can you figure out how to fix this into the calculation? I suck at maths.

[dodopod]

This only works correctly if the project's PixelRatio is at "Doom" settings (1.2). For projects with PixelRatio 1.0, your fix looks wrong on them.

level.pixelstretch can be used to retrieve said setting. Can you figure out how to fix this into the calculation? I suck at maths.

In that case the line should be:

Code: Select all

Scale.Y = double(Height) * level.pixelStretch;

[Nash]

20th December 2018 Update:

- Proper height scale calculation
- Update size every tic so that Actor death height, and any other real-time changes will be reflected. This might be a little expensive, but because RadiusDebug is a development aid, I am not going to bother to optimize it

Download link in first post

[gramps]

Hey, that's pretty neat!

I'm just gonna throw an idea out there; not really related but this brings it to mind. I'd love to see an add-on with a toggle button that freezes time, and then draws a box like that around anything you point at, and also pops up all the stuff from the "info" console command in a nice little overlay thing. I've found myself using "freeze" and "info" a lot during some experimentation and something like that would speed things up quite a bit.

[TDRR]

Can you also add A_RadiusGive radius viewing? Even if it's just for RGF_CUBE.

[dodopod]

I made a custom event handler, which displays actor radii depending on a CVar. Just like with TestRadiusDebugHandler.pk3, load RadiusDebugCVar.pk3 after RadiusDebug.pk3 to make it work.

RadiusDebug can be set to either:

• None
• Monsters
• Pickups
• Solids
• Shootables
• All

Oh, by the way, calling RadiusDebug.Disable() doesn't work for me.

[Nash]

I have a few cool ideas to make this mod even more useful and actually universally auto-load ready (meaning you can just leave it in your autoload, and turn it on or off with a button toggle/option menu), and I can also add useful text info about what you are pointing at - but I'm going to way for GZDoom to add "extends Actor" functionality first (which will be technically possible, last I understood it).

[Kizoky]

I edited dodopod's code, so now you'll get a menu + and when you change the setting in the menu the box will be attached to the actors in real time
No need to reload the level

---

[Kzer-Za]

It appears there is a bug that crashes the game when you create a class inherited from ammo and inherit specific ammo types from this class. I have:

Code: Select all

Class SchismAmmo : Ammo
{
	Default
	{}
}

//---------------------------------------------------
Class SchismGoldWandAmmo : SchismAmmo replaces GoldWandAmmo
{
	Default
	{
		Inventory.PickupMessage "$TXT_AMMOGOLDWAND1";
		Inventory.Amount 10;
		Inventory.MaxAmount 100;
		Ammo.BackpackAmount 10;
		Ammo.BackpackMaxAmount 200;
		Inventory.Icon "INAMGLD";
	}
	States
	{
	Spawn:
		TNT1 A 0 NoDelay {RadiusDebug.Enable(self);}
	Exist:
		AMG1 A 1 Bright;
		Loop;
	}
}

As you can see, I removed everything from SchismAmmo, so it seems it is not any property or flag that is responsible, but the very fact of inheriting. If I inherit SchismGoldWandAmmo form just "Ammo", everything works. But if I inherit it from SchismAmmo, then regardless of what SchismAmmo has defined in it or it being just empty, the game crashes with:

Code: Select all

VM execution aborted: tried to read from address zero.
Called from RadiusDebugMe.Tick at RadiusDebug.pk3:zscript/radiusdebug/radiusdebug.zc, line 82