For the rest, if you find the rule interesting, I will ask you to provide me with the script to incorporate in the current scenarios, for a future patch.
New Commands: AddGarrison & ClearGarrisons
Here is the presentation of a new command & concept. The aim is to automatically create small garrisons in important places. I think this should help the player (micro management wise) and the AI (efficiency wise!). This is a rule done for NCP but I think AACW can benefit from it nicely. The thing is that without the rule activated, it won't changes the game for AACW players, and we know some are against changes
For the rest, if you find the rule interesting, I will ask you to provide me with the script to incorporate in the current scenarios, for a future patch.
For the rest, if you find the rule interesting, I will ask you to provide me with the script to incorporate in the current scenarios, for a future patch.
Hofstadter's Law: "It always takes longer than you expect, even when you take into account Hofstadter's law."
New Commands: AddGarrison & ClearGarrisons
Concept: Auto Garrisoning
If the rule is enabled (Disabled by default for AACW, Enabled by default for NCP+), factions can possibly have garrisons created automatically in importants sites, depending of the availability of replacements in their repl pool.
Two aims, mostly: First to allow players to have some garrisons, as in history, without having to resort to spliting divisions and brigades (a chore what's more). Second to help the AI counter some skirmishes techniques which can be very nasty when done by players.
Is qualified as an important site: a Fort, a Depot, a City of level at least equals to half the maximum level possible for the game (see stcMaxLevel_, 10 for BOA, 20 for all others)
The Garrison can appears if a site exists, and:
a) Has no others units of the garrison type.
b) Has a garrison type defined by script (see below)
c) Has at least 75% military control
d) Is not besieged
e) Has at least one regular infantry (prevent cavalry raids to establish garrisons)
f) Has at least 100 supply points (if under the rule rulAdvancedSupply, BOA don't use this criteria)
If the garrison can appears, a % roll is made under the number of replacements in the pool (of the family of the first element of the garrison) time ChancePerRPL (see below).
If the roll is ok, a new unit appears, in the structure and one RPL is deduced from the pool. Note that garrisons units with several elements will be created with one, but will get others by the standard replacement rule, so in effect you can 'grow' multi-elements units on several turns.
Syntax:
AddGarrison AreaUID StrucKindUID UnitDefUID ChancePerRPL NULL NULL NULL NULL
(the 4 NULL are placeholders strings for a future upgraded version of the command)
and ClearGarrisons (clear all garrisons definition)
When you add a garrison, you add the reference to the unit definition used for that, for a given area and structure type. If you use -1, the garrison will be fit for any structure, otherwise you have to use these aliases:
$Fort = 1
$Depot = 2
$City = 3
Implementations 'levels':
a) at the most basic level, you will use one definition per nation: The area would be the map, strucKind at -1 and every structure to be garrisoned would get the same kind of garrison (a militia eg.)
b) more advanced, you specify several areas. For NCP Wurtemberg garrisons in WUR for example, or Kentucky Militia in KY, etc.
c) The 'deluxe' scripting would be to change the garrison for the 3 structures. For example a conscript unit for cities, a single militia for depot and for forts, a unit made of 2 reserve line regiments and one fort battery. That would be perfect!
Concept: Auto Garrisoning
If the rule is enabled (Disabled by default for AACW, Enabled by default for NCP+), factions can possibly have garrisons created automatically in importants sites, depending of the availability of replacements in their repl pool.
Two aims, mostly: First to allow players to have some garrisons, as in history, without having to resort to spliting divisions and brigades (a chore what's more). Second to help the AI counter some skirmishes techniques which can be very nasty when done by players.
Is qualified as an important site: a Fort, a Depot, a City of level at least equals to half the maximum level possible for the game (see stcMaxLevel_, 10 for BOA, 20 for all others)
The Garrison can appears if a site exists, and:
a) Has no others units of the garrison type.
b) Has a garrison type defined by script (see below)
c) Has at least 75% military control
d) Is not besieged
e) Has at least one regular infantry (prevent cavalry raids to establish garrisons)
f) Has at least 100 supply points (if under the rule rulAdvancedSupply, BOA don't use this criteria)
If the garrison can appears, a % roll is made under the number of replacements in the pool (of the family of the first element of the garrison) time ChancePerRPL (see below).
If the roll is ok, a new unit appears, in the structure and one RPL is deduced from the pool. Note that garrisons units with several elements will be created with one, but will get others by the standard replacement rule, so in effect you can 'grow' multi-elements units on several turns.
Syntax:
AddGarrison AreaUID StrucKindUID UnitDefUID ChancePerRPL NULL NULL NULL NULL
(the 4 NULL are placeholders strings for a future upgraded version of the command)
and ClearGarrisons (clear all garrisons definition)
When you add a garrison, you add the reference to the unit definition used for that, for a given area and structure type. If you use -1, the garrison will be fit for any structure, otherwise you have to use these aliases:
$Fort = 1
$Depot = 2
$City = 3
Implementations 'levels':
a) at the most basic level, you will use one definition per nation: The area would be the map, strucKind at -1 and every structure to be garrisoned would get the same kind of garrison (a militia eg.)
b) more advanced, you specify several areas. For NCP Wurtemberg garrisons in WUR for example, or Kentucky Militia in KY, etc.
c) The 'deluxe' scripting would be to change the garrison for the 3 structures. For example a conscript unit for cities, a single militia for depot and for forts, a unit made of 2 reserve line regiments and one fort battery. That would be perfect!
Hofstadter's Law: "It always takes longer than you expect, even when you take into account Hofstadter's law."
Being imaginative at time (rare though), I have done the command in a way that it can be used for others things. For example with a bit of upgrade (so the 4 parameters I have put in case of) you can use this command to have an AI produce new units from some sites. For example native tribes in VGN, or even monster lairs in an heroic fantasy game 
Hofstadter's Law: "It always takes longer than you expect, even when you take into account Hofstadter's law."
Here is the code for the script parsing of the command. This is for Rafiki to understand how the command must be labelled, but if you spot errors, fire!
Code: Select all
// ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
// ADD GARRISON
// Ajoute une garnison à la faction
// ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
function TScriptEngine.AddGarrison(Params : TStringList) : integer;
var
AreaUID : TUID;
StrucKind : TUID;
UnitUID : TUID;
Chance : integer;
begin
Result := 0;
if (Params.Count <> 8) then
begin
Inc(Result);
Log(['=> Add Garrison , syntax is: AddGarrison = AreaUID ; StrucKindUID ; UnitDefUID ; ChancePerRPL; PlaceHolder1; PlaceHolder2; PlaceHolder3; PlaceHolder4']);
end;
if (cuFaction = nil) then
begin
Inc(Result);
Log(['=> AddGarrison: No faction selected']);
end;
AreaUID := STI(Params[0]);
StrucKind := STI(Params[1]);
UnitUID := STI(Params[2]);
Chance := STI(Params[3]);
if (AreaUID < 0) or (AreaUID > Areas.Count-1) then
begin
Inc(Result);
Log(['=> Add Garrison , Erroneous AreaUID', AreaUID]);
end;
if (StrucKind < _noUID) or (StrucKind > _stuMax) then
begin
Inc(Result);
Log(['=> Add Garrison , Erroneous StrucKind', StrucKind]);
end;
if (UnitUID < 0) or (UnitUID > ListUnitDefs.Count-1) then
begin
Inc(Result);
Log(['=> Add Garrison , Erroneous UnitUID', UnitUID]);
end;
if (Chance <= 0) then
begin
Inc(Result);
Log(['=> Add Garrison , Erroneous Chance value', Chance]);
end;
if Result > 0 then Exit;
cuFaction.AddGarrisonsInfos(AreaUID, StrucKind, UnitUID, Chance);
Log(['Add Garrison , Added this garrison:', 'AreaUID:', AreaUID, 'StrucKind:', StrucKind, 'UnitDefUID:', UnitUID, 'ChancePerRPL:', Chance]);
end;
// ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
// CLEAR GARRISONS
// ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
function TScriptEngine.ClearGarrisons(Params : TStringList) : integer;
begin
Result := 0;
if (Params.Count > 0) then
begin
Log(['=> [WARNING] Clear Garrisons Garrison , syntax is: ClearGarrisons, no parameter are needed.']);
end;
if (cuFaction = nil) then
begin
Inc(Result);
Log(['=> Clear Garrisons: No faction selected']);
end;
if Result > 0 then Exit;
cuFaction.ClearGarrisonsInfos;
Log(['Clear Garrisons , All Garrisons cleared for faction', cuFaction.UID, cuFaction.Name]);
end;
Hofstadter's Law: "It always takes longer than you expect, even when you take into account Hofstadter's law."
-
McNaughton
- Posts: 2766
- Joined: Wed Mar 21, 2007 8:47 pm
- Location: Toronto, Canada
I believe that the regular regiment requirement is based on the trigger looking for (at minimum) one infantry unit in the stack (stopping these larger garrisons appearing just by a marauding cavalry force). There would be no additional micromanagement required, I believe, as it primarily is to check for the force nearby, to given an appropriate response by the garrison engine (i.e., a way to get the engine to react to the particular force against it, not just to any force).
I'm not entirely sure how much I like this, at least when applied to the player (I'm all in favour for things that help the AI in not-too-gamey ways)
The way I see it, planning garrisons is one of the strategic aspects that a player need to have an opinion on. Do I safe it and build stationary garrisons everywhere I'm afraid the enemy raiders might come? Do I build up mobile forces that can react to raids? Do I consider the raids to be mere nuisances that don't need to be handled while my main forces march forward?
By having these events, that choice is in a fair number of ways taken away from the player. Depending on the luck of the dice, the player is committed to spending replacements to bring into being garrisons he might have decided he could do without.
Additionally, since there is a random chance that the garrison might not appear, a cautious player will still garrison important places (so it's guaranteed that there is at least something there), but might end up with double garrisons when the forces provided by these events show up, thereby wasting resources that might've been used better elsewhere.
That said, I think it's good to explore new ways to minimize micromanagement, and I also appreciate the thorough explanation you provided Pocus
The way I see it, planning garrisons is one of the strategic aspects that a player need to have an opinion on. Do I safe it and build stationary garrisons everywhere I'm afraid the enemy raiders might come? Do I build up mobile forces that can react to raids? Do I consider the raids to be mere nuisances that don't need to be handled while my main forces march forward?
By having these events, that choice is in a fair number of ways taken away from the player. Depending on the luck of the dice, the player is committed to spending replacements to bring into being garrisons he might have decided he could do without.
Additionally, since there is a random chance that the garrison might not appear, a cautious player will still garrison important places (so it's guaranteed that there is at least something there), but might end up with double garrisons when the forces provided by these events show up, thereby wasting resources that might've been used better elsewhere.
That said, I think it's good to explore new ways to minimize micromanagement, and I also appreciate the thorough explanation you provided Pocus
Clovis, I added this condition for the reason and aim McNaughton said. (this prevent me from buidling yet another batch of awkward english sentences ).
Rafiki, I understand your concern. The rule is there for NCP before all, because we won't have the player being able to build a ton of militia for this purpose, and as the campaigns can be very dynamic, even if the players could get second-line troops for garrisoning, they would arrive too late where he need them... so this automation was needed.
For ACW, things are bit different, I concur. Also you are right about the doubling of force, because a prudent player don't want to wait for a garrison to appears... although I was seeing the thing in a different way: you take a fortress. The rule is active. So you know that eventually your first line troops will be discharged of the duty of garrisoning it. When it happens (garrison appearing), you move away your force. Somehow you reversed my logic, but don't forget that when you have a new spot to garrison, generally it means you just arrived there with combat troops, so it is not like you have to move purposely troops there. (Don't know if i'm clear enough)
The rule will be optional for AACW don't forget. Players will have these choices: no garrisoning, only for AI, for both. So if it bothers you to see choices taken away from you, just enable that for the AI.
Also what is great is that at last there is a mean for the AI to receive a competent garrison in captured coastal forts. Create a unit with some reserve infantry regiment and a coastal gun or two, and wait for it to appears. And voila, the fort is functionning!
).Rafiki, I understand your concern. The rule is there for NCP before all, because we won't have the player being able to build a ton of militia for this purpose, and as the campaigns can be very dynamic, even if the players could get second-line troops for garrisoning, they would arrive too late where he need them... so this automation was needed.
For ACW, things are bit different, I concur. Also you are right about the doubling of force, because a prudent player don't want to wait for a garrison to appears... although I was seeing the thing in a different way: you take a fortress. The rule is active. So you know that eventually your first line troops will be discharged of the duty of garrisoning it. When it happens (garrison appearing), you move away your force. Somehow you reversed my logic, but don't forget that when you have a new spot to garrison, generally it means you just arrived there with combat troops, so it is not like you have to move purposely troops there. (Don't know if i'm clear enough)
The rule will be optional for AACW don't forget. Players will have these choices: no garrisoning, only for AI, for both. So if it bothers you to see choices taken away from you, just enable that for the AI.
Also what is great is that at last there is a mean for the AI to receive a competent garrison in captured coastal forts. Create a unit with some reserve infantry regiment and a coastal gun or two, and wait for it to appears. And voila, the fort is functionning!
Hofstadter's Law: "It always takes longer than you expect, even when you take into account Hofstadter's law."
If one of the aim is to make Athena more efficient, I don't a reason why the garisoning rule should be optional for her.
IMHO the only choice available to the player should be: Does HE want to play with this rule, yes or no. The basic setting for Athena should be the more efficient one. Let's not overcomplicate the choices available to the player.
NB: we could do the same thing for the aggresivness, I believe Athena is more efficient with the first level of agressivness, if everybody agrees it should be the basic setting).
IMHO the only choice available to the player should be: Does HE want to play with this rule, yes or no. The basic setting for Athena should be the more efficient one. Let's not overcomplicate the choices available to the player.
NB: we could do the same thing for the aggresivness, I believe Athena is more efficient with the first level of agressivness, if everybody agrees it should be the basic setting).
"Never argue with a fool, onlookers may not be able to tell the difference." Mark Twain
For AACW I'm unsure Athena should benefits from the rule by default. After all, some can say she is now cheating. For NCP, different story, the rule will be there from the start.
Well, I'm just thinking aloud there anyway.
Well, I'm just thinking aloud there anyway.
Hofstadter's Law: "It always takes longer than you expect, even when you take into account Hofstadter's law."
done. Feel free to use :
SelectFaction = CSA
AddGarrison = $NY;-1;$mdl_CSA_Inf10;10
SelectFaction = CSA
AddGarrison = $CT;-1;$mdl_CSA_Inf10;10
SelectFaction = CSA
AddGarrison = $PA;-1;$mdl_CSA_Inf10;10
SelectFaction = CSA
AddGarrison = $MD;-1;$mdl_CSA_Inf10;10
SelectFaction = CSA
AddGarrison = $NJ;-1;$mdl_CSA_Inf10;10
SelectFaction = CSA
AddGarrison = $DE;-1;$mdl_CSA_Inf10;10
SelectFaction = CSA
AddGarrison = $VA;-1;$mdl_CSA_Inf10;10
SelectFaction = CSA
AddGarrison = $OH;-1;$mdl_CSA_Inf10;10
SelectFaction = CSA
AddGarrison = $MI;-1;$mdl_CSA_Inf10;10
SelectFaction = CSA
AddGarrison = $WV;-1;$mdl_CSA_Inf10;10
SelectFaction = CSA
AddGarrison = $IN;-1;$mdl_CSA_Inf10;10
SelectFaction = CSA
AddGarrison = $KY;-1;$mdl_CSA_Inf10;10
SelectFaction = CSA
AddGarrison = $TN;-1;$mdl_CSA_Inf10;10
SelectFaction = CSA
AddGarrison = $WI;-1;$mdl_CSA_Inf10;10
SelectFaction = CSA
AddGarrison = $IL;-1;$mdl_CSA_Inf10;10
SelectFaction = CSA
AddGarrison = $MO;-1;$mdl_CSA_Inf10;10
SelectFaction = CSA
AddGarrison = $KS;-1;$mdl_CSA_Inf10;10
SelectFaction = USA
AddGarrison = $VA;-1;$mdl_USA_Inf11;20
SelectFaction = USA
AddGarrison = $NC;-1;$mdl_USA_Inf11;20
SelectFaction = USA
AddGarrison = $SC;-1;$mdl_USA_Inf11;20
SelectFaction = USA
AddGarrison = $GA;-1;$mdl_USA_Inf11;20
SelectFaction = USA
AddGarrison = $FL;-1;$mdl_USA_Inf11;20
SelectFaction = USA
AddGarrison = $VW;-1;$mdl_USA_Inf11;20
SelectFaction = USA
AddGarrison = $IN;-1;$mdl_USA_Inf11;20
SelectFaction = USA
AddGarrison = $KY;-1;$mdl_USA_Inf11;20
SelectFaction = USA
AddGarrison = $TN;-1;$mdl_USA_Inf11;20
SelectFaction = USA
AddGarrison = $AL;-1;$mdl_USA_Inf11;20
SelectFaction = USA
AddGarrison = $MS;-1;$mdl_USA_Inf11;20
SelectFaction = USA
AddGarrison = $LA;-1;$mdl_USA_Inf11;20
SelectFaction = USA
AddGarrison = $TX;-1;$mdl_USA_Inf11;20
SelectFaction = USA
AddGarrison = $AR;-1;$mdl_USA_Inf11;20
SelectFaction = USA
AddGarrison = $IL;-1;$mdl_USA_Inf11;20
SelectFaction = USA
AddGarrison = $MO;-1;$mdl_USA_Inf11;20
SelectFaction = USA
AddGarrison = $IA;-1;$mdl_USA_Inf11;20
SelectFaction = USA
AddGarrison = $KS;-1;$mdl_USA_Inf11;20
SelectFaction = CSA
AddGarrison = $NY;-1;$mdl_CSA_Inf10;10
SelectFaction = CSA
AddGarrison = $CT;-1;$mdl_CSA_Inf10;10
SelectFaction = CSA
AddGarrison = $PA;-1;$mdl_CSA_Inf10;10
SelectFaction = CSA
AddGarrison = $MD;-1;$mdl_CSA_Inf10;10
SelectFaction = CSA
AddGarrison = $NJ;-1;$mdl_CSA_Inf10;10
SelectFaction = CSA
AddGarrison = $DE;-1;$mdl_CSA_Inf10;10
SelectFaction = CSA
AddGarrison = $VA;-1;$mdl_CSA_Inf10;10
SelectFaction = CSA
AddGarrison = $OH;-1;$mdl_CSA_Inf10;10
SelectFaction = CSA
AddGarrison = $MI;-1;$mdl_CSA_Inf10;10
SelectFaction = CSA
AddGarrison = $WV;-1;$mdl_CSA_Inf10;10
SelectFaction = CSA
AddGarrison = $IN;-1;$mdl_CSA_Inf10;10
SelectFaction = CSA
AddGarrison = $KY;-1;$mdl_CSA_Inf10;10
SelectFaction = CSA
AddGarrison = $TN;-1;$mdl_CSA_Inf10;10
SelectFaction = CSA
AddGarrison = $WI;-1;$mdl_CSA_Inf10;10
SelectFaction = CSA
AddGarrison = $IL;-1;$mdl_CSA_Inf10;10
SelectFaction = CSA
AddGarrison = $MO;-1;$mdl_CSA_Inf10;10
SelectFaction = CSA
AddGarrison = $KS;-1;$mdl_CSA_Inf10;10
SelectFaction = USA
AddGarrison = $VA;-1;$mdl_USA_Inf11;20
SelectFaction = USA
AddGarrison = $NC;-1;$mdl_USA_Inf11;20
SelectFaction = USA
AddGarrison = $SC;-1;$mdl_USA_Inf11;20
SelectFaction = USA
AddGarrison = $GA;-1;$mdl_USA_Inf11;20
SelectFaction = USA
AddGarrison = $FL;-1;$mdl_USA_Inf11;20
SelectFaction = USA
AddGarrison = $VW;-1;$mdl_USA_Inf11;20
SelectFaction = USA
AddGarrison = $IN;-1;$mdl_USA_Inf11;20
SelectFaction = USA
AddGarrison = $KY;-1;$mdl_USA_Inf11;20
SelectFaction = USA
AddGarrison = $TN;-1;$mdl_USA_Inf11;20
SelectFaction = USA
AddGarrison = $AL;-1;$mdl_USA_Inf11;20
SelectFaction = USA
AddGarrison = $MS;-1;$mdl_USA_Inf11;20
SelectFaction = USA
AddGarrison = $LA;-1;$mdl_USA_Inf11;20
SelectFaction = USA
AddGarrison = $TX;-1;$mdl_USA_Inf11;20
SelectFaction = USA
AddGarrison = $AR;-1;$mdl_USA_Inf11;20
SelectFaction = USA
AddGarrison = $IL;-1;$mdl_USA_Inf11;20
SelectFaction = USA
AddGarrison = $MO;-1;$mdl_USA_Inf11;20
SelectFaction = USA
AddGarrison = $IA;-1;$mdl_USA_Inf11;20
SelectFaction = USA
AddGarrison = $KS;-1;$mdl_USA_Inf11;20
Pocus wrote:New Commands: AddGarrison & ClearGarrisons
Concept: Auto Garrisoning
An Interesting Idea folks! Good one!
For ACW I think Clovis has a good point that maybe 25-30% MC is good!
What about garrisons in strategic cities or VP cities only? The AI usually has a
bad habit of giving up strategic sites or leaving them unattended?
This rule is a must I think for ACW!
It's really a shame this did'nt make it into the 1.08 patch.
bigus
Clovis wrote:OK I've put the new data at the end of the variousevents.xls file:
Did these ever make it into the game? I wanted to try a round of ACW with auto-garrisons to see how it would work out (admittedly not having given them much thought the last weeks), but can't find any traces of it in ACW, niether on activating the rule nor on the events themselves.
Disclaimer: I may have misunderstood how this all would relate to ACW
Rafiki wrote:Clovis, is this something you have done/are doing work on? I'd like to take a shot at it, either from scratch or building off the work already done
(I want to become more familiar with how modding/scripting works
I will send you the files next week ( not at home for now)
[LEFT]Disabled
[CENTER][LEFT]
[/LEFT]
[LEFT]SVF news: http://struggleformodding.wordpress.com/
[/LEFT]
[/CENTER]
[/LEFT]
[CENTER][LEFT]
[/LEFT]
[LEFT]SVF news: http://struggleformodding.wordpress.com/
[/LEFT]
[/CENTER]
[/LEFT]
Thanks, a.m.vedo-h@nsen.ch if you don't have the address from elsewhere
Here is the addgarrison events I have in the Kentucky scenario.
[ATTACH]2219[/ATTACH]
Is this the correct way to implement this command?
If so ...I am not seeing a garrison created. I assume this is because I don't have a level 10 city in the scenario (ACW)? If this is the case, what are the chances of reducing the city level needed to create a garrison.
sorry for the flood of questions but I'd like to get this to work.
bigus
[ATTACH]2219[/ATTACH]
Is this the correct way to implement this command?
If so ...I am not seeing a garrison created. I assume this is because I don't have a level 10 city in the scenario (ACW)? If this is the case, what are the chances of reducing the city level needed to create a garrison.
sorry for the flood of questions but I'd like to get this to work.
bigus
- Attachments
-
You are missing the 4 placeholders data at the end of the command, they are needed.
AddGarrison = $NY;-1;$mdl_CSA_Inf10;10;x;x;x;x
the command must be in the setup or within an event. It does not seem to be the case in your xls excerpt.
The garrison has 10% chance of appearing in your case, for each RPL you have in stock of the type needed by the unit you use (regular I guess). Region which qualify are: has a depot, has a fort, or has a city of level 7+
city level variable is not exported yet. you have to strike the balance between adding garrison in a sufficient number of place and not sucking the rpl pool by adding them everywhere, so it seems ok to me.
AddGarrison = $NY;-1;$mdl_CSA_Inf10;10;x;x;x;x
the command must be in the setup or within an event. It does not seem to be the case in your xls excerpt.
The garrison has 10% chance of appearing in your case, for each RPL you have in stock of the type needed by the unit you use (regular I guess). Region which qualify are: has a depot, has a fort, or has a city of level 7+
city level variable is not exported yet. you have to strike the balance between adding garrison in a sufficient number of place and not sucking the rpl pool by adding them everywhere, so it seems ok to me.
Hofstadter's Law: "It always takes longer than you expect, even when you take into account Hofstadter's law."
Pocus wrote:You are missing the 4 placeholders data at the end of the command, they are needed.
AddGarrison = $NY;-1;$mdl_CSA_Inf10;10;x;x;x;x
the command must be in the setup or within an event. It does not seem to be the case in your xls excerpt.
The garrison has 10% chance of appearing in your case, for each RPL you have in stock of the type needed by the unit you use (regular I guess). Region which qualify are: has a depot, has a fort, or has a city of level 7+
city level variable is not exported yet. you have to strike the balance between adding garrison in a sufficient number of place and not sucking the rpl pool by adding them everywhere, so it seems ok to me.
Are the placeholders "Null"?
Are you saying I need to add a "start event" and end with an "end event" Or Can I just place it in the setup at start Tab and not the Events tab?
I would like to place the commands in the "setup at start" if I can.
bigus
Helping Athena?
I assume that this is 'script language', and so I could write an event that:
1. Checks AI level >= 1
2. Implements AddGarrison
Run this at the first opportunity [not in setup, as I'm not sure how to check AI there]...
This would be a powerful tool if we can't get Athena to protect her rear....
....and it's a beautiful rear, I'm sure....
1. Checks AI level >= 1
2. Implements AddGarrison
Run this at the first opportunity [not in setup, as I'm not sure how to check AI there]...
This would be a powerful tool if we can't get Athena to protect her rear....
....and it's a beautiful rear, I'm sure....
Always ask yourself: "Am I part of the Solution?" If you aren't, then you are part of the Problem!
[CENTER][/CENTER]
[CENTER]Visit AGEWiki - your increasingly comprehensive source for information about AGE games[/CENTER]
[CENTER]Rules for new members[/CENTER]
[CENTER]Forum Rules[/CENTER]
[CENTER]Help desk: support@slitherine.co.uk[/CENTER]
[CENTER][/CENTER]
[CENTER]Visit AGEWiki - your increasingly comprehensive source for information about AGE games[/CENTER]
[CENTER]Rules for new members[/CENTER]
[CENTER]Forum Rules[/CENTER]
[CENTER]Help desk: support@slitherine.co.uk[/CENTER]
Return to “Modding AGE engine games”
Who is online
Users browsing this forum: No registered users and 8 guests