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 » Sat Aug 31, 2013 2:09 pm

Please point to "where". I just came across this problem while checking the debug statements for the heek game. Until I know what direction to go with the debug prints, I'm just idling about. At least I learned something new today.

You are correct about wasting time on this... the only script that uses getOwnerNode() is the heek game. I'd fix it if I could think of a simple way to do it. After all, there are other versions out there that are just as broken that still have a working game manager. I never got to play heek in MOUL because it was locked up more often than not in my hood and then the node code was 'deprecated'. It just doesn't sit well with me to know a problem exists and not try to do something about it.
johnsojc
 
Posts: 246
Joined: Sun Dec 07, 2008 10:27 am

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

Postby johnsojc » Tue Sep 03, 2013 1:56 pm

Need a suggestion or two to continue the debug statement project...

Normal conditions:
    external client set to level 3 (Errors only)
    internal client set to level 2 (warnings and errors)
    uncoded PtDebugPrint() statements bumped to level 3 and always print

What would you all like to see always printed? (uncoded)?
What type of situation warrants a Warning level (2)?
What type of situation warrants an Error level(3)... (besides Exceptions)?

Since these levels are coded into the C++ code, I don't think I can redefine them to be anything else (although I might be able to add additional keywords to do something specific like suppress/enable output on a module by module basis)

Level 0 - kNoLevel is only on the C++ side and not currently in the Python side
Level 1 - kDebugDumpLevel
Level 2 - kWarningLevel
Level 3 - kErrorLevel
Level 4 - kAssertLevel (calls PtAssert() - not used anywhere that I could find)
johnsojc
 
Posts: 246
Joined: Sun Dec 07, 2008 10:27 am

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

Postby Tsar Hoikas » Tue Sep 03, 2013 2:17 pm

johnsojc wrote:Please point to "where".


I assume you mean where game scores should be stored? There was new infrastructure added in MOUL for scores, see ptGameScore in the H-uru codebase. I had to rewrite a fair portion of the API because the original implementation blocked on server responses (so the code for a Cyan client will need to be different).

I'm not really sure I have much more in the way of suggestions for debug printing. I'll ask some of the other guys to offer their take.
Image
User avatar
Tsar Hoikas
Councilor of Technical Direction
 
Posts: 1898
Joined: Fri Nov 16, 2007 9:45 pm
Location: South Georgia

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

Postby johnsojc » Tue Sep 03, 2013 3:13 pm

Storing heek scores in a chron or in the scores table isn't really important. The problem is extracting the score data for all your hoodmates and resorting the top 10. When the code for getownerid() went away, it only broke the update to the hood imager. There was no way to attach a name to the score any longer. Everything else still seems to work. I've wracked my brain trying to come with some way to do it but the best I can do is append my score to the existing textnote. I supposed the textnote could be grabbed, enumerated, split, and sorted for the top 10 scores but that does not take into account removing members who left the hood for another or recent score updates from any other player. In any case, I've given up on trying to fix it for now... I just don't know enough Python or understand what Plasma can do well enough yet.

So, all I have left that I can work on is making the debug environment useful. With nearly half the statements not properly identifying the correct module/function it originated from made the logs somewhat useless.
johnsojc
 
Posts: 246
Joined: Sun Dec 07, 2008 10:27 am

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

Postby johnsojc » Thu Sep 05, 2013 12:51 pm

Should you all decide you would like to be able to turn debugging on/off at the module level, I have found a way to do it. The solution also lends itself to enabling individual debug statements even if the module debug output is turned off. I do have to redefine the PtDebugPrint function and edit all 264 of the python files but I'm getting used to that :lol: .

Essentially, I would have to add a positional argument in the function call:
def PtDebugPrint(dbg_on, *msgs **keywords) where dbg_on is a bool and set True/False in each module.
To override the module debug output being off, you just have to make the first arg = 1 which will allow that statement to print.
And you can always just use print() if you are in a hurry.

If I understand variable scoping correctly, this would not enable the debug on any imported modules... I would have to actually set up a test to check this. I estimate it would take me about 4 hours to actually implement this.

(New thing learned today... mixing positional, arg lists, and keyword args all in the same function).

EDIT: By adding another arg, I could also create any user-defined error level you might like and totally disable the original levels.
johnsojc
 
Posts: 246
Joined: Sun Dec 07, 2008 10:27 am

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

Postby johnsojc » Thu Sep 19, 2013 11:09 am

I've been diddling with some of the scripts and (the good news) I've managed to get most of the Wall code to work on a dirtsand server. It is in very rough shape and will take a lot of cleanup work since I sourced most of the ideas from about 3 or 4 other solutions (thanks to everyone who worked on this!).

(The bad news) I ran into the bug where once your avvie starts to climb the wall, you fall down a few feet and the client crashes. The only error I got was from the server code which I've seen before when using flymode to travel about the climbing walls:

Code: Select all
[Factory] Tried to create unknown type 0451
[Game] Warning: Ignoring message: 026B


I will try to find the references to the Wall bug again... I suspect the server messages are a bit more esoteric to unravel their cause. I'm not sure they are related but one never knows.
johnsojc
 
Posts: 246
Joined: Sun Dec 07, 2008 10:27 am

Previous

Return to Plasma Development

Who is online

Users browsing this forum: No registered users and 1 guest

cron