Script 'Win32API' line 3: RuntimeError occured.XD

[haidanQAQ]

I tried downloading a kernel.dll and putting it in that folder, but it didn't work.

[Splendide-Imaginarius]

Possible duplicate of #1? Also see #6 for a partial fix.

[ghost]

Essentials games that use any version pre-19 aren't supported, period. Not even on Windows. The list of things that would need to be changed is far too long, and requires many, many direct changes to the code.

If this is post-19 and this is the only issue, then you'll have to elaborate on exactly what is broken. Native code for Windows isn't going to work on macOS or Linux. You would need native ELF for linux and Mach-O for macOS.

[ghost]

...actually, I still have an old gist lying around if you want to try it anyway, but porting an old essentials game is a different issue entirely -- I helped fix it for 19 onwards.

(I should also note that this was with Ruby 1.8, not 3.1, so you have more things to change than this unless you build yourself with 1.8)

((Come to think of it, you can probably just get an old release that still has 1.8 and the bits of fake Win32API implementations that I used for debugging at the time, maybe check the link to my google drive in the releases. Won't make it easy, but it replicates the environment that I used then. I had implemented several Win32API functions internally at the time. They've been since removed because trying to replicate Windows wasn't and isn't the point of mkxp-z))

[Splendide-Imaginarius]

@strumajen I'm curious, did you implement much of the Win32API besides what's in #6 ? Seems like it wouldn't hurt to keep it around in a preload script, as long as it's well-segregated from the mkxp-z code itself (and presumably not enabled unless someone modifies mkxp.conf to use it). So far the contents of #6 are all that I've needed for the games I've tossed at it, but admittedly I haven't tried many games.

EDIT: That said, it's not clear to me whether what you implemented was actually useful for running real-world games or if it was just for debugging. If it's just the latter, then probably not much point in keeping it around. shrug

EDIT2: I think I misread, I originally thought you meant a preload script but reading again it sounds like you're talking about Win32API bits inside mkxp-z itself. If so, yeah, I don't see any reason to resurrect that. Sorry for my reading comprehension fail there.

[ghost]

Yes, in the beginning I emulated some of the more bothersome parts by returning internal function pointers, until I got around to writing in proper extensions to replace them.

Pokemon Essentials used to use Win32API extensively. Pretty much everything in mkxp-z is specifically there to replace something that used to require Win32API before. Besides the Steam parts, Essentials is pretty much exclusively what was used to write everything. I don't know too much else and have never really been given a reason to care, since supporting Essentials seemed to solve pretty much everybody else's problems in the process, for the most part, given how involved of an ordeal it was.

As far as things like preload scripts are concerned though, I still don't really know what to do with them. Ancurio made mkxp to be a "player", and preload scripts were one of the tools given for you to fix games yourself, as the person desiring to play a game that someone else made. mkxp-z though is more of a developer's tool, for someone to use with games that they themselves made, so my assumption is that you should be free to just port the game yourself (including Essentials; mkxp-z isn't a "Essentials Game Player" or an "emulator" like mkxp was originally supposed to be, it was made for Essentials and then Essentials was fixed up specifically to work with it from then onwards), and in that case, preload scripts feel kind of redundant.

It's not that I'm averse to the idea of keeping around extra scripts, it's just that I don't know if I want to go down the road of trying to 'fake' the functionality of certain environments beyond the sort of 'core' of RGSS, because if I were to, say, start emulating parts of Windows, it begins a slippery slope where then people assume all of their native bits must work, and mkxp-z isn't Wine -- somebody should just use Wine instead as far as I'm concerned, it would do a far better job and it already exists

[Splendide-Imaginarius]

It's not that I'm averse to the idea of keeping around extra scripts, it's just that I don't know if I want to go down the road of trying to 'fake' the functionality of certain environments beyond the sort of 'core' of RGSS, because if I were to, say, start emulating parts of Windows, it begins a slippery slope where then people assume all of their native bits must work, and mkxp-z isn't Wine -- somebody should just use Wine instead as far as I'm concerned, it would do a far better job and it already exists

@strumajen Yeah, I totally understand the concern about feature creep. Is a PR like #6 a problem from your perspective? AFAICT it's pretty minimal and self-contained (it's literally just a copy of Ancurio's preload script, plus a couple of similar tweaks to get it running on modern Ruby etc.), and isn't enabled by default, so I kind of assumed it wouldn't be an issue, but I'm curious if I've misjudged that.

Relatedly, are other features that are designed to enhance existing games considered to be problematic? I have a PR about 90% done (planning to submit soon) that enables high-res Bitmap replacement (playing existing games in 1600x1200 instead of the usual 640x480 is pretty slick). AFAICT such a feature wouldn't be useless for game devs (as a game dev it seems like a reasonable want to allow users to change the resolution), but it's definitely the kind of feature that frequently shows up in emulators, so I'm curious if you're averse to that kind of functionality. (Turned out to be pretty easy to implement, it wasn't very invasive to the codebase, and it was actually much much easier than patching the Ruby code of a game to get the same functionality -- I tried both approaches and eventually gave up on patching the game directly, especially because mkxp-z currently makes a lot of assumptions about tile size that are near-impossible to properly patch from the Ruby side, but are trivially easy to deal with in a mkxp-z patch.) Happy to start a separate issue if you want to discuss that feature in more detail.

EDIT: Actually yeah, I'm going to split the latter question into a separate issue (with a more useful explanation of the intent) so I don't hijack this one. Will file it shortly.