The game doesnt start about naikari HOT 13 CLOSED

OK, I've found a promising possible cause: it looks like there was a typo in the Meson build script connected to physfs (which is used by Naikari to load data). It's a promising possible cause because the game crashes in between two log entries where the only thing that happens is some calls to physfs to do some things.

So to that end, I've pushed a release candidate which I think might fix the bug. Could you please test this and let me know if it runs? If so, I'll push this fix out as a 0.2.1 release right away.

https://github.com/naikari/naikari/releases/tag/v0.2.1-rc.1

🕵️

from naikari.

Alright, thanks for checking. Back to the drawing board, then.…

Something I've already noticed is that the bug is not reproduced when I use Wine. My girlfriend suggested at one point that it could be specific to Windows 11, which does seem plausible. What I do know is that it's very unlikely for Naev (the project we forked from) to be affected by this bug, given that it has a much larger userbase than us and that Naev 0.9 has easily been out long enough for a problem as serious as this to be reported by now.

I still suspect that the problem is likely physfs related, since not much happens between the last log that gets printed and the next log that should get printed and most of that code is interacting with physfs.

🕵️

from naikari.

OK, I think I may have made another possible breakthrough. I noticed that there was a syntax correction to one of the Windows build files several months ago upstream which is for a forced fallback on SuiteSparse (something that IIRC physfs interacts with). I've pushed out another RC:

https://github.com/naikari/naikari/releases/tag/v0.2.1-rc.2

Hopefully this might make it work? Please do let me know, I would really appreciate it.

🕵️

from naikari.

Changing languages makes the game crash? Huh, that's interesting. As it happens, another piece of code between the last log and the next log is a line that chooses the language to use, so that makes me wonder if the two problems might be related. This makes it occur to me that one major difference between Naev and Naikari that might be significant is that Naev doesn't use pgettext, while Naikari does. I don't know if that would affect language loading at all, but it could be possible.

Thank you so much for your help and patience with this problem. I'll take a closer look at the language connection and report back if I discover anything of note. 🙂

🕵️

from naikari.

OK, so this is somewhat a shot in the dark, but looking at the gettext code, I noticed that there was a commit to Naev a while back that seems to protect against a segmentation fault. The potential segfault was a little weird and connected to whether or not the environment variables for gettext were set, but it does seem like at least a plausible cause for something like this.

I think the next nightly (which incorporates that upstream fix) should be up by the time you wake up, and for good measure I've also pushed another release candidate incorporating the change as well. I apologize for the trial-and-error nature of my attempts to fix this problem, it's how it would normally go except normally I'm able to reproduce on my end and so can do the testing myself. 😅 In any case, attempt 3 can be found here:

https://github.com/naikari/naikari/releases/tag/v0.2.1-rc.3

If that doesn't work, I'll have to figure out some way to do some more intensive investigation since I think that's probably the last "issue that was fixed months ago by upstream" hole (most likely by pushing out a nightly with a whole bunch of debug prints all over the place), but we'll cross that bridge if we get there. Fingers crossed!

🕵️

from naikari.

Wow, that's quite bad! Thanks for reporting. I don't have a Windows machine to test on myself, but my girlfriend who does have windows confirmed the presence of the bug. Strangely enough, the nightly apparently runs normally, so it may have been accidentally fixed after the 0.2.0 release, or it could simply be that the nightly is built with different parameters than the release candidate. Will investigate this further.

🕵️

from naikari.

Hey person, thanks for the quick response. Sadly i have to tell you that the problem is still there, also with the same stuff in the command line as i showed in the picture.

from naikari.

I dont know if that helps anything at all but the same happens when i try to use compat. modes of any kind. Im indeed using win11 though.
Also i dont know if thats from importance, i dont know anything about programming, but the directories(?) shown in the console have \ and /. It looked strange for me since im only used to \ regarding directories. But what do i know.
Just thought right now, i maybe should mention it.

from naikari.

The paths should be fine. One thing my girlfriend confirmed is that this bug doesn't seem to affect the nightly build, and they showed me a log from a successful launch on their Windows machine of the nightly build. It had the same path directories (including the double-slash at one point), so it seems that's fine. (Windows does support POSIX-style forward-slashes; the only restriction is that they can't be used if the meaning is ambiguous with DOS-style forward slash command-line arguments.)

I looked at the commits between version 0.2.0 and the nightly and didn't see anything that I would expect to affect a bug like this, so right now my best guess is that the source of this problem is in the build process, or possibly the Windows installation process. The nightly build is a "debug" build, and the prerelease is a "debugoptimized" build, so it could be that being built in debug mode is causing a problem to be masked (which, if so, would indicate that something is being done very wrongly).

I appreciate your assistance. If you notice anything else that might be helpful for tracking the cause of this bug, do let us know. Every bit of information counts. 🙂

🕵️

from naikari.

Hello! The problem still exists, still the same outcome. But i can confirm that the nightly build runs just fine.
(performance wise naev is a mess for some reason on my computer, your build (nightly) runs wonderfully.)

I dont know if i should make another ticket, but what i noticed in the nightly build is changing languages makes the game crash.
But i guess its better to focus on the startup problem right now.

I will go with you through that 'til its working though, just have to say that i have to sleep now. Its 1am here hehe.

from naikari.

Hello again. I can say that the game is starting and even changing languages works as intended.
Dont worry about your way approaching things, we got somewhere, so it cant be the wrong way! (:
Great Job man!

from naikari.

Fantastic! I'm happy to hear that! 😄

Just started the process to push out version 0.2.1, so the full release should appear on GitHub soon and then we'll put the release on itch.io and GameJolt and close this issue. Thanks so much for your help through all of this! 😄👍

🕷️

from naikari.

Alright, we were delayed a little bit by some errands and such, but we've pushed out the 0.2.1 release. 🙂

🕵️

from naikari.