It seems that all SD unit graphics are located in mainSD.anim, which cannot be edited until we have an anim compiler. Will the game just use the graphic located in the anim\ and HD2\ directories in the event of no SD graphic change, or will it display the old, unedited one, since mainSD.anim isn't edited?

My guess would be that if there is no change at all to the file it will always use the original one. Just like if you do not mod your units.dat the game will just use the original units.dat.

Right, editing SD sprites requires editing mainSD.anim, I don't believe there's a way to trick the game into using the separate anim files for SD images.

Samase `panics` if you add more button sets than the default number.

Fixed, thanks for reporting.

With Blizzard's EUD/CCMU changes coming soon, is it safe to expect some downtime for samase, or is it impossible to know?

Hard to say.

It's likely going to be a large patch, and many changes obviously increase the risk of the offset analysis breaking or data structures changing. Technically there isn't anything related to EUD/CCMU that directly breaks samase, so it also may work perfectly fine.

Though the patcher is also flexible in that if the analysis fails to find the offsets required by Firegraft, any mod that doesn't have a Firegraft patch can still launch.

I'm also becoming acceptably quick at working with new/future patches, so hopefully even if something breaks it doesn't take long to fix.

Is there a command to unpack exes compiled with samase?

`samase --unpack <exe> <out_dir>` should work? Note that it'll override any existing files of same name in the output directory.

Edit: Nvm it works, didn't have the latest version

Post has been edited 1 time(s), last time on Jan 14 2018, 12:02 pm by Nekron.

Error when running a samase exe on linux. I assume this is to be expected?

No, I'll try changing some things that could fix it, but hard to say what's the issue there.

Moose was the user, maybe he can do some additional testing at our behest.

I'm getting the following message with the latest version of SC:R:

---------------------------
Samase panic
---------------------------
Panic at samase_ad\src\lib.rs:634
Ad version is not supported
Backtrace:
0x53ea0303 "samase_1dc3556212f34a67005aaa12551d542f0d739533.dll" 0x53e00000 -- rust_eh_personality
0x53e3df61 "samase_1dc3556212f34a67005aaa12551d542f0d739533.dll" 0x53e00000 -- Initialize
0x53e44151 "samase_1dc3556212f34a67005aaa12551d542f0d739533.dll" 0x53e00000 -- rust_eh_personality
0x53e42b41 "samase_1dc3556212f34a67005aaa12551d542f0d739533.dll" 0x53e00000 -- rust_eh_personality
0x53e44336 "samase_1dc3556212f34a67005aaa12551d542f0d739533.dll" 0x53e00000 -- rust_eh_personality
0x7721cbef "ntdll.dll" 0x771e0000 -- RtlDeactivateActivationContextUnsafeFast
0x77275297 "ntdll.dll" 0x771e0000 -- RtlCaptureStackContext
0x77288ded "ntdll.dll" 0x771e0000 -- RtlCaptureStackContext
0x772438aa "ntdll.dll" 0x771e0000 -- LdrInitializeThunk
0x7724378e "ntdll.dll" 0x771e0000 -- LdrInitializeThunk

---------------------------
OK
---------------------------

The attached file is out of date, try this

The attachment is reported as Trojan:Win32/Fuery.B!cl . (2018/06/24 ver. samase_0.5-beta20.exe)
There must be something wrong with current attachment , maybe it's polluted by some hackers. Please fix this.

Modding tools and mod executables are frequently incorrectly flagged as trojans. The technique they use to inject the mod plugin is the same way many viruses work, and the AV program can't tell the difference.

Edit: nvm

Nice work!

Post has been edited 1 time(s), last time on Jul 11 2018, 11:55 am by lucifirius.

Updated to work with 1.22.1.

I had to break compatibility with older versions to get this done reasonably quickly But guess nobody cares since blizz pretty much forces people to use the newest SCR patch anyway.

Updated to work with the latest patch. (Hopefully?)

SCR just keeps slightly changing the way files are closed, everything else samase relies on has stayed pretty much stable between last ~20 patches >:l