Neiv, thank you!
It works great!
I've been struggling with BWMetaAI today and I'm just totally happy.
Cheers!
Attachments:
None.
Hello good ppl and Neiv,
I'm trying to make this work for v 1.23.9.10756 but samase doesn't even launch (it seems like it does for a split second, then it crashes with no error message).
Am I doing something wrong or this version is not supported?
Thx in advance!
None.
Do you mean the mod or samase.exe?
Trial and error... mostly error.
Sry, should've been clearer.
Was trying to make this work:
Get Samase
Get aiscript.bin from BWMetaAI's releases
Make the directory layout like this:
StarCraft\x86\StarCraft.exe
StarCraft\x86\semase.exe
StarCraft\x86\custom\scripts\aiscript.bin
Make a shortcut to sasame.exe and add custom as a command line parameter.
Run StarCraft using this shortcut
But when I launch the samase.exe shortcut, nothing happens.
None.
You run samase from the commandline
cd to the directory samase's in ->
samase.exe C:\samase\foldername --pack C:\samase\executablename.exe
I was referring to the method detailed here:
https://github.com/jncraton/BWMetaAI (under installation paragraph), which apparently should run through a shortcut, is this not viable anymore?
None.
Oh that will just run without saving an executable from the /custom/ folder. You can try running this from a .bat file to check if there is an error that pops up, assuming the same folder structure JNCraton gave:
:retry
samase.exe C:\x86\custom\ || pause
if errorlevel 1 goto retry
thx for the tip Nekron, tried it, same result. no error message, it simply wouldn't run
None.
Neiv, is the source code of Samase publicly available?
Wondering since having this tool open source'd would boost mod development for SC:R IMO
None.
SCR spawned by samase crashes under wine/linux randomly (even when using an empty dir).
It would be helpful if source code is available or backtrace and detailed tracing log are available.
Post has been edited 1 time(s), last time on Jun 15 2024, 12:04 am by myocytebd.
None.
The source code isn't available so that people wouldn't repurpose it for hacks. I wouldn't mind a setup where only the process initialization code is kept closed source with the remaining 99% being available, though it would take some time to reorganize the code for that.
SCR spawned by samase crashes under wine/linux randomly (even when using an empty dir).
It would be helpful if source code is available or backtrace and detailed tracing log are available.
Do you mean that it sometimes works under wine? My impression was that wine doesn't support the process creation method samase uses at all. Moving samase to use same wine-compatible SC:R injection code that ShieldBattery uses is on my list of things to do, though not sure when I'll manage to get to working on that.
None.
The source code isn't available so that people wouldn't repurpose it for hacks. I wouldn't mind a setup where only the process initialization code is kept closed source with the remaining 99% being available, though it would take some time to reorganize the code for that.
SCR spawned by samase crashes under wine/linux randomly (even when using an empty dir).
It would be helpful if source code is available or backtrace and detailed tracing log are available.
Do you mean that it sometimes works under wine? My impression was that wine doesn't support the process creation method samase uses at all. Moving samase to use same wine-compatible SC:R injection code that ShieldBattery uses is on my list of things to do, though not sure when I'll manage to get to working on that.
Thanks. I was trying to use Samase with an "offline" release of SCR 1.23.10, but since they use a patched ClientSDK.dll + Offline.dll, Samase isn't able to find the correct memory addresses/offsets I believe. Was thinking of modifying it myself if source was available, to enjoy a true offline experience (No 30 day login or ban risk) with mods though Samase.
None.
SCR spawned by samase crashes under wine/linux randomly (even when using an empty dir).
It would be helpful if source code is available or backtrace and detailed tracing log are available.
Do you mean that it sometimes works under wine? My impression was that wine doesn't support the process creation method samase uses at all. Moving samase to use same wine-compatible SC:R injection code that ShieldBattery uses is on my list of things to do, though not sure when I'll manage to get to working on that.
It is like this:
- 100% working to launch the game and start a map;
The CASC overriding does work.
- After some random time, SC:R freeze (more common) or crash during a map play. Usually on the magnitude of 5-15 minutes. (If the game is short enough, then SC:R can survive to map result screen and start a new map).
samase's crash logger does not catch this freeze or crash.
(I don't even know whether the fatal originated from win32 land or wine itself. wine has no doc for debugging, and documented trace env vars are broken.)
- 'samase-0.8.31.exe empty_dir [--log]' can reproduce the crash. (no plugin)
So I guess it is more likely that some hooked implementation dislike wine. The injection/hook itself should be fine, otherwise SC:R should die much faster.
(I didn't experience the freeze/crash with 'SC:R -launch' w/o samase.)
(If I recall correctly, wine improved process/PE compatibility before, maybe during 7.x)
Post has been edited 3 time(s), last time on Jun 23 2024, 9:53 pm by myocytebd.
None.
Thanks. I was trying to use Samase with an "offline" release of SCR 1.23.10, but since they use a patched ClientSDK.dll + Offline.dll, Samase isn't able to find the correct memory addresses/offsets I believe. Was thinking of modifying it myself if source was available, to enjoy a true offline experience (No 30 day login or ban risk) with mods though Samase.
Ah ultimately the part of initialization code where the cracked version breaks for some reason would be in the small part of code I would prefer not to release. Samase does not go out of its way to break unofficial exes though, and is able to patch exes that don't include the usual protection, so, idk, would just prefer if samase wouldn't have to be modified at all for pirated exes.
It is like this:
- 100% working to launch the game and start a map;
The CASC overriding does work.
- After some random time, SC:R freeze (more common) or crash during a map play. Usually on the magnitude of 5-15 minutes. (If the game is short enough, then SC:R can survive to map result screen and start a new map).
samase's crash logger does not catch this freeze or crash.
(I don't even know whether the fatal originated from win32 land or wine itself. wine has no doc for debugging, and documented trace env vars are broken.)
- 'samase-0.8.31.exe empty_dir [--log]' can reproduce the crash. (no plugin)
So I guess it is more likely that some hooked implementation dislike wine. The injection/hook itself should be fine, otherwise SC:R should die much faster.
(I didn't experience the freeze/crash with 'SC:R -launch' w/o samase.)
(If I recall correctly, wine improved process/PE compatibility before, maybe during 7.x)
Huh, if wine is able to get samase launch in a way that allows it patch the game they definitely have improved on niche windows compatibility.
Random crashing without crash handler running, and sometimes freezing definitely sounds like it's triggering one of the executable's protections that intentionally close the exe, often with int 29 so that the process exits without running any exception handlers.
I have one guess of where the cause could be without any other information, if you could run this build of samase with --log and post the log file after startup it may be helpful (Does not have to hit the crash). The zip also includes a 64-bit executable in case it changes anything and you have time to try it.
https://drive.google.com/file/d/1fOOZD3ib3xG5kRHLmg6dHp-YWoDP_4W5/view?usp=sharingBut other than the log it'd be most helpful to know which instruction in the exe (address, relative to image base) it exactly is freezing / crashing, not sure if you can attach a debugger on freeze to get that information out with wine or anything. Ruuning with `WINEDEBUG=+seh` may also help to get the information from a crash? Not sure if it works there.
None.
It is like this:
- 100% working to launch the game and start a map;
The CASC overriding does work.
- After some random time, SC:R freeze (more common) or crash during a map play. Usually on the magnitude of 5-15 minutes. (If the game is short enough, then SC:R can survive to map result screen and start a new map).
samase's crash logger does not catch this freeze or crash.
(I don't even know whether the fatal originated from win32 land or wine itself. wine has no doc for debugging, and documented trace env vars are broken.)
- 'samase-0.8.31.exe empty_dir [--log]' can reproduce the crash. (no plugin)
So I guess it is more likely that some hooked implementation dislike wine. The injection/hook itself should be fine, otherwise SC:R should die much faster.
(I didn't experience the freeze/crash with 'SC:R -launch' w/o samase.)
(If I recall correctly, wine improved process/PE compatibility before, maybe during 7.x)
Huh, if wine is able to get samase launch in a way that allows it patch the game they definitely have improved on niche windows compatibility.
Random crashing without crash handler running, and sometimes freezing definitely sounds like it's triggering one of the executable's protections that intentionally close the exe, often with int 29 so that the process exits without running any exception handlers.
I have one guess of where the cause could be without any other information, if you could run this build of samase with --log and post the log file after startup it may be helpful (Does not have to hit the crash). The zip also includes a 64-bit executable in case it changes anything and you have time to try it.
https://drive.google.com/file/d/1fOOZD3ib3xG5kRHLmg6dHp-YWoDP_4W5/view?usp=sharingBut other than the log it'd be most helpful to know which instruction in the exe (address, relative to image base) it exactly is freezing / crashing, not sure if you can attach a debugger on freeze to get that information out with wine or anything. Ruuning with `WINEDEBUG=+seh` may also help to get the information from a crash? Not sure if it works there.
I hope you don't mind that I have uploaded some logs in one of your github project for better formatting:
https://github.com/neivv/mtl/issues/1The 64-bit exe didn't freeze or crash over totally 40 min wall clock. It appears fixed or greatly improved.
What is the possible cause/fix/workaround?
None.