RadiusDebug - Visual Actor radius utility [ZScript/DECORATE]

[Nash]

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

Usage is super easy, and can be used with both DECORATE and ZScript! Here are examples for both of them.

DECORATE:

Code: Select all • Expand view

// 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 • Expand view


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();
    }
}


I've also attached a test event handler that'll make every monster in the level show their radius. Just load TestRadiusDebugHandler.pk3 after RadiusDebug.pk3 to check it out.

Works in both OpenGL and the software* renderer.

* model rendering in software only works starting from GZDoom 3.5.0 onwards

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

[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 • Expand view

Scale.Y = double(Height);


to

Code: Select all • Expand view

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 • Expand view

Scale.Y = double(Height);


to

Code: Select all • Expand view

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 • Expand view

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 • Expand view

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 • Expand view

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