Report, edit, etc...Posted by Laser_Dude on 2006-11-13 at 02:45:09
I chacked the tutorials database on this one, the link in "how to write a starcraft MOD" isn't working, and the wiki is down, so I'm out of ideas for where to look. What are the req. var and action var for in stargraft? What do they do?
Report, edit, etc...Posted by ShadowFlare on 2006-11-13 at 02:49:40
They are values passed to the functions for the button requirements and actions. Lots of times this will be something like a unit or technology number, or something like that.
I haven't actually used StarGraft in years, but I know what parts of it you are talking about, since I've delved into the format of that stuff sometimes and hex edited things in the exe directly sometimes (I actually looked at it sometime recently
).
I haven't actually used StarGraft in years, but I know what parts of it you are talking about, since I've delved into the format of that stuff sometimes and hex edited things in the exe directly sometimes (I actually looked at it sometime recently
).Report, edit, etc...Posted by TheNomad on 2006-11-13 at 04:17:47
yeah, but if you are a mapper, it's simple to think of them in terms of "CONDITIONS" and "ACTIONS". I'll use MemGraft which is basically the same
Here is an explanation... Buttons don't do anything, unless instructed to perform a certain action. Starcraft uses 3 types of action routines: orders (simple ones such as move, stop, attack, attack move, repair etc.), scripts (spider mine, which waits for units to come in proximity, then attacks like crazy, creep management, such as creating creep, spreading it, losing it if a creep provider such as a hatchery or colony dies, burrowed states etc.) and something I call casting (they are basically intermediates that call other functions, and are, in most cases, techs/spells, and the complexity in all this is that some call weapons, flingys, iscripts etc.). If you're wondering where they are, they're stored in Orders.dat
Anyway, each of these orders/scripts have properties (from flags, such as not being interrupted, not casting over obstacles such as water etc. to stuff like which unit is allowed to do it, since you won't see a tank with mines or a marine with lift-off buttons... and even if you add them, it won't work unless you set a marine to be allowed to liftoff, but it gets more complicated since you'll need to edit lo? files and iscripts... but back to the point now...). In order for StarCraft to know what the player wants, he uses buttons to interact with the user (talking from the engine's POV ).
So now it gets fun
When you press a button, it won't do anything, unless it is properly set-up. This is done by using a set of conditions (reqs) and a set of actions (order calls). Let's say a lurker. We'll assume we are in StarCraft (therefore a lurker doesn't exist). You'll create a hydralisk mutant thingy that only attacks while burrowed. This means the following:
- attack button is missing while unburrowed
- attack button is visible while burrowed
- even if some dude h4xes the game to have an attack button while burrowed, the unit won't attack
Here is where the Reqs and Acts come in:
Button: Attack
Req: Unit is burrowed (noted as "Is using ability 11")
Act: Attack
What does that mean ? The req is "is using ability" and the req value is 11.
If you'll check TechData.dat in your favorite ARR Data editor (A3, A0, ArrEd or DatEd) you'll see that 11 is the ID for burrowing.
This is similar to something like:
Button: Research
Req: Tech is not researched X
Act: Research X
X being the ID of the tech you want to research.
Of course you can do fun stuff like in WarCraft 3, where, by researching one spell (which is actually a traiing that researches both a spell and increases mana) you'll get a new spell on the next level. Something like weapon upgrades only for spells.
In this example we'll allow researching of the lurker aspect ONLY IF burrowing is researched first.
Button: Research Lurker Aspect
Req: Tech is researched 11
Act: Research 32
As for the large textboxes on the right of the Req and Act tabs, they are used to add new actions or requirements using the hex conversion of asm. In asm, iirc, the values of reqs or acts are the EAX registers (but I am not 100% sure).
Anyway, hope this gave you a larger horizon on the fun stuff you can do by playing with Reqs and Acts
Here is an explanation... Buttons don't do anything, unless instructed to perform a certain action. Starcraft uses 3 types of action routines: orders (simple ones such as move, stop, attack, attack move, repair etc.), scripts (spider mine, which waits for units to come in proximity, then attacks like crazy, creep management, such as creating creep, spreading it, losing it if a creep provider such as a hatchery or colony dies, burrowed states etc.) and something I call casting (they are basically intermediates that call other functions, and are, in most cases, techs/spells, and the complexity in all this is that some call weapons, flingys, iscripts etc.). If you're wondering where they are, they're stored in Orders.dat
Anyway, each of these orders/scripts have properties (from flags, such as not being interrupted, not casting over obstacles such as water etc. to stuff like which unit is allowed to do it, since you won't see a tank with mines or a marine with lift-off buttons... and even if you add them, it won't work unless you set a marine to be allowed to liftoff, but it gets more complicated since you'll need to edit lo? files and iscripts... but back to the point now...). In order for StarCraft to know what the player wants, he uses buttons to interact with the user (talking from the engine's POV
). So now it gets fun
When you press a button, it won't do anything, unless it is properly set-up. This is done by using a set of conditions (reqs) and a set of actions (order calls). Let's say a lurker. We'll assume we are in StarCraft (therefore a lurker doesn't exist). You'll create a hydralisk mutant thingy that only attacks while burrowed. This means the following:- attack button is missing while unburrowed
- attack button is visible while burrowed
- even if some dude h4xes the game to have an attack button while burrowed, the unit won't attack
Here is where the Reqs and Acts come in:
Button: Attack
Req: Unit is burrowed (noted as "Is using ability 11")
Act: Attack
What does that mean ? The req is "is using ability" and the req value is 11.
If you'll check TechData.dat in your favorite ARR Data editor (A3, A0, ArrEd or DatEd) you'll see that 11 is the ID for burrowing.
This is similar to something like:
Button: Research
Req: Tech is not researched X
Act: Research X
X being the ID of the tech you want to research.
Of course you can do fun stuff like in WarCraft 3, where, by researching one spell (which is actually a traiing that researches both a spell and increases mana) you'll get a new spell on the next level. Something like weapon upgrades only for spells.
In this example we'll allow researching of the lurker aspect ONLY IF burrowing is researched first.
Button: Research Lurker Aspect
Req: Tech is researched 11
Act: Research 32
As for the large textboxes on the right of the Req and Act tabs, they are used to add new actions or requirements using the hex conversion of asm. In asm, iirc, the values of reqs or acts are the EAX registers (but I am not 100% sure).
Anyway, hope this gave you a larger horizon on the fun stuff you can do by playing with Reqs and Acts
Report, edit, etc...Posted by Ojan on 2006-11-13 at 11:28:28
Here's a little list that will tell you what number to use, since MemGraft lacks such a feature:
http://www.smempire.org/specs/req-action_var.php
http://www.smempire.org/specs/req-action_var.php
Report, edit, etc...Posted by Laser_Dude on 2006-11-13 at 13:34:08
I get it now, but I'm pretty curious, what governs whether a button is greyed out, or black? Does it have to do with is it possible for that tech to ever be used?
Report, edit, etc...Posted by ShadowFlare on 2006-11-13 at 13:44:39
It has something to do with what function is being used for the condition and the requirements that condition references.
Report, edit, etc...Posted by Laser_Dude on 2006-11-13 at 15:09:33
What I'm referring to is how the set rally point button disappears when the building is lifted, but the build science vessel button doesn't disappear when there's no science facility.
Report, edit, etc...Posted by TheNomad on 2006-11-14 at 08:41:00
I believe that is hardcoded by the internal reqs.
For example adding an EMP ability for the Marine with the "spell researched" condition meaning that once the emp is researched the button is clickable was no problem. But as soon as the spell was researched the button disappeared. Why ? That's because I didn't set the TechUReq for the EMP to allow Marines.
The land, rally point and so on are all done internally. As you see the buttons are replaced (SCV is replaced by Move and Cancel by Land etc).
Move, Stop, Land, Burrow etc are simple orders (remember the big list I mentioned in the other post ?) and are specifically designed to either exist or not exist. You can't say "I will allow a Marine to move if he researched the Move ability". That'd be original, yes, but you can't
without exe editing anyway.
The Casting orders are basically defined by conditions. If a spell is researched, if an ability is being used, if the unit is allowed to cast the ability etc. Which means they can either be allowed or not allowed (contrary to "either exist or not exist").
Scripts can't be controlled via buttons. The only place scripts are able to be called is via StarEdit. And even there quite limited to AI Scripts, and SOME abilities that are emulated via scripts. The unit scripts (Spider Mine, Larva, Tower, Reaver etc.) are only accessible and able to be changed via the AI Script subtab in the DatEdit Unit tab.
Personally I'd have appreciated if Blizz would have separated them as I did to make it a bit ore user friendly than to throw them all in a pile and say they are all orders, when in fact, they're not.
For example adding an EMP ability for the Marine with the "spell researched" condition meaning that once the emp is researched the button is clickable was no problem. But as soon as the spell was researched the button disappeared. Why ? That's because I didn't set the TechUReq for the EMP to allow Marines.
The land, rally point and so on are all done internally. As you see the buttons are replaced (SCV is replaced by Move and Cancel by Land etc).
Move, Stop, Land, Burrow etc are simple orders (remember the big list I mentioned in the other post ?) and are specifically designed to either exist or not exist. You can't say "I will allow a Marine to move if he researched the Move ability". That'd be original, yes, but you can't
without exe editing anyway.The Casting orders are basically defined by conditions. If a spell is researched, if an ability is being used, if the unit is allowed to cast the ability etc. Which means they can either be allowed or not allowed (contrary to "either exist or not exist").
Scripts can't be controlled via buttons. The only place scripts are able to be called is via StarEdit. And even there quite limited to AI Scripts, and SOME abilities that are emulated via scripts. The unit scripts (Spider Mine, Larva, Tower, Reaver etc.) are only accessible and able to be changed via the AI Script subtab in the DatEdit Unit tab.
Personally I'd have appreciated if Blizz would have separated them as I did to make it a bit ore user friendly than to throw them all in a pile and say they are all orders, when in fact, they're not.
Report, edit, etc...Posted by BroodKiller on 2006-11-14 at 13:14:46
Heh, in late 90s noone thought that such a degree of modding would ever be possible, mate:) It's just the way Blizzard have done it, and I don't know any other game apart SC where you do memory-structure operations of this kind. Noone expected it to happen, and neither did Blizz.
Report, edit, etc...Posted by Laser_Dude on 2006-11-14 at 19:22:36
I guess if they had, they still wouldn't have done it
after all, they didn't intend for people to be able to mod SC
after all, they didn't intend for people to be able to mod SC
Report, edit, etc...Posted by TheNomad on 2006-11-14 at 20:58:50
True, but WC3 is better supported for modding than SC.
Truth is, it's too late to change stuff in SC to make it user-friendly for mods now, unlike WC3 where it was more than obvious they planned supporting them as a side option.
Still, I wouldn't mind them making a new orders.dat with 10 more unused orders (*cough*), 10 more unused units slots and a bit of room in setting default options.
For example "Scanner Sweep" is by default researched in the EXE and can't be "researchable" at all.
While this is a minor thing, as I said, I wouldn't mind a bit of more help from their part
Truth is, it's too late to change stuff in SC to make it user-friendly for mods now, unlike WC3 where it was more than obvious they planned supporting them as a side option.
Still, I wouldn't mind them making a new orders.dat with 10 more unused orders (*cough*), 10 more unused units slots and a bit of room in setting default options.
For example "Scanner Sweep" is by default researched in the EXE and can't be "researchable" at all.
While this is a minor thing, as I said, I wouldn't mind a bit of more help from their part