|
|
|
|
# 1
|
|
Ouroboros-in-training
Join Date: Jul 2006
|
Reference: Requirements
Rating: General reference
So, I'm bored at work right now and thought I'd write a tutorial that didn't need any screenshots and figured I'd round up the requirements. Now, I know most of these are totally self-explanatory, but I thought that I might elucidate these and bring some of the more useful and underused ones to light. Any modder worth his salt should know these things inside-out and back-to-front as they are probably the most potent and elegant tools available in the AE. Also, there's various tid-bits in there that might save you some serious head-scratching some day. How To Add Requirements If the item you want to add requirements to already has a requirements section then altering them is easy. You don't technically need to 'add' any to this as they are all there already, they are just set to required_none. Through combining these requirements you can form your tech tree and powerfully shape your races. Altering these is dead simple, it's just a case of selecting the desired units are structures from the drop box and filling in any numbers you want. If you want to get rid of a requirement simply set the requirement to 'required_none' and it will clear all the info. The requirements for troops will generally be their squad file. Requirements on their entity will do. Squad leaders however are different, their requirements are on their EBPs, which is the same for buildings as neither actually has a squad file. Should you find that the requirements section is missing you'll need to add one yourself. You'll need to select the right thing to add from three. Right-click on the white space, Add Reference, then select the appropriate thing from the list, and before you dive in and click it: no, it's not the one that says 'requirement'!! (see below) ![]() For squads (SBPs) you only add a 'squad_extension', then find the squad_requirement_ext, autoname it and OK it. For entity files (EBPs, such as buildings and squad leaders) you need to add a normal 'extension', then same again: find requirement_ext, autoname it, then OK For addons, researches, abilities and weapons you need to add a research 'table' as they are neither entity nor squad. Select table from the right-click list, then find the requirement table, autoname it, then OK. You'll notice however that addons, abilities and researches all have this by default, it's only weapons that might catch you out. You should now be able to edit it normally. The Requirements Buildings Basic buildings blocks of the tech tree, these are pretty versatile and very straight-forward. required_structure Code:
No real explanation necessary. Note that this requirement will only be met when the building is finished (and important distinction that varies between requirements). required_strucutre_exclusive Code:
This is the code that allows the branching tech tree of the Tau, the thing with this cannot be built if the named building is built. The most important factor about this requirement is that it doesn't matter if you destroy the building, you will not be able to reverse this once met: it is final. The only other requirement which is irreversible is required_research, this is important to note. This requirement kicks as soon as the building is placed. (see what I mean? required_structure_either Code:
This one was introduced in Dark Crusade to much whinging - this is the one that allows you to get to T2 after building only the barracks OR the armoury (pre-DC you required both). Again, only kicks in when the building is properly complete. require_structure_ratio Code:
Your power gens are limited to 6 per HQ with this one (HQ goes in the top slot, gens in the bottom). Interesting points are that this one doesn't show up in yellow required text, which is annoying and means you should probably update your tooltips, and also that the ratio can be top heavy too - say 3 HQs required to build 2 generators: you won't be able to build any gens till you build that third HQ, at which point you'll be allowed to build two gens. Also, it doesn't have to be building to building, it can building to anything; however, this will break the ratio on the anything side - i.e. say terminators:barracks ratio was 1:2, you would need two barracks to build any terminators, but as soon as you built two you could build as many terminators as you liked. This is useful for using multiple buildings as requirments for things. required_cap Code:
Buildings such as the Orbital Relay and Mars Pattern Command use this. Simple really, just stick in the number. It works much the same as, but should not be confused with, hard caps (required_squad_cap) - this limits entities where as the other limits squads, they work differently too. This is another one that kicks in as soon as the building is placed. You can almost use this to limit leaders in a squad (say Shas-Ui limited to 1) as these are entities, but it is flawed. The cap kicks in when an entity appears on the map (i.e. placing a building) but this means it doesn't kick in for leaders unit they are complete, which allows you to queue up more, thus defeating the cap (once queued they will get built regardless of the cap). Researches The most notable thing about these is that they cannot be undone/de-teched. This is the crucial difference between researches and addons, very important when thinking about game design and avoiding potential bugs. required_research Code:
The third line is the main one, and doesn't need any real explanation. This requirement has a built in 'exclusive' clause in it that you can tick (the 2nd line), however be wary - this only kicks in when the research is complete, so again you can queue up the second research behind it to get round it. This could be solved by having zero build time, and so you could create a branching tech tree with out needing extra buildings. Other than that it's relatively useless. Multi-Tier Researches - eg Power/Req upgrades, tier upgrades etc These are the ones where the second stage replaces the first when it's complete. To achieve this affect you need to set a few things. First the second research must require the first. Simple. Next you need to make sure that both are set to appear in the same slot on the user interface. Set this in the ui_ext - ui_index_hint (see icons tutorial for more detail). Next you only want it to appear when the first was is complete. For this you need to set the display requirements; set a second field to require the first research and the tick the display requirements this time. Two-tier researches - done. ![]() required_research_either Code:
Basically, the same as above but you get to name two researches. Works in exactly the same way as required_structure_either. Tau are the only ones to use it so far. research_limit Code:
This isn't a requirement as such but works very much like them and I felt it was worth mentioning. It appears at the top of the research_ext which lists all available researches on that building and allows you to limit the amount done on it. Necrons Artifacts are limited by this box. Leave it at 0 to have it be ignored. If you set a number, that number will apply across all instances of that building, so you can't get around it that way. Very useful this one is (eh Croaxleigh! Addons/Stones At first glance these might seem exactly like researches, and they share many characteristics, the main difference is that they are LOCAL. Imperial Guard and Eldar use tons of these 'Stones' to enable/prevent building of things from certain building. You'll be well aware that you have to build the appropriate stone on each of the buildings you want to build them from. Tier upgrades (other than Eldar) are also addons, and thus can be de-teched, as the addon disappears when the building is destroyed and the requirement no longer met. The local-ness of them gives rise to some interesting effects... global_required_addon Code:
Dead simple, this is what is used by the main Tier upgrades. This only needs one instance of the addon to be present on the battlefield (for you player). Must be complete for requirement to be met. global_required_addon_exclusive Code:
Same again, but the negative effect. If this addon is present anywhere then you can't build this thing. Also, this requirement kicks in as soon as you queue up the addon, it doesn't wait until it is complete. local_required_addon Code:
This will only apply to buildable squads, addons and researches. It could potentially also apply to deepstrike_ext on buildings but I seem to remember compiler saying that it had no effect (is that right Big C?) Basically, something that comes out of a building, as it will require that very same building to have this addon built on it. Basically, this is way Guard and Eldar Stones work. Must be complete for requirement to be met. local_required_addon_exclusive Code:
Same as above, but exclusive: if this is complete then you cannot build the unit. Again, this requirement is met as soon as the addon is queued up. The fact that the exclusive versions of these addons are met as soon as you queue them up is the most important part as this allows you to properly create little mini branching systems. Take IG bunkers for instance, you can make it so that you can build either Kasrkins or Ogryns, but not both, but making the stones locally exclusive. With this technique you can create a need for the player to build multiples of buildings so that they can access all the options. Use of globally exclusive requirement on addons allows you to limit various addons to only one on the battlefield, it also allows them to act like researches to some extent if you give them various modifiers are make things require that addons. There's lot of potential for good combos in there. Troops required_squad_cap Code:
This is the one that sets hardcaps. required_cumulative_squad_cap Code:
This one sets group hard caps. The table is for listing the other squads you want to include in the group. Be sure to only put the OTHER units in there, and not the one you are currently editing. ***These two have been covered in proper detail with a full tutorial here *** required_squad Code:
This is an odd one and is used for the Bloodthirster and Daemonprince, but not in the way you'd expect. Their researches use it, but set to 0. Setting this one to 0 turns it into an exclusive requirement, so if that unit is on the field it's a no-no. However, this requirement can be used as you'd expect: naming a squad and putting in the number 3 in means that when you have three squads out it's met. It's not a ratio thing like the buildings. The major drawback with this one is that when the yellow required text comes up it doesn't say how many squads are still required, it just says which one. Unsurprisingly this confuses people and the need for tweaked tooltips becomes apparent. required_mobvalue Code:
This is an interesting one and is used by the orks. Basically, the mob bonus is controlled through this one, each ork has a set of abilites that are turned on or off by this requirement. Each ork has been given a 'mob value' which you add as mob_ext to their EBPS. If the total mobvalue in the whole squad exceeds the required mobvalue then surprise surprise the requirement is met. Now, while "squad_activated" is set to true the second line is redundant. Turn the squad stuff to false and it will become a radius based count up rather than squad based. However, I think that this proximity value is in fact non-functional, and the true proximity value is ACTUALLY set in tuning_types -> mobrule -> search_radius (tuning_types is the base file in the AE, it's not IN anything). Currently the 'search_radius' is at 7. Note that mob_ext given to buildings doesn't do anything (wish it did though). required_total_pop Code:
Orkies again. This is the doo-hickey that sorts out the WAAAGH! requirements. You can set it to whatever you like really, it'll figure out what the Waagh image should be by itself. The levels at which the letters become coloured are set in tuning_types -> ui -> ork_pop_level. Misc required_ownership Code:
This is the sneaky little fella that Relic units use, they require ownership of one Relic point. You have to type an entity name into the space, there's no drop box. The words you need are: Relics = relic_struct, Strat points = strategic_point_flag and Crits = strategic_objective_struct. You will have noticed that you can set the number needed too, useful eh? These only apply to entities that can change ownership, so points only. required_health Code:
Not acutally sure who uses this one, did a search and couldn't find anyone, but they must be in there somewhere. I have a feeling it's used on an ability or two somewhere Anyway, this one does what it says on the tin - unless the entity has the required amount of health then it won't be met. 0.5 = 50%. Not much to say other than it will only really be useful for abilites I guess, not tried it with other stuff. required_human_player_metamap_game Code:
.....eh? Right, well this one is basically how Relic have split their single player stuff from the metamap stuff. This is how you get to have skirmish commanders and then wargear-tastic SP commanders. Other than that this is useless. If this requirement is not present at all the unit will appear in both types of game, if you leave it unticked it won't appear in SP, mark it ticked and it will appear in the campaign. Display Requirements ![]() So you might have noticed that little tick box in each requirement right? Well, that's a useful little fellow indeed. That's the one that makes your greyed out icons appear. Ok, so when the display_requirement is met then the icon will appear. If all the other REAL requirements have NOT been met then it will appear grey. When all the other real ones are met it will be full colour. Think of it as a two stage thing, the display requirements should be easier to meet than the real ones, so they get met first and it appears grey. It's important to note that the display_requirements are not real requirements; they do not actually count as a real one, so think of them as two separate sets of requirements. Also, a unit will display as soon as any ONE of its display requirements are met, it does not have to meet them all, just one. If you set the disp_req to higher requirents then they will just get ignored and overriden by the main requirements - as soon as the real requirements are met the icon will appear full colour, regardless of whether the display requirement has been met or not. Traditionally the race HQ or the building you get the unit from are set as display_requirements. So, hope that enlightened some things and provoked some new tech tree ideas for you. As usual, keep me informed about any errors. Last edited by Octopus Rex : 9th Feb 09 at 6:03 AM. |
|
|
![]() |
|
|||||||
| Thread Tools | Search this Thread |
| Display Modes | Rate This Thread |
|
|