Crash when casting spell

[Dgc2002]

Crash when casting spell

[token419]

I happened to be tinkering around with this the other night because I just ran across this neat app and encountered the same issue while digging around to see if i could expand on the triggers to get a little more "gina" like.

I believe this and #62 may be related to the current master branch, which appears to be qt6 (which is not the release version, that version is the stable/qt5 version it looks like).

I was able to resolve this by changing the "parsers/spells.py" on line 320 from progress_layout.insertStretch(2, 1) to progress_layout.insertStretch(1, 1) in the master qt6 version.

So far after making that change on python 3.12 on windows 10 everything seems to be running fine locally for me now and the spell window no longer crashes the app, but I haven't tested much further as I was only tinkering around.

Though it is worth mentioning, as I was investigating as well, it looks like the "stable/qt5" branch is a few commits ahead and also appears to be where the releases are coming from.

I'd be happy to submit a pull request if this resolves the issue for others as well, but being as this isn't the branch being released, and it's a few commits behind, I'm not sure if it's still active.

[token419]

It's also worth mentioning when I loaded the stable/qt5 branch i was getting crashes also, but I believe they are unrelated. I was also able to get that version running in python 3.12 on windows 10 as well. I had to remove the pinned QT5 requirement in the requirements.txt and used the newest version, then some items needed to be specifically casted to INT's (This work was already done in the master/qt6 version mostly).

I'd also be happy to submit a pull request for that as well if needed/wanted if the goal is to keep the QT5 branch living on also since it appears to be where the current commits/releases are coming from.

[Dgc2002]

I believe this and #62 may be related to the current master branch, which appears to be qt6 (which is not the release version, that version is the stable/qt5 version it looks like).

The crash happens in the release and master branch version for me.

I was able to resolve this by changing the "parsers/spells.py" on line 320 from progress_layout.insertStretch(2, 1) to progress_layout.insertStretch(1, 1) in the master qt6 version.

I still experience crashes on the master branch after making this change. I haven't tried it on 3.12 though.

It seems pretty unpredictable at points. Sometimes wiping my log directory works. Other times I can just relaunch and it seems to be fine for hours.

I'm not digging into the crash dump of every individual crash to verify it's the exact same crash so it's possible I'm experiencing separate issues but at this point it all seems to be when I cast a spell.

[token419]

Ah for sure, yeah the issue I was experiencing was a hard crash upon the first buff I cast. Like if I cast a self buff, the app immediately crashed. I did notice though that upon starting the app, i did have to hail once before it would catch the spell cast. Also I fat fingered previously, it was line 330, but yeah the value was the change that mattered heh.

I just pulled down master again just to verify. Here's my pip freeze just in case some dependencies got updated too or whatnot:

charset-normalizer==3.3.2
colorhash==2.0.0
darkdetect==0.8.0
idna==3.6
pathvalidate==3.2.0
PyQt6==6.6.1
PyQt6-Qt6==6.6.2
PyQt6-sip==13.6.0
PyQt6-WebEngine==6.6.0
PyQt6-WebEngine-Qt6==6.6.2
PySide6==6.6.2
PySide6_Addons==6.6.2
PySide6_Essentials==6.6.2
requests==2.31.0
semver==3.0.2
shiboken6==6.6.2
urllib3==2.2.1
websocket-client==1.7.0
websockets==12.0```

[rm-you]

@Dgc2002 @token419
Hey! Yeah, you hit the nail on the head here at every point.
Yes, the releases are coming from the stable/qt5 branch. The reason for that was I couldn't figure out why spellcasting was crashing it, as I similarly couldn't get any breakpoints to fire. Since I maintain this in my very limited free time, I kinda gave up for a while on the qt6 upgrade.

I'll test out the change you mentioned, or please do feel free to make a PR, I was just talking to someone else about trying to solve this issue again and noticed you may have figured it out. I will port the other changes into this branch soon so it will be up to date with the latest release.

Thanks for taking a look! You can also hit me up on Discord, I honestly only saw this issue by pure chance -- I'm rm_you and I'm in a bunch of P99 guild/tools discords.

[token419]

For sure, happy to help out! Thanks for keeping your work in the open so I had a codebase to play with! Honestly, from me to you, without your work being in the public, specifically the PyQT6 port commits, I wouldn't have even touched the project! I know nothing of QT in general and haven't been programming regularly in awhile, let alone with python.

I'll defer to you on merging/rebasing the 2 branches back together but would be more than happy to help as well if needed/wanted. I just don't want to build a massive pull request on one side or the other to get the branches up to date and then have my user tagged with all the commits for work you've already done!

I thought the project may be dead so I had actually just gone through every version of the codebase across all the forks and chose Nomn's 0.5.1 version to play with locally (I just used the source from the release page). I'll be honest, I specifically chose 0.5.1 because I had 0 personal interest in the location server. I got the old codebase working on python 3.12 and Pyside6 instead of PyQT6.

But since the project is still alive, I'd be happy to combine efforts. In the end I may still go my own route, but there's many things that can still mutually benefit us both.

Below are just some random though about my goals as well as what I've observed in the code:

• Swap PyQT6 for Pyside6. After my initial research into QT land, I think Pyside6 would be a better library than pyqt6 simply because they are maintained by the QT company itself. LUCKILY the port from PyQT6 to Pyside6 was just changing 1 or 2 calls, so ez wins if you end up wanting to go that route as well.
• Swap out the "config" portion of the code (loading/saving of settings to disk) to use QSettings. Qsettings is built into QT and handles multiprocessing/threads.
• Change Version Check calls to point to the Github api for the project releases. Update checks are still happening to personal servers for version checks where github has an api for that. i.e. check the "name" from: https://api.github.com/repos/nomns/nparse/releases/latest
• Investigate Travis integration for building the windows.exe and creating releases automagically.
• Profile the app, I know nothing about profiling in python and this would be a great learning opportunity. This would help me determine a baseline for the current application and give us a performance baseline that we can compare against as releases go forward.
• Investigate separate Multiprocessing/Threading for any code that is not GUI related, i.e. the logparser, parsing and the websocket server.
• Separate out as much GUI code from the Application Logic as possible. My initial thoughts are just to make a "man in the middle" function just runs the original function with its args, but also inserts a pause so as to deadlock the GUI thread and create a very noticeable pause if the function is in the GUI thread :p
• Investigate porting the apps from QT Widgets to QML. Most of the QT Widgets functionality can be achieved in QML with QT Quick currently. In my very limited testing it does look like everything being done here could be done there.

[rm-you]

Resolved in #70
Thanks @token419