Staredit Network

I meant using triggers to activate the program. We know that we can change certain byte values. There is probably one out of the entire range that StarCraft doesn't use or ignore, so can't we have the program detect that change (which would be done with a trigger), and then activate itself? And when the game ends, have the program deactivate itself?

EDIT: Okay, thanks for clarifying that DK. My post is kinda pointless now...

Heimdal says this to me, so its possible.



Deathknight offeres reassurance.



And this is answered in my first statement, found above on this post.

ADDITION:


This is also answered in my post, found above. It's entirely possible

Well, why enable/disable it? It should always be enabled. It doesn't change gameplay, except the fact that it runs EUD triggers.

Well, it does drop the poor sap who is unfortunate enough to not have this program and join a game where it uses EUDs. Otherwise, it's not a big deal, and that is the person and the map maker's fault for not being more careful, and not labelling the map correctly. Unless he did, then it's the unfortunate poor saps fault.

A nice tool for map makers would to be able to close non-EUD enabled people gracefully. Meaning instead of dropping them, send them a message, tell them where to get the program, and then end the map in a draw. Much better than just dropping them.

Well it wouldn't necessarily drop them in the way we think (disconnecting), more like using drophack to drop someone from a agme and force them to enter the channel where they originally were. And if they don't have this program ON in a map with EUDs, it would drop them anyway. The only way to get around this is to make a map say this RIGHT AWAY in a map, in text, and once again in the briefing, and lastly, once in the pregame forces. Force 4 maybe be "EUD Map, reuqires Enabler", and in the briefing, it would list where you could get it. Most likely here, but we should wait until Blizzard says something. No point in getting further than we are if Blizzard won't let us. But if they do let us, then it's all free game to think of ways to inform the masses.

whats is the url to download this? so i can put it on my map?

I personally think this program will be mainly used in private games, or the SEN map night. Normal battle.net users will really not download this, so people will get frustrated when hosting public games because no one supports EUDs.

Definitely a possibility.

I've set up a super easy subdomain for you to put in your maps.

http://eud.staredit.net

This'll definitely be useful.
Less letters and numbers to type, and when you copy, less space you have to highlight, which means you have to move your mouse not as far.

Plus you can memorize it, I figured.

Certainly is easier to memorize.

well, what about the EUDEnabler url plz?

Why don't you check the VERY FIRST POST? Or perhaps the link Yoshi just posted?

I used a hex editor to compare the area where the version data is stored, and then changed it to match the new patch. What I did was make a permanant version of this. Since the only change in 1.13-1.13b was the EUD triggers, both ways work. The data in that area would be perfect for reading in making version dependant programs, like Memgraft/or an Automodder with button/req changes. Anyway, I like to do that kind of stuff with the exe. I've done some wierd effects.

Interesting; I'm surprised that worked. My original attempt was to overwrite the code in the EXE, but battle.net rejected me when trying to connect. I figured it was running a checksum or something. So then I just patched it in memory.

This program sounds like it was quite simple to make acutally, you just kind of revert back to 1.13a using the memory after your already connected to bnet.
You just had to copy and paste the old assemply.

But ya, it still justifises the programmer exstrodinare custom title.

And If i knew how to make a program to patch sc memory, we'd all have a better Memgraft, maybe an automodder. And I was thinking about the issue of Blizz' shuting this down. I don't know the exact reason for why they were removed(i have a vauge idea by what has been said), but if the EUD enabler make it so only certain areas of mem could be modified by EUD triggers, it would be safer. A lot of important data is in the area we are messing with. The biggest concern should be execution pointers. I know one way that a virus can be created(not with this program, another one). All it really requires is messing with the pointers. Luckly, not many people understand some of the workings of the SC code as I do(having been in it and done a lot). My best guess to fix this would be to scan the triggers when the map is selected, compute the memory address any EUD triggers would modify, and compare against a list of valid memory. If it is outside the memory, EUDEnabler should disable and no EUD triggers run. The catch is that a lot of the .dat files have space between entries which is invalid(used by the code for data). Oh, and we should look into adding P9-P12 support too.

How true... Memory patching (memgraft modding) has always been a form of hacking, as DK quite exsplicitly showed us at one point...

ADDITION:
Wait, do the exe pointers mean:
a. viruses in maps
b. we can modify an even greater range of starcraft's memory (iscripts, and stat_txt)

ADDITION: Wait what do you mean a virus can't be created with this program, only another one. It's not the program which patches the memory, it's the triggers.

srry Chuos i tought it was a section for EUD maps not url

It requires other programs to actually create/add malicious code to memory, then the triggers can run it(if they find a place where the code will make a call/jump from).

I was talking about Memgraft, adding new code that was actually malicious in nature. And it can call it(if you know what your doing). All DK did with the morph thing was make use of the fact that there was no check to make sure that only a Mutalisk could become a Cocoon. The check was there for Lavae->Egg and Hydralisk->Lurker Egg

Exe pointers would mean we mess up what code is running when, creating exceptions and crashing starcraft. To modify Iscript, we'd need an automodder, or just use standard modding means.

Of course, I could be wrong, and if I am, I'm sorry. Doubtless, someone will point out if I have something wrong.

My theory is that EUDs enrich SC gameplay. Therefore they are not hacks. That is why they should be used by all!

Okay, umm. Wow I don't know where to begin.

EUDs violate EULA, therefore they should not be used by all. Blizzard would get very upset. They also enhance gameplay how? By using this owrding, you justify the use of MapHack, and DropHack, which also enhance gameplay for the incredibly newbish and unskilled. EUDEnabler DOES NOT enhance gameplay. It merely allows for the use of something which enhances map making, which is not considered gameplay: it is a section by itself. Map making is not gameplay; mak mapking provides for new platforms of gameplay. And the way in which EUDEnabler works, it really does work like a hack. It manipulates something in the SC memory.

While some of my statements may or may not contradict what I have already said, or would be happening to sa at the same time, the point is that EUDs do not fulfil any of the above enlisted requirements. Choose and take a pick, and you violate something no matter what.

Ya, i really dont know much about it. If it would be kept private that would be one thing.