Report, edit, etc...Posted by ShadowFlare on 2006-09-19 at 14:50:36
I released a new SCMLoader version yesterday on my web site. Except for minor updates, such as bug fixes or support for new Starcraft versions, this will likely be the final version of it -- at least until FireGraft is released and when there is some type of integration with that. Besides that, basically every feature I had in mind for it is implemented in the current release. The list of changes for this release:
- Added support for Brood War 1.07, 1.10, 1.11b, and 1.12b.
- Checks for modified files related to graphics before forcing Starcraft to reload them; significantly reduces the load time of maps not containing modified graphics.
- A list of additional MPQ archives to load along with the scm/scx map may now be included. For example, this may be used to have optional graphics/sound/music packs which contain files that are not critical to actual gameplay.
- New executable for self-patcher which does not use MPQDraft and has its own new SCMLoader icon.
- Automatically checks for updates and notifies when a new version is available. (can be disabled)
- New configuration program which can change the update notification setting and will later have other options to configure.
- Now works properly with Data Execution Prevention in Windows XP SP2 and other Windows versions which use it.
- Fixed a crashing bug related to including a music\playlist.txt file in the plain list format.
- Fixed a crash that would occur when exiting Starcraft while running SCMLoader on Windows 9x.
Go download it now from my web site at http://shadowflare.samods.org/
Original SCMLoader Topic
- Added support for Brood War 1.07, 1.10, 1.11b, and 1.12b.
- Checks for modified files related to graphics before forcing Starcraft to reload them; significantly reduces the load time of maps not containing modified graphics.
- A list of additional MPQ archives to load along with the scm/scx map may now be included. For example, this may be used to have optional graphics/sound/music packs which contain files that are not critical to actual gameplay.
- New executable for self-patcher which does not use MPQDraft and has its own new SCMLoader icon.
- Automatically checks for updates and notifies when a new version is available. (can be disabled)
- New configuration program which can change the update notification setting and will later have other options to configure.
- Now works properly with Data Execution Prevention in Windows XP SP2 and other Windows versions which use it.
- Fixed a crashing bug related to including a music\playlist.txt file in the plain list format.
- Fixed a crash that would occur when exiting Starcraft while running SCMLoader on Windows 9x.
Go download it now from my web site at http://shadowflare.samods.org/
Original SCMLoader Topic
Report, edit, etc...Posted by Lord_Jeremy on 2006-09-19 at 15:05:11
I'm guessing that there's no chance for you to port even an older version of SCMLoader to Mac? It seems like it would be a daunting task, considering all the lib work it's based on...
EDIT:
Thinking again, I could probably do it myself, as long as you didn't use too much of the visually-oriented C languages. The only problem I might have is in linking it to the Mac equivalent of the Storm Interface Library.
EDIT:
Thinking again, I could probably do it myself, as long as you didn't use too much of the visually-oriented C languages. The only problem I might have is in linking it to the Mac equivalent of the Storm Interface Library.
Report, edit, etc...Posted by ShadowFlare on 2006-09-19 at 15:13:05
I have no experience with programming for a Mac. In addition to that, a great deal of the code is Windows-specific and one would need to figure out how to do it on a Mac to be able to port it. Of course, after getting the basic framework of it done, the rest would be easy to port. However, that "basic framework" of it would be the complicated part. Hmm, I actually wouldn't really even mind releasing the other parts besides that "basic framework" for it. That is, the parts other than what loads SCMLoader into Starcraft and takes control of certain Storm functions. If you could find equivalent code for a Mac, then it could work.
Report, edit, etc...Posted by Xx.Doom.xX on 2006-09-19 at 15:38:10
Great update. Obviously since of the patch.
Gj
Gj
Report, edit, etc...Posted by WoAHorde2 on 2006-09-19 at 17:21:55
Good Job.
Report, edit, etc...Posted by Lord_Jeremy on 2006-09-19 at 17:36:58
What I'm saying is that all the MPQ work could easily be relinked to Mac-equivalent libraries. IMHO The only really hard part would be any visual C (I have nightmares about that stuff). I admit I haven't even looked for source for this thing, but I'm assuming that you have no qualms in sharing :-)
Report, edit, etc...Posted by Pie_Sniper on 2006-09-19 at 19:45:15
SCMLoader is close sourced. I assume it's because people knowing how it works could be potentially dangerous?
Report, edit, etc...Posted by ShadowFlare on 2006-09-19 at 20:51:33
QUOTE(Lord_Jeremy @ Sep 19 2006, 03:36 PM)
What I'm saying is that all the MPQ work could easily be relinked to Mac-equivalent libraries. IMHO The only really hard part would be any visual C (I have nightmares about that stuff). I admit I haven't even looked for source for this thing, but I'm assuming that you have no qualms in sharing :-)
[right][snapback]563994[/snapback][/right]
[right][snapback]563994[/snapback][/right]
I actually didn't really use anything specific to the Microsoft compiler or header files. If I wanted to, I could compile it just fine in any other compiler for Windows (possibly would need minor modifications for some), just as long as the proper header files and import libraries were available. BTW, the compiler I used for the newest version is the one with Microsoft Visual Studio 2005.
Anyway, what I was talking about earlier about certain "basic framework" in SCMLoader that wouldn't work on a Mac is the code for injecting code into another process and hooking functions that are called by Starcraft. The rest shouldn't be too hard to port to Mac.
If you are serious about wanting to work on a version of SCMLoader for Mac, something I've heard of, called mach_inject and mach_override, might be useful. If you can get that or something else working to hook Storm functions called by the Mac version of Starcraft, then it would be possible to port SCMLoader to Mac, since that is one of the key requirements to being able to port it.
Basically, if you take out the parts of the code for injecting SCMLoader.qdp into Starcraft's process space and for hooking functions in Storm, there isn't really anything else that would take much work to port to any other operating system.
Report, edit, etc...Posted by Kookster on 2006-09-19 at 20:58:46
ive really liked this program since you first released it cudos , im curious tho what you me by firegraft compatible what it will do
, im curious tho what you me by firegraft compatible what it will doReport, edit, etc...Posted by ShadowFlare on 2006-09-19 at 21:05:54
Heh, after using SCMLoader on one of my older computers (to test it on Windows 98), I've found that the feature for "checking for modified files related to graphics before forcing Starcraft to reload them" is actually a significant feature for anyone running it on a slower computer. The forced reload I think took approximately 20 seconds on my older computer with a Celeron 1 GHz processor and 384 MB of PC100 SDRAM. So, that was definately something that should not be done when not needed.
BTW, it seems that FireGraft support probably won't be too far away, as long as FireGraft is released soon (which it kind of sounded like in the FireGraft thread).
BTW, it seems that FireGraft support probably won't be too far away, as long as FireGraft is released soon (which it kind of sounded like in the FireGraft thread).
Report, edit, etc...Posted by Lord_Jeremy on 2006-09-19 at 23:37:47
I'm going to address this one thing at a time:
That's good news! If it's not too much trouble, a list of what additional libraries you used (and where I could find them) would be very helpful.
I'm not sure I understand the true nature of this program. I can't imagine why it needs to access the Starcraft process, unless it's an inline editor. Let me rephrase that as a direct question: Does SCMLoader load the map and its extra data directly into the Starcraft process while it's running or does it just produce a "doctored" map? Based on what you've said I'm now getting the idea that it loads the extra data relevant to the map by hooking the Starcraft map loading functions (whatever they may be) and injecting your own data path. If this is true, then I need to go back to my C++ forDummies Idiot Mac Users book and hope it has a chapter for "Starcraft" because I have no idea how the executable functions in regards to map loading.
Damn straight! Those functions, while not the most ideal I ca think of, would certainly be the easiest to implement. I might have to do some research into the SCM/MPQ data fork, as I seem to remember those commands can't function with certain data formats (IE encrypted or non-linear data produces a lot of errors). And in case you didn't get my meaning by the "Damn straight" line, I finish what I start. If it is within my ability, I will port this.
I'd agree with you except... um... what is a ".qdp" and what does it have to do with the process tree? I'm hoping that it is the equivalent of a Daemon in that it's a background process that hooks onto other processes. Other than that, I see clear skies and smooth sailing ;-)
@Pie_Sniper:
Are you sure of this? While I agree with you that nasty things could result, Ms. Flare seems like a good example of the "sourceforge" type. I also doubt that she and I would be publicly discussing SCMLoader's inner working if she intended it to be closed source.
QUOTE
I actually didn't really use anything specific to the Microsoft compiler or header files. If I wanted to, I could compile it just fine in any other compiler for Windows (possibly would need minor modifications for some), just as long as the proper header files and import libraries were available. BTW, the compiler I used for the newest version is the one with Microsoft Visual Studio 2005.
That's good news! If it's not too much trouble, a list of what additional libraries you used (and where I could find them) would be very helpful.
QUOTE
Anyway, what I was talking about earlier about certain "basic framework" in SCMLoader that wouldn't work on a Mac is the code for injecting code into another process and hooking functions that are called by Starcraft. The rest shouldn't be too hard to port to Mac.
I'm not sure I understand the true nature of this program. I can't imagine why it needs to access the Starcraft process, unless it's an inline editor. Let me rephrase that as a direct question: Does SCMLoader load the map and its extra data directly into the Starcraft process while it's running or does it just produce a "doctored" map? Based on what you've said I'm now getting the idea that it loads the extra data relevant to the map by hooking the Starcraft map loading functions (whatever they may be) and injecting your own data path. If this is true, then I need to go back to my C++ for
QUOTE
If you are serious about wanting to work on a version of SCMLoader for Mac, something I've heard of, called mach_inject and mach_override, might be useful. If you can get that or something else working to hook Storm functions called by the Mac version of Starcraft, then it would be possible to port SCMLoader to Mac, since that is one of the key requirements to being able to port it.
Damn straight! Those functions, while not the most ideal I ca think of, would certainly be the easiest to implement. I might have to do some research into the SCM/MPQ data fork, as I seem to remember those commands can't function with certain data formats (IE encrypted or non-linear data produces a lot of errors). And in case you didn't get my meaning by the "Damn straight" line, I finish what I start. If it is within my ability, I will port this.
QUOTE
Basically, if you take out the parts of the code for injecting SCMLoader.qdp into Starcraft's process space and for hooking functions in Storm, there isn't really anything else that would take much work to port to any other operating system.
I'd agree with you except... um... what is a ".qdp" and what does it have to do with the process tree? I'm hoping that it is the equivalent of a Daemon in that it's a background process that hooks onto other processes. Other than that, I see clear skies and smooth sailing ;-)
@Pie_Sniper:
Are you sure of this? While I agree with you that nasty things could result, Ms. Flare seems like a good example of the "sourceforge" type. I also doubt that she and I would be publicly discussing SCMLoader's inner working if she intended it to be closed source.
Report, edit, etc...Posted by DiscipleOfAdun on 2006-09-20 at 13:21:32
Just because she tells you how it works doesn't mean you can't replicate it on your own. I know, I tried. I think her reasons for not releasing that framework code are the same as mine for FG's loader....but that's just a guess.
BTW, here's what I can answer for her, based on my understanding:
SCMLoader changes storm calls to load the maps. It also uses some internal functions to load/unload several files from an mpq. All the extra files are in the map(it's an mpq also). Basically, she changes the calls so the map is open and it looks in the map first.
A .qdp is an MPQDraft Plugin. It's a dll that is injected into SC's memory and is called by the injecting process. Basically, you'd be making a mac version of it.
BTW, here's what I can answer for her, based on my understanding:
SCMLoader changes storm calls to load the maps. It also uses some internal functions to load/unload several files from an mpq. All the extra files are in the map(it's an mpq also). Basically, she changes the calls so the map is open and it looks in the map first.
A .qdp is an MPQDraft Plugin. It's a dll that is injected into SC's memory and is called by the injecting process. Basically, you'd be making a mac version of it.
Report, edit, etc...Posted by ShadowFlare on 2006-09-20 at 14:46:08
QUOTE(Lord_Jeremy @ Sep 19 2006, 09:37 PM)
That's good news! If it's not too much trouble, a list of what additional libraries you used (and where I could find them) would be very helpful.
Besides Windows API functions and linking to some Storm functions, none whatsoever! The only place I really needed to use Windows API functions was in injecting SCMLoader.qdp into the Starcraft process; more on that further down. As far as I know, any other direct use of the Windows API wasn't really actually needed.
QUOTE
I'm not sure I understand the true nature of this program. I can't imagine why it needs to access the Starcraft process, unless it's an inline editor. Let me rephrase that as a direct question: Does SCMLoader load the map and its extra data directly into the Starcraft process while it's running or does it just produce a "doctored" map? Based on what you've said I'm now getting the idea that it loads the extra data relevant to the map by hooking the Starcraft map loading functions (whatever they may be) and injecting your own data path. If this is true, then I need to go back to my C++ for Dummies Idiot Mac Users book and hope it has a chapter for "Starcraft" because I have no idea how the executable functions in regards to map loading.
SCMLoader hooks 4 functions in Storm (only 2 of which are actually needed, though) and does various processing and occasionally changes parameters before passing the data to the real Storm functions. Those 2 that are needed are the ones for opening archives and opening files from archives. Also, as DiscipleOfAdun mentioned, it calls a couple of internal functions of Starcraft to unload/load some other stuff (iscript.bin, image.dat, GRPs, LO* files; things like that).
QUOTE
Damn straight! Those functions, while not the most ideal I ca think of, would certainly be the easiest to implement. I might have to do some research into the SCM/MPQ data fork, as I seem to remember those commands can't function with certain data formats (IE encrypted or non-linear data produces a lot of errors). And in case you didn't get my meaning by the "Damn straight" line, I finish what I start. If it is within my ability, I will port this.
Well, if you can get what I mentioned to be able to work and get it so that you are able to successfully hook the two required Storm functions (the ones we would call SFileOpenArchive and SFileOpenFileEx) and maybe even find (or have someone find) the addresses to those other two functions to call, then the rest will be easy in comparison, since it is mostly just C/C++ code and not a lot of calls to the Windows API, so not so hard to port.
QUOTE
I'd agree with you except... um... what is a ".qdp" and what does it have to do with the process tree? I'm hoping that it is the equivalent of a Daemon in that it's a background process that hooks onto other processes. Other than that, I see clear skies and smooth sailing ;-)
[right][snapback]564309[/snapback][/right]
[right][snapback]564309[/snapback][/right]
As DiscipleOfAdun mentioned, it is the file extension used for MPQDraft Plugins. It is simply a DLL with a different extension on the file with specific functions available in it for MPQDraft to call. Basically all of the code for SCMLoader gets compiled into SCMLoader.qdp. Though there are separate SCMloader.exe and SCMLoader_Configuration.exe files, they are little more than just custom versions of the program with Windows that is called rundll32. You can actually run SCMLoader's self-patcher and configuration apps directly using Windows' rundll32 with the commands "rundll32 SCMLoader.qdp,RunPatcher" and "rundll32 SCMLoader.qdp,RunConfigure" In addition, it still supports being loaded through MPQDraft, hence the .qdp file extension.
Hmm, as mentioned further up, the only place I actually needed to directly use Windows API functions was in injecting SCMLoader.qdp into the Starcraft process. This is specific to Windows and has no remote chance of working on anything else (well, possibly WINE if they implement it). In addition to that, the code for hooking functions is specific to Windows programs, even though it may not necessarily need to call any API functions at all to help with any part of it. It deals with things like the format of .exe files in Windows and some things with changing stuff in the actual compiled code as well. Anyway, those parts of the code most likely would be of no use at all to you, because of it being Windows and x86 specific.