scient replied

[scient]

Well, after this patch release I don't really plan on making another. If anything, I like PlotinusRedux idea of injecting dll. I want to focus solely on decompilation project since my time is pretty limited as is. I don't really feel like dealing with patching at ASM level anymore beyond some simple testing. Some of patches I did in my unreleased update were quite a pain to do. Especially the one getting the unused pcx for resource pops/disappears to display correctly.

However, I am happy to provide all info regarding my patches and the setup for NSIS installer so merging with Yitzi's patch is seamless.

[Buster's Uncle]

Did anything ever get done with that negative resource graphic I did up for you five+ years and several forums ago?

[Yitzi]

Indeed.. . I'm up for playing project manager and filling in bits of any non-art non-programming jobs that need doing, testing, bug organization, writing, suggestions, etc...

If you're talking about the possibility of an unofficial sequel, writing is not going to be a "filled-in because it needs doing" job; that seems to be the approach BE took to writing, and that's why it's not a proper sequel to SMAC.

[scient]

No, I still have it somewhere tho. 

The problem was a limited heap space (memory) inside the binary to store info after parsing pcx. This could be solved by redirecting offsets to injected dll. Patching it in binary itself would be complicated. Both methods would be a pain to implement. Another reason decompiling the exe is a good idea. There are many things hardcoded that are difficult to work around without extensive patching.

[Buster's Uncle]

Okay.  [sniffles]

Indeed.. . I'm up for playing project manager and filling in bits of any non-art non-programming jobs that need doing, testing, bug organization, writing, suggestions, etc...

If you're talking about the possibility of an unofficial sequel, writing is not going to be a "filled-in because it needs doing" job; that seems to be the approach BE took to writing, and that's why it's not a proper sequel to SMAC.

I think we can cover writing, though.  Rymdolov is scary good, and I've dashed off a few pieces of AC fanfic I'm not ashamed of...

[ete]

Okay, so approximately this plan:
1. scient provides his patch and notes, Yitzi merges them (?)
2. scient and Plotinux post their IDA data then merge their current decompilations to a repository I'll set up and incorporate research by Yitzi and Dio to speed up decompilation, I try and get kyrub's data to add into the mix
3. Yitzi & Dio either join in the decompilation project and work with C++ for their modifications or continue to patch directly, leaving hooks for the .dll guys to work from?
4. As functions are drawn into the .dll more and more becomes easily moddable until finally the original exe is unnecessary
5. We make an awesome sequel complete with bells and whistles (may take another 15 years)

Indeed.. . I'm up for playing project manager and filling in bits of any non-art non-programming jobs that need doing, testing, bug organization, writing, suggestions, etc...

If you're talking about the possibility of an unofficial sequel, writing is not going to be a "filled-in because it needs doing" job; that seems to be the approach BE took to writing, and that's why it's not a proper sequel to SMAC.

I can write fairly good stuff if I apply myself. It's not my favorite part of creating things, but it'd not be half-arsed. Of course I'd rather have others doing the bulk or the writing, organization is what I most enjoy.

[Sigma]

Writing is probably the only thing I could contribute to a project like this, but I'd love to have a hand in it.

[scient]

Actually, rather than wait two weeks if Yitzi or whoever would like to merge my patch that would be great. Releasing a stand alone patch just splitters the patches even more and since Yitzi has been doing the majority of patch work merging the new patches into his sounds like the best solution. Especially since I don't plan to continue releasing patches.

I highly recommend using NSIS to create a single click installer. I have included the NSI script along with all the comments. This allows for managing all the related files besides just the exes such as the various languages for text files and ability to update registry among other things. I tried to make clear comments for each section, but more than happy to explain anything.

I have a mix of various text files by Guv. The ones I have packaged as part of my patch are not the latest. I believe the ones in "final_update_txt.zip" are the final set he sent me via email. I didn't merge them together so folks can see. However, some kind of unified text files would be a good call. He did a LOT of work updating and cleaning up the stock ones.

Also, inside my patch files I included my internal patches.txt I use to locate specific patch data to speed up applying them to binary. Actually, I don't think I ever applied Kyrub's patches to my binaries. However, everything else should be there. I tested all my patch code extensively.

My readme includes detailed explanations of all the patches and what they do.

Enjoy. I should of shared this sooner with the community.

[ete]

Makes sense. Okay, I'll move checking and merging the text files to top priority (my copies have a handful of changes he'd not included, though his work is based on mine so he's got most of my changes already). I've also found a fair number of things changed that probably shouldn't be (e.g. removing a load of alien dialogue which should be edited instead), it needs a bit of review. I should have them ready to bundle in the next couple of days .

[Buster's Uncle]

Does anyone know what the deal with Guv is?

I miss Guv.

[scient]

I have his email but haven't talked to him in over a year. The last email I got was with those text files and that was it.

[PlotinusRedux]

I'm curious what the issue was, I tracked it down to a function UV2Player::play that has calls to old direct x (4 or 5) functions starting at offset 0x4BF4B0 in SMACX exe. However, I never went further from there.

For SMAC, basically DDraw always got initialized in the movie code with SetCooperativeLevel(DDSCL_FULLSCREEN | DDSCL_EXCLUSIVE) and no fallback.  It got reinitialized in the later start up code with a fallback to DDSCL_NORMAL.  Out of exclusive mode, the code has to be able to handle no automatic back surfaces and no flip, which the main code did handle by manually creating back surfaces and using Blt() instead of Flip() in that case--or even not using DDraw at all if you had the .ini configuration.  The movie code, on the other hand, used DDraw regardless, and if you try to set DDSCL_NORMAL on it, it would crash the first time it tried to access the automatic backbuffer.

If the movie played, the main code inherited the DDSCL_EXCLUSIVE from the movie code even if the main code wasn't using DDraw because they used the same window handle.

I've got ALT-TAB working plus instead of minimizing it runs on a sizeable window outside of full screen.  For the movie fix, I was looking at using the open source ffmpeg library which can actually read the format directly, when I hit on a an absurdly simple solution:

Code: [Select]

void __cdecl PRACXShowMovie(const char *pszFileName)
{
PROCESS_INFORMATION pi = { 0 };
STARTUPINFO si = { 0 };
char szCmd[512];
int i;

strcpy(szCmd, ".\\movies\\playuv15.exe -software ");
strcat(szCmd, pszFileName);

i = strlen(szCmd) - 4;

if (i > -1 && szCmd[i] != '.')
strcat(szCmd, ".wve");

m_fPlayingMovie = true;

if (CreateProcess(".\\movies\\playuv15.exe", szCmd, NULL, NULL, false, CREATE_NO_WINDOW, NULL, NULL, &si, &pi))
{
WaitForSingleObject(pi.hProcess, 2 * 60 * 1000);
CloseHandle(pi.hProcess);
CloseHandle(pi.hThread);
}

PostMessage(*m_pAC->phWnd, WM_MOVIEOVER, 0, 0);
}

To the user, the effect is indistinguishable from the video being played by the app itself--and since playuv15.exe uses it's own window handle, it doesn't screw up the game's window.

[ete]

I can have a go at reviving Guv, I bet he'll love the switch to github.

[Buster's Uncle]

I vote in favor.

[ete]

On my to do list. Will probably happen tomorrow.