I heard that we are still able to use EUD conditions just not the actions, and after doing some digging and not finding anything could someone plz clarify this for me. And if we can still use the conditions, what options are still open to us?
Actions were patched in 1.13b because it could modify the RAM for starcraft and it could do something harmful to your computer. Conditions only read the RAM, and isn't harmful so they are still available. A list of extended conditions currently known:
QUOTE
Saved Screen Position (F2) [Single-Player Only]
Saved Screen Position (F3) [Single-Player Only]
Saved Screen Position (F4) [Single-Player Only]
Zerg Supply Max
Terran Supply Max
Protoss Supply Max
Zerg Supply Used
Terran Supply Used
Protoss Supply Used
Technology Research
Technology Research BW
Upgrades
Upgrades BW
Location Position
Cheat Enabled [Single-Player Only]
Game Speed
Player Name
Text Display
Unit HP
Unit Destination
Unit Target Location
Unit Shields
Unit Queue(1/2)
Unit Queue(3/4)
Unit Queue 5 and Energy
Build Time
Unit Status
Rally Point
Energy Left[Broodling/Hallucination], Defense Matrix HP
Status Pack 1
Status Pack 2
Status Pack 3
Status Pack 4
Pauses Left
Game Latency Setting
Screen X Position [Single-Player Only]
Screen Y Position [Single-Player Only]
HUD Display
WAV(Sound) is Playing
WAV(Sound) has Stopped
Your best option for EUD conditions in my opinion is ARTmoney + memcalc.
You can add Unit Cool-down to that list soon...
So could i use those conditions such as the detect units HP and then use a normal SCMDraft action trigger such as set unit HP to 100% and have it work on B.net?
Well, it wouldn't need a trigger to set it's health, if it's already at 100% health it can detect it, but it doesn't detect in percentages. The main problem with it though, is you need to know what unit number the unit is. I do not mean by what type of unit, the unit number depends what order the unit was placed in, making it very ineffective unless it's just for a few units that are pre-placed. Yes, it does work on B.net.
Actions could change the pointer for the render functions, and you could have pointed it to code in your map that was malicious.
Pre-placed units are the only real way to use some of those actions. It's very hard to keep track of what shows up where in memory. Very hard. It will work on B-net, until a new patch shifts around the RAM. Then, all the offsets might(meaning most likely will) be messed up.
QUOTE
Actions could change the pointer for the render functions, and you could have pointed it to code in your map that was malicious.
Are you saying that the actions of the EUD conditions can be used??? I thought that people said only the conditions were working with the new patch...QUOTE(DiscipleOfAdun @ Dec 6 2005, 11:03 AM)
Actions could change the pointer for the render functions, and you could have pointed it to code in your map that was malicious.
Pre-placed units are the only real way to use some of those actions. It's very hard to keep track of what shows up where in memory. Very hard. It will work on B-net, until a new patch shifts around the RAM. Then, all the offsets might(meaning most likely will) be messed up.
[right][snapback]372884[/snapback][/right]
"Pre-placed units are the only real way to use some of those actions."? I do not believe it would be impossibly hard to create a series of triggers to identify a type of unit in a range of occupated slots. I am thinking along the lines of switches, but then you would be semi-limited to the number of switches available, but there are other ways.
"It's very hard to keep track of what shows up where in memory. Very Hard."? If this is only concerning the use of EUDs, how is it hard... the unit table offsets are static. Also concerning new patches, would this not just require the finding of the start of the unit table? which could be updated in... 5 seconds...
He said the only real way, which is really meaning the only practical way. It is possible to detect the unit types, but very ineffective. If you want created units to have HP detection or whatever, just place it in some corner of the map and then move it instead of creating it.
At the same time though, it is possible to have created units work effectively, but you need to know a pre-placed unit's number for it to work effectively, and it also lags the game massively for a short time (it creates like 1700 burrowed units at some point, removes the pre-placed unit which you know the unit number of, and then creates the unit so it's guaranteed to end up as that unit number, then removes the swarm of burrowed units). Much more effective to just move a pre-placed unit.
how about input text detection? could i have a person type "spell one" and then a spell be used?
QUOTE(Kumano @ Dec 6 2005, 05:44 PM)
He said the only real way, which is really meaning the only practical way. It is possible to detect the unit types, but very ineffective. If you want created units to have HP detection or whatever, just place it in some corner of the map and then move it instead of creating it.
At the same time though, it is possible to have created units work effectively, but you need to know a pre-placed unit's number for it to work effectively, and it also lags the game massively for a short time (it creates like 1700 burrowed units at some point, removes the pre-placed unit which you know the unit number of, and then creates the unit so it's guaranteed to end up as that unit number, then removes the swarm of burrowed units). Much more effective to just move a pre-placed unit.
[right][snapback]373055[/snapback][/right]
"lags the game massively..."? umm thats not the way I was thinking of exactly... to go in depth of my idea... I would create a trigger to check the HP of the first unit on the table, 5BC688, to help identify what unit this is... I would most likely have to run a check further than HP figuring some units have the same HP. Then this trigger would set off a switch, upon the enabling of the switch another trigger reacts, aka the trigger with the EUDs you want. You would repeat this process for the range of units, yes not the most efficient method but this came from quick glance thought.
"...you need to know a pre-placed unit's number for it to work..." To get disgustingly technical its not a number assigned to a 'pre-placed unit' as long as you can expect some sort of range for the targeted unit to fall in, you could easily create some adapting triggering. Example, lets say mr.X makes a RPG map... He soon realizes he would like to incorperate EUD conditioned triggers. He observes that no matter how his map is played out upon the arrival of his targeted unit that unit has around the same placement on the unit table, lets say this unit sometimes is 2 slots ahead give or take a few.. so he mr.X now knows as fact that if he uses the idea above he could easily create EUD conditioned triggers even though his targeted unit might not fall in the same slot every time his map is played. Then again in this specific situation just pre-placing the unit would be easier.
Frozen-rpg : Yes that has already been done
p.s. There are some 'trigger-systems' that involve alot more triggering than that... so I don't see it as impossibly inefficient...
QUOTE
how about input text detection? could i have a person type "spell one" and then a spell be used?
Yes, but it's ineffective. Since players can have different name lengths the text could be at different places. For me it would be just bytes 9-18 since bytes 1-8 would be 'Kumano :' but if somebody had a name with 5 characters it would be bytes 8-17, and with many different name lengths it can make lots of triggers. For people with a name length of 5, 9 or 13 it could be very annoying (keep in mind EUD conditions detect the bytes in groups of 4) because you would need to know that last character in their name, and with many characters available it becomes difficult. (1 character, then a space then : then the spell text would happen, for other name lengths you can predict if the space or : is there. Also on top of this there are many different lines it could be on, depending if they have any text messages or something on the screen. Overall it could end up using hundreds of triggers for it, which really isn't that effective.
QUOTE
"lags the game massively..."? umm thats not the way I was thinking of exactly... to go in depth of my idea... I would create a trigger to check the HP of the first unit on the table, 5BC688, to help identify what unit this is... I would most likely have to run a check further than HP figuring some units have the same HP. Then this trigger would set off a switch, upon the enabling of the switch another trigger reacts, aka the trigger with the EUDs you want. You would repeat this process for the range of units, yes not the most efficient method but this came from quick glance thought.
I know, the lagging game thing was the just a method I found to make it possible to predict what unit number a created unit could be. Only use I can think of for it is if you want a unit to become a different type of unit, while making the health detection/whatever detection for the first unit carry on to the second unit.
The number is where in the table it exists. It's not fair to have to search through the entire unit table. Or even just about 10 entires. Figuring out the range is based off of how many units exist, what type they are, what the computer is doing, and so on. I'm not refuting that it can't be done, IT CAN. I'm just saying that it isn't practical. Besides, wasn't I one of the first to demonstrate unit table EUD's(even though I use actions too)?
But, Why not just check the Unit ID then, instead of the HP? Then you know exactly what unit it is. Then, why not check the Player ID? Then you know who owns it.
As for it being hard, trust me it is. First, you have to make sure you what is pre-placed. I've had some time figuring out what counts for the unit table. Then, what's made when. Don't forget about subunits, and hangar units. Add in the fact that if you don't know exactly what it's going to do, you can be off by quite a bit of memory. When EUD's first came out, I made a simple map showing how the unit table could be read/(before actions were removed)written. It took about 3 hours to just figure out the first 5 units.
I never said it was impossible either, and I don't think anyone was disagreeing with that. The thing I was talking about that lagged the game is just a way to make sure a created unit ends up as a specific unit number, since it wouldn't make sense to make the triggers for that unit to be used for many unit numbers depending where it could end up.
well then what eud conditions are feasable and dont require a headache to make?
Well, it can be all or none, it really depends on how you want to use them.
QUOTE(Mr_Mooo_Cow(U) @ Dec 5 2005, 05:45 PM)
You can add Unit Cool-down to that list soon...[right][snapback]372200[/snapback][/right]
I'm pretty sure it's already known.
QUOTE(Moose77 @ Dec 8 2005, 04:49 PM)
I'm pretty sure it's already known.
[right][snapback]374375[/snapback][/right]
I was under the impression that it was not used or maybe known yet because the list I saw made from the people who originally created the "known list" had 0x055 labeled with a ?. Also considering it hasn't properly been used yet because detecting it properly hasn't been done yet...
HAY WUT ABOUT CURSOR POSITION IN MULTIPLAYER?
It would be cool to have mouse-over effects.
Well it would be cool to be able to create conditions, but we can't. Even if there is a way to do cursor position, I doubt it would work in multiplayer.
why do some conditions work in single player and not multi? or is this an illegitimate question..
It would be good if someone made a trigger editor for eud conditions...
Trigger editor for EUDs? Look at uBeR@tion. Some triggers don't work because it would be different for different players, like screen position: player 1 might have his screen at the place, and then the trigger would go off for him but not the other players since they don't have their screens there. Text detection is possible (though not always) for something like this to happen if you are talking only to specific people, and not everyone in the game would hear it so the trigger may go off for you and not others.
QUOTE(Kumano @ Dec 9 2005, 08:12 AM)
Trigger editor for EUDs? Look at uBeR@tion. Some triggers don't work because it would be different for different players, like screen position: player 1 might have his screen at the place, and then the trigger would go off for him but not the other players since they don't have their screens there. Text detection is possible (though not always) for something like this to happen if you are talking only to specific people, and not everyone in the game would hear it so the trigger may go off for you and not others.
[right][snapback]374865[/snapback][/right]
The only reason text detection is improbable to do is because of the 11 lines and 13 name lengths.
On an unrelated note, does screen position detection detect the middle of the screen, or the sides?
I think the top left, I might be wrong though.