Debug Console (Visible, Scale)

I missed the control of the Debug Console (there is no “~” key on a smartphone, and the size of the console is not always convenient).
Category: Miscellaneous

logic_nodes
If Debug Console is disabled in the project settings, then nothing will happen (and null will be returned).

Small modification of the DebugConsole.hx class (added static get/set functions for the required fields).
Scripts: DebugConsole.zip

3 Likes

I like the idea :slight_smile:

I think is better to merge Get Debug Visible and Get Debug Scale into a single node to reduce the work.

Do you know if it is possible to disable/enable the console in real time? And changing anchoring/position?

Shouldn’t you follow the rules: one node - one operation/parameter? For ease of understanding.

Without the Debug Console option in the project settings, the code will not get into the build (using the arm_debug preprocessor variable).

 class DebugConsole extends Trait {

 #if (!arm_debug)
     public function new() { super(); }
 #else
   // Code class...

Debug Console uses the Zui class for rendering, its elements will be created for the code, and to change the position, you need to modernize the class code, without this it will not work. If necessary, I can try (I don’t think it will be difficult).

I think the debug should be anchored in the left, because our brain is used to read things starting from the left, but no need to care too much about that.

We need to avoid small nodes, because this increases the maintaining. Always is better to merge similar nodes. For example, if you merge the scale and the visible node, it will have just two or three more lines in the same node. If you create two small nodes, it will have the double of the size.

The debug console is not like an object with a lot of different data, then no problem about merging this two nodes into something like “Get Debug Console Data”.

It is just what i think, you may do what is better in your view

Just my two cents on this:

  • There already exists User Preferences > Addons > Armory > Show Advanced > UI Scale which sets the Zui scale (=> also the scale of the debug console). If you don’t need to change it during runtime, you can use this parameter instead, so maybe we don’t even need two nodes here.

  • Do you know if it is possible to disable/enable the console in real time?

    In theory that would be possible. There must be some flag then that enables including the debug console code without displaying it when the game starts (right now its impossible as @E1e5en stated) . But usually you can just enable it when debugging and disable it when exporting the final builds.

  • It’s because i think the debug should be anchored in the left, because our brain is used to read things starting from the left, but no need to care too much about that.

    Maybe there should be a setting in the preferences for that? I personally prefer it on the right side, maybe because I use two monitors and usually have Blender open on the left and VSCodium on the right. The debug console then is rather in the middle.

  • I’m not really sure if there is a need for a node to retrieve the debug console scale, what would be its use case?

1 Like

I think the scale is valid for mobile and some small screens with high resolution. Higher resolution screens makes the debug console and UI elements unreadable.

The anchoring point would be cool to change according to the need. I suggested the left side because i can hardly tell a game that uses chats or this kind of stuff in the right side, maybe there is a reason for this, but anyway it is not a thing that annoys.

I only want to scale the console, not the entire UI. This is what happens in the node, because I change the scale of one instance of the class.

  • Example: setValue (getValue() +/- 0.1);
    This will make it easier to scale to fit different extensions without customizing the project.
  • My rule:
    The “Set” operation without the “Get” operation is necessary in special cases, for example, output to the console, log…
    But if we change the parameters of the object, then the “Get” operation must be, otherwise it is not correct.

Position Debug Console

I think this is a useful opportunity, so I will.

1 Like

I suggest the following implementation:

  1. Modernization of the DebugConsole class:

a) Default keyboard controls:

  • key “~” - show / hide the console (it was like this before, it will remain so);
  • keys “[” and “]” - decrements and increments the debugFloat variable and prints the value to the console. This variable does not affect anything, but is used for another class. I propose to supplement the functionality: change the scale using these keys (the value can change from 0.3 to 10 with a step of 0.1).
    The value 0.3 is the minimum; if it is less, the application crashes.

It was:

// Toggle console
kha.input.Keyboard.get().notify(null, null, function (char: String) {
if (char == "~") visible =! visible;
else if (char == "[") {debugFloat - = 0.1; trace (getScale ()); }
else if (char == "]") {debugFloat + = 0.1; trace (getScale ()); }
});

Became:

        // Toggle console
		kha.input.Keyboard.get().notify(null, null, function(char: String) {
			if (char == "~") visible = !visible;
			else if (char == "[") {
				debugFloat -= 0.1; 
				trace("debugFloat = "+ debugFloat);
				// Scale
				var debugScale = getScale() - 0.1;
				if (debugScale > 0.3) {
					setScale(debugScale);
				} 
			}
			else if (char == "]") { 
				debugFloat += 0.1;
				trace("debugFloat = "+ debugFloat);
				// Scale
				var debugScale = getScale() + 0.1;
				if (debugScale < 10.0) {
					setScale(debugScale);
				} 
			}
		});

b) Add field, methods and enumeration for the position. Option 3: LEFT, CENTER, RIGHT.
The default is RIGHT.

  1. Refinement of logical nodes, taking into account all the proposals:

v2

Scripts: DebugConsole_v2.zip

To use Data in the name of the node rather confuses me, because there is a lot of data for the debug console. But this node is configuring it.

2 Likes
  1. Expand Armory Project settings:

3 Likes
  1. There was a requisition to enable the Debug Console by default for new projects. I suggest this option:
    armory_settings

If necessary, then I have implemented it.

What do you think about all the above improvements? What is needed and what is not?

3 Likes

What do you think about all the above improvements?

100% awesome :slight_smile: Maybe even add a way to change the console shortcuts in the preferences for people who don’t have an English keyboard?

May I ask why you have to restart Blender when changing that preference in the post above?

I’ll try…

In the current implementation, checking whether the option is enabled or not occurs when the interface is initialized (props.py). Therefore, the property is read when Blender starts up. I’ll try to fix it. If you have any ideas, I will be glad to hear.
An event is needed that fires in the Armory code when a new project is created.

You could use the if section in props.init_properties_on_load(), it is only executed when the Arm world doesn’t exist yet. Not sure if that solution works.

1 Like

Now it works like that. In the props.init_properties_on_load() function, the init_properties() function is executed if the Arm world does not already exist. In the init_properties() function, all parameters for the interface are added and default values are assigned there:

bpy.types.World.arm_debug_console = BoolProperty(name="Debug Console", description="Show inspector in player and enable debug draw.\nRequires that Zui is not disabled", default=arm.utils.get_debug_console_auto(), update=assets.invalidate_shader_cache)

But without restarting Blender, it won’t work.

I experimented a little more and it works like this:
Function code

def init_properties_on_load():
    if not 'Arm' in bpy.data.worlds:
        init_properties()
    arm.utils.fetch_script_names()

The init_properties_on_load() function fires when the project is created or loaded, but the condition (if not 'Arm' in bpy.data.worlds) is only true when Blender starts. In other cases, the init_properties() function does not work. Therefore, the condition is not read from the settings without restarting (maybe this is an error in this case, if you expect a different result).
To determine that the project is new, you can check whether it is saved to a file or not (check bpy.data.filepath). This is how it will now work without rebooting:

def init_properties_on_load():
    if not 'Arm' in bpy.data.worlds:
        init_properties()
    # New project?
    if bpy.data.filepath == '':      
        bpy.types.World.arm_debug_console = BoolProperty(name="Debug Console", description="Show inspector in player and enable debug draw.\nRequires that Zui is not disabled", default=arm.utils.get_debug_console_auto(), update=assets.invalidate_shader_cache)
    arm.utils.fetch_script_names()

Why are you redeclaring the property instead of just setting its value? This is probably why it updates only on restarting Blender.

1 Like

All properties are declared in init_properties() function. I also added the code for the new property there. And the update didn’t work because the condition if not 'Arm' in bpy.data.worlds was only triggered once when Blender started.
Yes, after checking the condition for a new project, only the value needs to be changed. But I still haven’t figured out how to do it and implemented the property override. :slight_smile:
Tell me how to fix it, I will only be glad.

Changed to this:

def init_properties_on_load():
    if not 'Arm' in bpy.data.worlds:
        init_properties()
    # New project?
    if bpy.data.filepath == '':
        wrd = bpy.data.worlds['Arm']
        wrd.arm_debug_console = arm.utils.get_debug_console_auto()          
    arm.utils.fetch_script_names()

At first it didn’t work out for me, but I sort of figured it out. :sweat_smile:
Scripts: DebugConsole_v3.zip

1 Like

Did I understand correctly that such a setting is needed?
hotkeys_v1

If yes, then do not tell me how to select keys like here:
hotkeys_version

Your solution looks good now :slight_smile:

Did I understand correctly that such a setting is needed?

It would be nice to have, but its not a must. For me with a German keyboard for example those shortcuts are impossible to use, to type a [, I need to press Alt Gr + 8 which probably is recognized by Iron as two keys (this combination) but not [ itself. But I would put the shortcut UI into the Armory user preferences and not into the properties panel as it is on the screenshot. Maybe even all the new debug console settings (this is probably a thing that each user wants to keep between projects? I don’t know).

If yes, then do not tell me how to select keys like here:

I’ve never done this so I don’t know for sure, but I did take a look into the source code of that UI (you can do that in Blender by Right click > Edit Source). UILayout.prop() has an event parameter to listen to a keyboard event (in this case you probably shouldn’t use full_event, see the linked documentation for explanation). Then you probably need to create a StringProperty to store the keys in.

Basically like this:

# wrd.arm_debug_console_visible_key is a StringProperty (maybe with a too long name?)
layout.prop(wrd, "arm_debug_console_visible_key", text="", event=True)
1 Like