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

[johnsojc]

When I was looking for some little project to occupy my time, I considered trying to convert the scripts to Python3 but somewhere I read that PIL had not been updated to version 3 yet so I dropped that idea for now. it still would be a nice project to do but I really need to learn 2.7 first and get a better understanding of how all the pieces of the game work together. I'm still trying to figure out where the SDL variables that are causing the errors live. They seem to be in both the vault and in the PRP files and then there are local data sets for the internal client and who knows where else.

[Deledrius]

When I was looking for some little project to occupy my time, I considered trying to convert the scripts to Python3 but somewhere I read that PIL had not been updated to version 3 yet so I dropped that idea for now.

Plasma doesn't use PIL at all.

I'm still trying to figure out where the SDL variables that are causing the errors live. They seem to be in both the vault and in the PRP files and then there are local data sets for the internal client and who knows where else.

Hoikas has made a fix (well, at least properly ignoring what we can't fix in the data) for those: https://github.com/H-uru/moul-scripts/pull/71

[Acorn]

I just updated all my PCs to Windows 8

How many?!

[johnsojc]

When I was looking for some little project to occupy my time, I considered trying to convert the scripts to Python3 but somewhere I read that PIL had not been updated to version 3 yet so I dropped that idea for now.

Plasma doesn't use PIL at all.

resources.dat?

[Deledrius]

When I was looking for some little project to occupy my time, I considered trying to convert the scripts to Python3 but somewhere I read that PIL had not been updated to version 3 yet so I dropped that idea for now.

Plasma doesn't use PIL at all.

resources.dat?

Ah, well I can see why that is a bit confusing.

Plasma (the engine), and the Python scripts that it uses, do not use any third-party Python modules.

The script which builds our tiny portion of game data does. Technically speaking, that script is part of the game data build process and not the engine, so it didn't occur to me at all when you mentioned it (because it's entirely irrelevant to what you're working on). The version of the Python executable used to build resource.dat has no necessary connection to the libraries used in the process of building the engine. I just happened to use a Python script as the tool to render the images we pack into the resource.dat, and it is that automation script and that alone which relies currently on PIL. The ability to turn off building the resource.dat was added recently by Mystler as a CMake option as well, since you don't need to build a new one very frequently at all (if ever).

Ideally that entire process should be moved to a separate repository, but as we don't have much game data being built currently it would be quite lonely.


That said, however, in addition to updating the scripts to be compliant with Python3, I suspect the engine will need to be tweaked for API changes in the Python library as well. Both the scripts you're working on and the engine itself will need work done to keep in step with each other. This is not a relatively high-priority task at this time, but if someone is interested in doing it the work is welcomed.

[johnsojc]

That said, however, in addition to updating the scripts to be compliant with Python3, I suspect the engine will need to be tweaked for API changes in the Python library as well. Both the scripts you're working on and the engine itself will need work done to keep in step with each other. This is not a relatively high-priority task at this time, but if someone is interested in doing it the work is welcomed.

I would love to help with this project but it is painfully obvious to me that I simply do not know enough C++ or Python (of either version) to take it on. I can do the mundane work of cleaning up code style and troubleshoot some of these annoying little bugs... I have always been able to fix existing code whether I know the language well or not (an odd talent but there it is). I still need to figure out just how it all the parts work together. LOL, I'm even considering going back to college to take a few courses in "modern" programming languages (especially since the tuition is free for someone my age). It's hard to believe I was a professional programmer once but what I know is so totally obsolete now. My first professional program was actually written in machine language but I convinced the company to buy me a assembler program to make my life easier.

[johnsojc]

At this point, the only traceback error I am getting is for Sharper's Journal.

Code: Select all

(07/22 14:57:58) xJournalBookGUIPopup: deprecated journal format, using name 'Sharper'
(07/22 14:57:58) cPythJournalPickup - Traceback (most recent call last):
(07/22 14:57:58)   File ".\python\xJournalBookGUIPopup.py", line 111, in OnNotify
(07/22 14:57:58)     self.IShowBook()
(07/22 14:57:58)   File ".\python\xJournalBookGUIPopup.py", line 193, in IShowBook
(07/22 14:57:58)     if journalContents == U"":
(07/22 14:57:58) UnboundLocalError: local variable 'journalContents' referenced before assignment

Is there a specific reason this happens or is it something I could possibly look at trying to fix?

EDIT: OK, I know why this error happens. The question now is whether there is anyway to put the Journal contents in dirtsand or were you trying to change the way this journal works?

EDIT(again): Apparently one line was removed in H-uru's xJournalBookGUIPopup.py:

Code: Select all

        journalContents = "I'm an empty book"

        # compile journal text

[/color]If inboxChildList is an empty list, then the compile journal text section falls through without ever assigning any value to journalContents hence you get the UnboundLocalError.

[johnsojc]

Alas, I have found another bug in xAgeSDLBoolRespond.py. It occurs when you are viewing one particular screen on the control imager in Er'cana (the one where you can see the grinding wheels). On switching to that screen, value become 2 when it should only be 0 or 1. This make the tuple index go out of range and triggers a traceback.

Code: Select all

(07/23 18:46:58) ActScrollRight callback
(07/23 18:46:58) DEBUG: ercaControlRoom.ImgrView():	View = 1, and mode = exit
(07/23 18:46:58) DEBUG: ercaControlRoom.OnSDLNotify():	ercaCtrlImgrView = 2
(07/23 18:46:58) xAgeSDLBoolRespond.OnSDLNotify():	VARname:ercaCtrlImgrView, SDLname:Ercana, value:2, playerID:10104
(07/23 18:46:58) value=2
(07/23 18:46:58) ff=False
(07/23 18:46:58) avatar=<Plasma.ptSceneobject object at 0x18A7D6C0>
(07/23 18:46:58) cPythSDLRespOvenBtns - Traceback (most recent call last):
(07/23 18:46:58)   File ".\python\xAgeSDLBoolRespond.py", line 91, in OnSDLNotify
(07/23 18:46:58)     self._Execute(value, ff, avatar)
(07/23 18:46:58)   File ".\python\xAgeSDLBoolRespond.py", line 99, in _Execute
(07/23 18:46:58)     PtDebugPrint("xAgeSDLBoolRespond._Execute():\tRunning %s responder on %s ff=%d" % (resps[int(value)], self.sceneobject.getName(), ff), level=kDebugDumpLevel)
(07/23 18:46:58) IndexError: tuple index out of range

[/color]
Once this happens, none of the control buttons on any screen will display. The 4th, 5th, 6th and 7th lines above are print statements I added to try to figure out what is going on.

My first theory is that in the old script, the test is if value is TRUE. an integer value of 2 returns TRUE in if ageSDL[stringVarName.value][0]:. Your script uses the integer value of ageSDL[sdlName.value][0] as an index. On the one screen, ageSDL[sdlName.value][0] returns the value 2.

EDIT: OK, this little hack fixes the problem:

Code: Select all

        ageSDL = PtGetAgeSDL()
        value = ageSDL[sdlName.value][0]
        PtDebugPrint("xAgeSDLBoolRespond.OnSDLNotify():\tVARname:%s, SDLname:%s, value:%d, playerID:%d" % (VARname, SDLname, value, playerID), level=kDebugDumpLevel)
        if value:
            value = 1  # Hack to make value work properly as an index in _Execute()

This forces value to be in the proper index range... any value that is not zero is set to 1. It appears the value is only used to select the correct responder to run... it's actual value is irrelevant as long as it's either 0 or 1.

Perhaps you can come up with a more elegant solution. I put my hack in after the PtDebugPrint() so the actual value of ageSDL[sdlName.value][0] is displayed.

[johnsojc]

Is Ahnonay broken? I can't seem to get to sphere 4... The 2nd avvie can't get the spheres to rotate and I seem to have a phantom quab somewhere.

[Tsar Hoikas]

I just recently pushed fixes for sphere rotating issues, and there's also a pull request for invisible quabs on Dirtsand. (Though sometimes they just get stuck on ledges above the kill region)

That's Er'cana issue makes me want to strangle Cyan even more. I have a truckload of "real work" to get done, unfortunately