Staredit Network

axblader> Warcraft III does not use any formats similar to Starcraft, Warcraft III is 3D, Starcraft is 2D. HUGE difference, NO compatibility.

Doodle77> The mod would be applied either during the lobby after the map downloads, or during the mission briefing. In both cases, the mod would be applied before the game starts. I still don't know what you mean by "server split" because no Starcraft game is hosted on Battle.net.

TheOddAngel> Mods are NOT huge, unless the creator doesn't know what he's doing.

Let's see the possibilities:
•All *.dat and *.tbl files are under 6kb.
•Cusor grp files are all less than 4kb.
•Pcx files range from less than 1kb(Player colours, font colours, etc) to 30kb(Consoles at bottom of screen). And most pcx files relate to the single player menu and battle.net backgrounds, which would be left unmodded.
•*.smk files would be edited only for portraits, which can range from 1kb to 30kb.
•The biggest *.wav file I've seen was 148kb(Xel'Naga Temple).
•Tileset files consist of different formats. Depending what part of the tileset is edited, it ranges from 0-15kb for *.cv5 files, *.grp files, *.vf4 files, and *.wpe files. Filesizes are around 100-150kb with *.vx4 files, and 700+kb for *.vf4 files. A drastic tileset change will probably not be made.
•Most *.grp files are 0-30kb for bullets and many units. other units that have more frames are somewhere in between 30 and 130 kb. The protoss warping texture is 175kb.
•*.lo* files are less than 1kb.
•Iscript.bin and AIScript.bin are less than 15kb each.

Files that would be rejected(that I'd think would be rejected) by the program would include:
•dlgs\*.grp will probably not be modded.
•*.got files(game templates) will not be edited.
•Font files range from less than 1kb to 41kb(at max). We should probably reject the editing of these files.
•*.bin files (for menus and stuff) we should probably reject from being edited. All of these are under 2kb.
•Staredit related files will definitely not be modded.
•*.trg files will not be touched.


These sizes are the packed sizes, and what should be worried about. So unless you make some ultra-drastic change, the filesize of the map should not be too much bigger. It's not like you're going to be editing more than 5 units, and nobody's going to re-create a tileset. Extremely large maps would be rejected from the community anyway.

GRPs and BINs should definitely be allowed to be changed...how would you get new unit graphics, aiscripts, and iscript?

Also keep in mind that MPQs have a compression factor of about 10% or so.

For v1, all we need is to find the static memory addresses of moddable stuff, and then from there we could go on to find a way to dynamically keep track of memory addresses so the program stays current with new SC patches.

Anyone know any people good at disassembling?

Ok you guys have definitely left my small scope. Very talented coders here at SEN!

Only thing I know is BSTRhino is a good modder.
And shadowflare is a uber programmer.

Suicidal Insanity created SCMD2, is he not important?
Heimdal created SF, is he not important?
Clokr_ created PROEdit, is he not important?

The list goes on...

Any news on what it's going to be programmed in and who's working on it now?

Well, for now, count me out. I have my own priorities, and doing another "maybe" project isn't one of them.

I'm getting the feeling the bits of cynasism over this are punching holes in it, ensuring its eventual sinking. Though I somehow doubt this would ever become used widely enough to be worthwhile, anyway. The only way I can see this working is with a MASSIVE coordinated effort, both between map makers designing many new maps to utilize modding features (good maps, not run of the mill showcases), and all the major SC sites advertising it like crazy.

I'm afraid that doing something on that scale would attract blizzard's anti-hack attention, though. Any way you look at it, it's gonna be risky. If you like risks though, then I'd still say it's worth a shot (at least).

That's what you didn't understand. I used "dlgs\*.grp" in the second list, what won't be modded, and you see in brackets THOSE bin files are for the menus and stuff, I listed AIScript and Iscript in the first list.


That's why I suggested samods.org a lot earlier. People at samods have done a lot of things to Starcraft...

So you guys know Programming will start this wednesday!

i guess this would be important to know lol

Cool. GL with it.

Damn, I just went to samods.org to see what they're all about. Strange I never realized they were doing all that stuff. Messing with hard-coded exe limits, modding units beyond SC's abilities... dang.

It would be cool if they could help with an automodder, as it seems they've already done a lot of work with finding memory locations and such.

Just so everyone knows, it's VB starting

Yeah it would probably be smart to talk with some of the modders

Good luck!

hm...ya, since Tux checked it out, I will too!

Hey, we've responded to your topic on the Star Alliance boards. (samods.org)

There's some basic responses, but we can give you a detailed answer in exact file paths, patch compatibiilties and other issues once you give us more information.

http://forums.samods.org/index.php?showtopic=4044&st=0&

Well thanks for the reply, but I'd still like to see that frozen sniper effect before I believe it. As I said, I know better than to think no one else would be using custom graphics in their own maps if they could.

As for the idea itself, please read my reply.

I just wanted to state a little bit of knowledge that may or may not interest you. It came up to me while I was writing content for a new section on StarCraft.org which would have all these fascinating facts about StarCraft. Here's a relevant fact:

StarDraft's first ever patch loader did not use MPQs, CWAD, or any other kind of archive files for you to make your mod in. What actually happened was you set up your mod as a folder on your hard drive, and the patch loader would apply the files in that folder just like MPQDraft does with MPQs today.

One of the most amazing things about this was that, if you went along and changed the files inside the patch folder while StarCraft was running, the data that was in StarCraft's memory would also change. In other words, you could apply mods without closing StarCraft. This would crash 1 out of 4 times or so, but it worked quite well generally.

That is exactly what you want here. I don't know if it will help, but I do know how the various patch loaders worked and how MPQs are loaded.

First of all, to explain how the StarDraft patch loader worked, you have to understand how MPQs are loaded. You guys probably already know this, but the basic idea is, when StarCraft wants a file, it first checks in memory to see whether the file is loaded already. If it's not there, it goes through the list of MPQs and loads the first occurence of the file.

The way StarDraft's patch loader worked was, it stuck the files in memory, so the next time StarCraft went down to find a modded file, it'd find it in memory and go "Oh well, no point looking in the MPQ..."

So that's where I would point you to, revamping the old StarDraft patching technology, just adding a little more smartness to it. It's a really fascinating project, and I do have experience with disassembling, searching for memory locations and reading and writing to the memory of another process. If we could work out some algorithm to know where to look and where to write data, most likely basing it on our friend StarDraft, I think it wouldn't be that hard to do.

Being a modder I honestly think it'd be a fun project to do, but like Tux, I have a few responsibilities to attend to, so I don't think I will be able to work on this during the next few months. We'll see what happens after that though.




Also, about the size of mods, I'd just like to say that today I calculated that every trigger you create adds 2400 bytes or 2.4 KB to the CHK file (meaning that you can have 1789569 triggers in one map to those of you who are reaching for your calculators) and I think that's a huge amount of space for each trigger. Mods are nothing compared to that.

Interesting. Who were the makers of StarDraft? Perhaps they wouldn't mind revisiting it once more?

One thing to mention, though: Stwong (on samods.org) posted a clever idea to mod starcraft to change the order in which the mpqs are read, such that the map itself would actually be first in line, and then patch_rt, stardat/broodat, etc. If that works, then you could essentially put anything recognizable by starcraft in a map, and it might work on bnet as long as everyone else is running the same mod. Since automodder would be required by everyone anyway, how would having a mod to load other mods be much different?

My instincts are telling me it won't be that simple, though, but I suppose it's worth a shot.

I know, that's what I would've thought of at first. But remember how I said before that StarCraft checks if the file is already in memory before reading MPQs? That's what's the difficulty here, StarCraft might not read all the modded files in the map because some would already be in memory, perhaps from preloading or from the last game. That's why the StarDraft patching technology needs to be resurrected for this, because it always overwrites loaded files in memory with new versions.

King Arthur/Merlin from Camelot Systems created the StarDraft technology. I'll have to check their real names. I think they work at Blizzard now too actually...

Uh oh. Dunno if we can trust them then lol...

Well, it's worth a shot I think. It wouldn't even be too difficult, once you find the list in Starcraft for that. I wonder if you could even put the map in front of memory in the list (or would that lag the game horribly?)...

Hopefully ZephyrTC will live up to his word and start working on it tomorrow

Does StarDraft technology include "un-modding" the game?

*LegacyWeapon sees a glimmer of hope beyond the horizon...
Of course it would make the entire thing much easier.

This project sounds great. But I, as a new member to Staredit.net (not to mapmaking), and one who knows little about programming, have a couple of questions for clarification.

When you say Starcraft loads data in a hierarchial manner, and say that memory comes first, then patch_rt, then BrooDat, then StarDat, and then the map...
Does it mean that once it finds a file in a higher priority location, then it won't look for one anymore, and will go with that version, or does it mean that it reads the "list" backwards, starting with the lowest priority, and overwrites it if it finds a higher-priority one?

Is there any way to force the engine to _reload_ a certain piece of game data ingame, or is the only way of doing this is to replace the data in the memory itself, which you are trying to accomplish?

Are parts of the actual scenario data loaded into memory, or is it read directly from the scenario.chk? Will it be possible to replace not only "mod-related" game data in the memory, but also scenario data such as the string table, positions of locations, unit stats, etc.?

Again, excuse my lack of knowledge.

I would really like to help with this project any way I can, but unfortunately my (quasi-)"programming" skills only extend to XHTML, CSS, and a little bit of ECMA/JavaScript. Nevertheless, if you think you could use my assistance, I will most likely be eager to help.

UED77

Well, when starcraft loads up, as far as I remember, it looks for the files it needs in the mpqs in order of patch_rt, stardat/broodat, install.exe, and then finally the map itself (I think it was). Someone who knows this info exactly will need to help me verify this.

As for reloading data, as far as I'm aware you can't do that within SC while its running. You need to close it out to "reload" anything, unless you want to hack into its memory during runtime, which is the idea of an automodder.

Trouble is, I don't know how to hack squat lol. That goes to whoever knows disassembling, and has the patience to map out all the addresses SC uses to hold stuff in memory. After that, the task of changing whats at those addresses at the right moment (as the game starts on bnet) is the next challenge.

As long as the memory changing stays in sync between all players, there should be nothing stopping you from changing almost anything in starcraft over bnet!

If BSTRhino is correct, what if we did the following:

Rearrange the linked list with the archives so that the map is in front (this would take swapping 4 pointers).
Somehow "invalidate" the current SC memory so that it has to load the files again. I know that most of the data is loaded at SC start, so this would only work if the programmers actually check if the data is loaded before starting each game and reloading it if necessary.

Edit: Bleh, I guess UED77 asked just about the same things. I should read more before posting.

By the way, I'd strongly suggest doing this project in C++ - you have much more control over memory.

Your idea is good, it's good that we have a number of brains to think about things, but I think it'd be difficult to implement, because it'd take disassembling and debugging, which would be harder than searching memory for the StarDraft idea, and also I'm not sure if there is any invalidate functionality in StarCraft. I think that StarCraft caches everything, except for a few exceptions like SMK files which are never loaded into memory as a whole. Those were the files that StarDraft couldn't patch.

At the moment it still looks like we should do what StarDraft did and overwrite files in memory. It's already been invented so I'm expecting that's the easiest thing to do at the moment.


Now I'll answer all your other questions...


Here's the basic idea.

Usually we get memory addresses by using a program to search a program's memory while it's running. So if you know your minerals are 112 at the moment, then you use a program to search the memory for 112, and then you change your minerals to say, 128, and then narrow down your search for memory locations that have changed to 128, and keep narrowing down until you have one memory location.

That's the main tool because it's faster and easier. Reading disassembled code is a lot harder to understand, it's really long, boring, and you can't really tell what it's doing because it's quite low level. For those I usually just look at string or DLL references and look at the code around them. String references or DLL references are like little beacons in the code for humans that say things like "This code is reading the string 'Psi limit exceeded'" and so they give you a place to start looking. I have found some useful memory locations for other games by doing this, but I have disassembled StarCraft several times before and found no obvious places to look in the code. StarCraft is not as simple as the other games I've disassembled, so I often wonder how everyone else managed to create programs like MPQDraft.



Well, what I had expected to do was, we'd search the memory for the original units.dat file, and then we'd see what would happen if we overwrote that. The program to do this should only take about an hour or less to make to be honest. Then we'd restart the game and search for units.dat, and see if its memory location changed. If it did, what I was thinking is, somewhere in StarCraft's memory there would probably be the string "arr\units.dat" or its MPQ hash code, and somewhere near that would be a pointer, so we'd just search for that and look at the memory around it.

I would think next we'd make our own SCM or SCX with a arr\units.dat file in it and see if we could find the SCM/SCX data in memory, and if we could we'd next have to try extracting it and reading it like an MPQ, extracting arr\units.dat out and overwriting it back into the system using what we learnt from the last experiment.

Finally we'd expand to try to overwrite all files, not just arr\units.dat. That plan I just wrote doesn't sound too hard to do at the moment, but I bet something will be different from what I expect it to.




Hi UED77!

I have always been told it goes from highest to lowest. I'll have to think about that though, I can't think of a reason why a Blizzard programmer would want to waste memory by making it read backwards. Also, perhaps your CD would be more active during the game if it always read backwards like that.



I think staredit\scenario.chk is one of those files I was mentioning before that is never fully memory (and so cannot be patched by StarDraft, not that it matters). However, unit stats, location positions, and everything else can still be edited. I have written StarGraft code to change unit stats mid-game, just for fun. Anything in memory can be edited with the right amount of knowledge.


Unfortunately not. The AutoModder will have to be clever enough to overwrite modded files with their originals.



C++ would be fine if we were going to use a lot of pointers or something, but I was expecting that we'd be using those Win32 APIs to peek and poke memory of another process, so the main thing we'd be looking for when choosing a programming language would be one that had good data handling facilities. Perhaps we will choose C++ in the end, but I was hoping for C#...

C# would have about the same power as C++ as long as you wrap everything in unsafe{}.

I see that my april fools joke is having a big repercusion in the thoughts of the map making comunity.
So now you are gonna make that program?
Well, if you finally start this project count me in for help