Updated Python Debug Console [v1.5]

[Kaks]

Now that this all works, we should probably have a wiki page for the use of the console.

Sounds like a plan! There are many, many ways to use the console that could do with an example or two...

The only page I could see with some usage examples is the  original debug oxp page which is sketchy at best, and slightly outdated too (what did the :: macro do??)!

And snap! I added a link to 'our' tcp protocol at the same time as you did!

[Eric Walch]

The only page I could see with some usage examples is the  original debug oxp page which is sketchy at best, and slightly outdated too (what did the :: macro do??)!

Thanks for the link. i could not find it but somehow I new it was there somewhere. I have no idea why it was not indexed as scripting. Makes much more sense than the current: "Misc OXPs | Oolite expansion packs | Oolite utilities" as its only intended for scripters and not for normal users. Although the target inspector in the mac version would be useful for players.

[Thargoid]

Although the target inspector in the mac version would be useful for players.

It would be useful for non-Mac scripters too

[Thargoid]

Hmm, something still isn't right.

I still don't seem to have persistently saved user macros, and if I :listM after I've :setM a macro but not yet saved the game, then the console dumps the connection on me. That is with last night's debug.oxp installed and console v1.4.4. under Win7 64-bit.

If I save the game :listM works (doesn't dump and shows the new macro). But if I then restart Oolite and do a :listM it dumps me out again.

[Kaks]

Save the game? It shouldn't make any difference one way or another.


Here's what I've just done, using a pc with win7 professional, 64 bits.

I've downloaded the nightly build, done a clean install. downloaded the console, extracted it to desktop.

Started the downloaded console, started the downloaded Oolite-trunk. done a

:setM test1 consoleMessage( 'Testing - ' + PARAM +' - testing!')

done

:listM

all macros listed, including the newly added :test1

:test1 hello

worked

turned off Oolite (twice, once with shift-q, once by hitting the 'close window' button)

Connection closed:"Oolite is terminating."
Opened connection with Oolite version 1.77
Connection closed:"Oolite is terminating."

appeared on the console.

NB no explicit saving of anything, Oolite-Trunk did save the new macro automatically on shutting down.


restarted Oolite-trunk once again.

Code: Select all

:listM

all macros listed, including the newly added :test1


No dumping of connection. At any point.
No savegame here contains (or should ever contain) any debug console macros whatsoever.
The clean Oolite-Trunk I've got has no savegames at all, but it now has 5 different test macros, all duly listed with :listM

Have you got a wip OXP that tries to save macros onto a savegame? What do you get in the log? How many macros have you got in total? What happens if before doing anything else you type the following?

console.ignoreDroppedPackets = true

[Kaks]

And one more thing!
Thargoid, can you try replacing oolite-debug-console.js inside c:\Oolite-trunk\AddOns\Basic-Debug.oxp\Scripts with the following one?

http://svn.berlios.de/viewvc/oolite-lin ... console.js

I've changed :listM so it shouldn't drop packets under any circumstances... and it now lists macros in alphabetical order, rather than the semi-random order they were displayed before.

[Gimi]

Kaks.

I see in the logs on Berlios that you have added a new debug key "c" to trunk, all versions.Your description in the log is a bit short. If I have understood the functionality right, it turns on and off the connection between Oolite and the debug console, with it's main purpose being to connect to the console while the game is running or to reconnect in case of a dropped connection.

I need to update the 1.77 key map.

On another note, is it still the intention to disable the debug console for main releases of Oolite, while still having an "OXP developers version" where the console is enabled for those that need it. Or are you going in the direction of always enabled.

[Kaks]

It's a new debug key, and it's framed by the #ifndef NDEBUG directive, so it's only enabled for debug versions of Oolite.
And yes, its only purpose is to get Oolite to connect/disconnect to a running console, if: debug.oxp/basic-debug.oxp was found in the addons directory, and you've got a running tcp debug console.
If running mac Oolite, the integrated mac debug console doesn't have connection issues, so mac integrated consoles are unaffected by pressing c when paused during flight.

Of course, console support itself is only enabled for debug versions of Oolite too!

Just to recap, starting from 1.77, the main release version of Oolite will be without debug features, making it faster, and using less memory than the otherwise identical debug version. The debug version will also be available, with all the debug features exactly as they are on the nightly builds.

Edit: Hmm, maybe we'll need 2 different keymaps, one for each version. What do you reckon?


Anyway, I've had another look at the various macro commands, and found a SNAFU in rev3909 that meant using :resetM would make it impossible to manually create new macros on a mac, and since rev4807 made it impossible to create new macros on windows & linux pcs too!
The new :resetM is now in trunk and - since I was fiddling with that part of the code - I've re-tweaked the new :listM so it lists all the built-in (& oxp) macros first - in alphabetical order, then all the user defined ones, again in alphabetical order. Hope that this last way of listing the macros makes a bit of sense!

Oh, and a heads-up: it looks like I'm going to do a bit more testing on all this debug console related stuff, so there might be yet another version of debug console in a while...


PS: I was 'slightly' distracted by the day job as I wrote this post, and I kind-of overused 'and yes' in about everywhere. Re-reading it, I didn't like the overall tone of this post. This post is now new, improved, with 90% less 'and yes'ses, and suitable for human usage!

[Thargoid]

And one more thing!
Thargoid, can you try replacing oolite-debug-console.js inside c:\Oolite-trunk\AddOns\Basic-Debug.oxp\Scripts with the following one?

http://svn.berlios.de/viewvc/oolite-lin ... console.js

I've changed :listM so it shouldn't drop packets under any circumstances... and it now lists macros in alphabetical order, rather than the semi-random order they were displayed before.

Will do, but not sure when I will get the chance as I'm on a business trip this week and it's been quite manic so far. Maybe either this weekend or next week, unless things slow up a little here - but I doubt that strongly.

[Gimi]

Just to recap, starting from 1.77, the main release version of Oolite will be without debug features, making it faster, and using less memory than the otherwise identical debug version. The debug version will also be available, with all the debug features exactly as they are on the nightly builds.

Edit: Hmm, maybe we'll need 2 different keymaps, one for each version. What do you reckon?

Thank you for the info Kaks. There already are 2 versions of my key maps, with and without the debug control keys. I intend to keep it that way. Will post updated maps tomorrow.

[Gimi]

Quick question.

According to the Wiki [wiki]Oolite Keyboard Controls[/wiki] page, the "c" key is used for Octree Debug. Is this a conflict with the new toggle debug console connection key, or is the Octree Debug function no longer in use.

Wiki overview of debug keys can be found here.

[Kaks]

Very good question. When I had a look for available keys I couldn't find any sign of another debug 'c' key in the code itself. Might have gone partially blind though.

I'll do some in-depth investigation to see what happened there!

[Eric Walch]

Quick question.

According to the Wiki [wiki]Oolite Keyboard Controls[/wiki] page, the "c" key is used for Octree Debug. Is this a conflict with the new toggle debug console connection key, or is the Octree Debug function no longer in use.

Wiki overview of debug keys can be found here.

Its the question if that 'c' for octree debugging should be removed. Its very verbose in the log and you don't want to accidentally activate it. Since we have the console, you can also activate it through the console debugFlags :

Code: Select all

console.debugFlags |= 16

Yesteraday, I updated that part on the wiki page. I think that real debugging of that part would happen now with the console and not with the 'c' key during pause. Even no need to pause the game with the console. For the mac its even simpler, as debugging is also available through a menu option.

[Kaks]

I think that real debugging of that part would happen now with the console and not with the 'c' key during pause. Even no need to pause the game with the console.

Yep, I've had that proper look, and a separate octree debug key (aka old debug 'c') hasn't been in the code since version 3148 (11 april 2010). That's when the whole of octree debugging was transferred to the console setting Eric mentioned above. Unfortunately the documentation wasn't changed at the time, and everybody (me at least!) kind of forgot about it...

By the way, those flag options are also available as named constants. I'd generally write the longer, but slightly more memory friendly

console.flags |= console.DEBUG_OCTREE_LOGGING

[Kaks]

The last python console update for now! I've added the last few missing features that weren't quite ready for 1.4.4, and here's version 1.5. There shouldn't be any more updates for a long while now!