Converting Python Scripts to meet PEP-8 (and bugs)

Announcements and discussion regarding any projects related to Cyan Worlds' Plasma Engine including (but not limited to) CyanWorlds.com Engine, Drizzle, OfflineKI, PyPRP, and libHSPlasma.

Re: Converting Python Scripts to meet PEP-8 (and bugs)

Postby johnsojc » Wed Aug 21, 2013 12:55 pm

Idling between projects... I (FINALLY!) built a working MOSS test bed so I can now test some of the Python scripts that DIRTSAND doesn't support (mostly the game manager stuff and markers).

I am slowly doing cleanup on the scripts that I already adjusted to meet PEP-8 but now I'm looking closely at all the log debug prints with the aim to make them somewhat more user-friendly. Mostly just standardizing the output structure and replacing the "%" formatting with the newer .format. I intend to make sure that every output line in the log clearly identifies what module and section of the code it came from (like Ahnonay.OnServerInitComplete():). I'm open to suggestions... I like to write myself some rules to follow in this task.
johnsojc
 
Posts: 246
Joined: Sun Dec 07, 2008 10:27 am

Re: Converting Python Scripts to meet PEP-8 (and bugs)

Postby johnsojc » Thu Aug 22, 2013 12:11 pm

I do not know how anyone could troubleshoot the Python code from the logs. A very large portion (30%-40%) of the lines either have no reference from where the log entry came or actually have the wrong source module name.

A good example was IDoCityLinksChron() in clftImager.py... some debug statements identified the source as being from xLinkingBookGUIPopup.IDoCityLinksChron(). It appears large sections of code were copied and pasted or moved from one function to another. It's all very confusing. Back to fixing it all...
johnsojc
 
Posts: 246
Joined: Sun Dec 07, 2008 10:27 am

Re: Converting Python Scripts to meet PEP-8 (and bugs)

Postby johnsojc » Mon Aug 26, 2013 5:23 am

As long as I'm mucking about with the log statements, I have a few questions about what we should do looking toward the future. Adam mentioned somewhere about setting up log levels to control exactly what prints out in the log and/or allow color coding of log entries for some kind of log viewer. Some statements have a level set but for now, everything prints out regardless of the log level.

There are 4 levels defined for PtDebugPrint(): DebugDumpLevel, WarningLevel, ErrorLevel, and AssertLevel. Do we want to:
    reenable turning logs on/off (/startlog(s); /stoplog(s))?
    have some control setting to set the level at which a log entry prints?
    allow setting logging level from the KI interace (like allowing a parameter for /startlog level=x)?
    do something else I can't think of atm?

On an unrelated topic, is it the intention of the GoW branch to maintain compatibility with the MOULa scipts or go off in some other direction? I am simply being curious as I understand there are intentions of completely rewriting the game manager part of the code. DiRTSAND does not have a GameManager atm and that branch seems to be dead. The WONDRUSS project hasn't seen any action for at least 6 months (not complaining... just noticing). So, for now, it seems prudent to me to maintain compatibility with MOULa and its clones.
johnsojc
 
Posts: 246
Joined: Sun Dec 07, 2008 10:27 am

Re: Converting Python Scripts to meet PEP-8 (and bugs)

Postby Tsar Hoikas » Mon Aug 26, 2013 9:19 am

Hmmm. By default the client should print everything that isn't a debug statement. It would probably be a good idea to add an info level between warning and debug--a lot of the prints are just info but not all are strictly debugging. I would probably remove the assert level, move error and warning up, then insert info where warning used to be.

For now, it would be prudent to remain as compatible as possible with Cyan's server/client setup. I think the plan was to finish all the game rewrites, then drop compatibility in the mainline code in one swoop. (smash bam boom?)
Image
Tsar Hoikas
Councilor of Technical Direction
 
Posts: 2180
Joined: Fri Nov 16, 2007 9:45 pm
Location: South Georgia

Re: Converting Python Scripts to meet PEP-8 (and bugs)

Postby johnsojc » Mon Aug 26, 2013 10:23 am

Heh! (smash bam boom) indeed!

Once I get through the dog work of cleaning up the debug statements so they correctly indicate their source and all have a common look and feel (there's some ugly stuff in there!), I will try to find where the hooks are to print the logs and figure out a way to be selective in what prints. If I can get that working, then once more through the code to set each "print" statement to one of the levels. That's assuming I can correctly interpret what level each line should be :roll: .

I'm my own worst enemy with this project... typos, Typos, TYPOs! are killing me!

(ex: who'd a thunk that
Code: Select all
coords = (0, 0, 0)
return U"%05d%   04d%   04d" % coords
would translate to
Code: Select all
return U"{0[0]:05d}{0[1]: 04d}{0[2]: 04d}".format(coords)
? coords is a tuple for the KI coordinates, (00000 000 000) you see in the nexus display... try typing that after 50 or 60 other file edits!)
johnsojc
 
Posts: 246
Joined: Sun Dec 07, 2008 10:27 am

Re: Converting Python Scripts to meet PEP-8 (and bugs)

Postby johnsojc » Wed Aug 28, 2013 12:50 pm

I've been round and round looking for where the default logging level is set in both the python and client code with no luck.

I went looking since I discovered that not everything is printing out in the logs since (apparently) the logging level is set to 2 (kWarningLevel) by default. To increase my confusion, the C code side levels seem to indicate that the higher the number, the more detail you get while the Python PtDebugPrint() only prints entries >= the logging level. Either I am misreading everything (entirely possible) or the C code and the Python work opposite each other. PtDebugPrint() appears to get the logging level from the C code (PtGetPythonLoggingLevel()). Right now, log entries coded at kDebugDumpLevel (level=1) are not printing for me.

Could someone point out where I am not seeing what the heek is going?

EDIT: and WOW! I changed the criteria for printing debug statements in PlasmaTypes.py to print more detail (essentially reversed it) so at a debug level of 2, everything from level 0 to 2 prints (not cool but definitely causes the log to take a dump :) ). The way it is currently written, if the default level is 2, then the warn(2) and error(3) levels print. Any statement not encoded with a level gets bumped to 3 and prints as well. Now the question is how exactly should this be written to work? I also found a level 0 setting (kNoLevel) that could be used. And I still need to know where the default level is set. I found the command to set it using the console.

EDIT2: nvm... I found it in cyMisc.cpp... set to 3 if external client and 2 if anything else. Can also be changed through the console.
johnsojc
 
Posts: 246
Joined: Sun Dec 07, 2008 10:27 am

Re: Converting Python Scripts to meet PEP-8 (and bugs)

Postby johnsojc » Fri Aug 30, 2013 6:38 am

Just uploaded latest commit to the pep8 branch on gitbub. This update includes:
    Fix PtDebugPrint() to correctly identify where in the code the log entry originated.
    Replace "%" operator string formatting with .format (anticipating future deprecating of "%" in Py3)
    Attempted to standardize format of all debug statements for a consistent look and feel.
    Fix minor typos (some not so minor :roll: )

TODO:
    Set appropriate dump level on PtDebugPrint() statements (not all have a level and some are incorrect)
    go back and change any print statements to print() function (there are a few left)
    even more things I don't want to think about atm

I'm still running tests with the log level set at max to check as much of the code changes as I can for typos but some always seem to slip through. At least I finally found out why that one JC in Garden causes the camera to go weird... missing camera modifier or some such... certain conditions cause the camera stack to get hosed.

EDIT: I'm still finding the occasional typo and non-fatal oversight but I have played through the entire game with these scripts (excepting game manager stuff I partially checked on a MOSS server) so these are good to go if anyone wants to use them. I'm not sure I'm knowledgeable enough to start assigning levels to the debug prints except the more obvious ones. It might be worth taking a moment to decide exactly how one would like the debug system to work before I spend another week or two running through the code again.
johnsojc
 
Posts: 246
Joined: Sun Dec 07, 2008 10:27 am

Re: Converting Python Scripts to meet PEP-8 (and bugs)

Postby johnsojc » Sat Aug 31, 2013 10:01 am

Just found a major flaw in the heek code (nb01RPSGame.py). The code fails to update the player chron as well as not updating the imager. The player's vault data only contains the original new player settings (rank 1 with 100 points) no matter how many rounds you win or lose. The textnote for the imager is never updated. I checked on MOULa and it appears the problem exists there as well. I think I'm going to tinker a bit with this. The one error I saw in the log is the imager is pointed at a folder instead of a textnote in xSimpleImager.IShowCurrentContent(). Need mo' debug statements...
johnsojc
 
Posts: 246
Joined: Sun Dec 07, 2008 10:27 am

Re: Converting Python Scripts to meet PEP-8 (and bugs)

Postby johnsojc » Sat Aug 31, 2013 12:49 pm

bug by design?

While troubleshooting the Heek game (specifically the score display on the Imager), I found where the code fails...
Code: Select all
ownerNode = chron.getOwnerNode()

The code appears to properly find the HeekScoresChron folder and extract the childlist of score chron nodes but when it tries to go get the player name (using the code above to find the player info), it always fails returning "None".

Digging into the client code, I found out why... GetOwnerNode() has been commented out!
Code: Select all
PyObject* pyVaultNode::GetOwnerNode( void )
{
    hsAssert(false, "eric, port?");
/*
    if (fNode)
    {
        const plVaultPlayerInfoNode* node = fNode->GetOwnerNode();
        if (node)
            return pyVaultPlayerInfoNode::New((plVaultPlayerInfoNode*)node);
    }
*/
    // just return a None object
    PYTHON_RETURN_NONE;
}


GetOwnerNodeID() is also commented out :roll:

It appears this is why the imager display is broken... I have to check on the part of the code that updates the score chrons when you are actually playing the game since it appears that's not working either.
johnsojc
 
Posts: 246
Joined: Sun Dec 07, 2008 10:27 am

Re: Converting Python Scripts to meet PEP-8 (and bugs)

Postby Tsar Hoikas » Sat Aug 31, 2013 1:32 pm

The entire vault api was (in the process of being) rewritten for MOUL. To be honest, there are a lot of issues with heek (eg that chronicled aren't the place to store game scores anymore). I think your efforts would be better spent elsewhere, rather than on bugs that won't even manifest on dirtsand anyway.
Image
Tsar Hoikas
Councilor of Technical Direction
 
Posts: 2180
Joined: Fri Nov 16, 2007 9:45 pm
Location: South Georgia

PreviousNext

Return to Plasma Development

Who is online

Users browsing this forum: No registered users and 0 guests

cron