Tutorials?
 

I just posted my issue over in the Warlord AB file forum since that is the AB files I am working with.

But, figured I would come over here to ask this more general question.

I have read the small descriptons related to overrides and exceptions in the downloaded creator manual. But, just isnt giving me enough to be able to do it myself.

I need examples.

I gave some specific examples in my post under the Warlord area.

I am hoping that a better tutorial might be written by someone using my datafiles as the backdrop and my specific examples that I am needing help with. I have many more over rides and exceptions to do than the few examples I listed. But, 95% of them are the same as those examples, so if I can get someone to help me do those few (and explain it to where I can understand) then I can and will gladly do the rest and then make my results available for all.

Thank you for your time.

Jason

Again, I ask about better scripting tutorials.

The given tutorials are ok, but too generic to be of help to me.

Here is an example of one I need:

I have created an item that is only for one faction. It is an item that only a spellcaster can carry. Said spellcasters can purchase a certain number of those items equal to a number of one of their card stats.

I am having difficulties trying to figure out which set of variables, tags, or whatever you want to call them that match what I am needing. I have tried all sorts of combinations and not getting very far...

what is the correct script (to be used in over ride) for returning a model's runtime leader of the squad?

I was thinking that if I checkmarked the box that says Is Leader then it should flag the leader ID or something like that (I read in a different thread).. And therefore it should be something similar to the following:

runtime.leader."leader's unique id"

leader.runtime.isunit["leader's unique id"]


Or even better, what is the script that returns the runtime squad name of a model? that is, if in the data file unit section, in the "other details" area, I assign a squad name there, I assume then if I add this model along with other models under it, then I should be able to do an over ride script that checks to see if the the model is included in the squad with that squad name. And trying to figure out the correct tags or script or whatnot.

And last for now, in the over rides pop up box, under the conditions box, there are boxes like squad name, cost, etc... How do I include those into the conditions instead of the results? That is I want the items on the left side of that pop up box to be condition factors and the items on the right side to be the results...

bumping to see if I can get these last couple of questions answered.

What is the correct script phrase to return the runtime leader of a squad member?

What is the correct script phrase to return a particular stat from a unit?

the stat one depends on if you are looing at a basestat or the stat.

for a stat (assuming numeric and stat is called xyz)

var retval as number
retval = stat[xyz]
(for a unit)

var retval as number
retval = unit.stat[xyz]
(for an option)

to access basestats then replace stat with basestat

Thank you for the feedback. Now, I will go see if I can take what you have given me and see if I can get to work for what I need.

Tutorials?
 

I'm not 100% sure I understand what you're trying to accomplish here. However, I'm pretty sure that you can't accomplish any of the things you specifically are asking for. So what I need is a detailed description of what you're trying to ACHIEVE. Please note the word I'm using. Tell me the goal of what you ultimately want to accomplish. Don't bother telling me what mechanism you are trying to use to accomplish the goal, since you'll likely need a different approach based on my reading of your questions below.

Please note that I don't have a CLUE about how the Warlord data files are written, and I am NOT very familiar with the army construction rules for the game. So you'll need to outline all the pertain game mechanics that I'll need to understand. You'll also need to outline how the existing Warlord files are written with respect to the mechanics you're trying to splice into. Armed with that, I'll do my best to offer suggestions for how to solve things.

-Rob


At 12:53 PM 12/29/2006, you wrote:

Rob,

Thanks for the reply. I guess I should start off by giving as short as possible game build construction rules, then about these related AB files.

Normal build rules for Warlord are fairly simple. The army unit "adepts" are the only real difficult model type. I will have to use several examples to show how they work. First, You have 4 main types: leaders, elites, soldiers, solos.

Leaders:

Warlords
Captains
Sgts

Elites:

Mages
clerics
heros
etc..

Soldiers:

adept
grunt

solos:

monsters
Solotaires
etc..

Builds are made up of troops. Each troop will either be a leader led group or a solo. The number of solo troops can never exceed the number of leader led troops. Leader led troops can start out having any level of leader, but the more troops you have the higher level leader is requied. Two sargeant led troops are fine, but three saregeant led troops requires that at least one captain led trrop is involved. two captain led troops is fine but a third captain led troop requires a warlord led troop. You not required to have a warlord with smaller groups, but you can if you want. If you do bring in a warlord for any size build it suffices for all higher level leader needs (i.e. you could run 3+ sargeants under a warlord without having a captain)

Each leader has a certain number of soldiers it can field in its troop. The average sgt will have 4-10/0. The average captain will have 4-12/1. The average Warlord will have 4-12/2. The numbers before the / are the total number of units that a leader can lead in its own troop. The number after the / indicates how many of those numbers can be elite models.

The number of grunts in a build are only limited by the leaders' limitations for fielding them. Adepts have a second limitation. Each type of adept can only be fielded in a single troop for every full 1000 points of the build limit, no matter what the actual army worth is. That is, even if my total construct value is only worth 1998 points, if the build limit was set at 2000, then 2000 is what the adept limit is based on.

So, trying my best to give examples without writing a book (too late): Each faction has a different set of grunts and adepts, so for now, I will use the Warlord faction Crusaders as my example. For the main crusader faction list, just using a few types, archers and knights are both considered adepts while breakers are considered grunts.

In a 1000 point build, I could put archers and knights in the same troop or in separate troops, but I could not put them in multiple troops (each adept type can only be fielded in a single troop for every full 1000 point build limit). In a 2000 point build, I could then have a second troop of either or both of them.

Legal 1000 pt build:

troop1
sgt
4 archers
4 breakers

troop2
sgt
4 knights
4 breakers
----------------------------------------

Legal 1000 pt build:

troop 1
sgt
5 archers
3 knights
2 breakers

troop2
captain
10 breakers
------------------------------------

Illegal 1000 pt build

troop1:
sgt
4 archers
4 breakers

troop2:
sgt
2 archers
4 knights
2 breakers
------------------------------------
This last one would be legal in a 2000 point build as then the adept limit would rise.

Oh, and one last build rule of significance... The has to be a 1:4 ratio of elites to soldiers in any troop that contains an elite. Therefore, if you have an elite, you must also have several soldiers for support.

So, that is a quick summary of the default warlord construct rules. I'll address the next thing in a subsequent post.

All factions have some sublist groups that if you restrict your army build to those sublists of units, then you can gain some different build or game benefits. In almost all sublists, at least one of faction adepts becomes grunts (thereby eliminating the troop involvement restrictions). We have been able to use the over rides area to handle this in most cases.

One of my first ITEMS OF ACHIEVEMENT that I am needing help with, relates to this idea of adepts becoming grunts in certain situations. When they become grunts based on being in a sublist it is not hard cause the adepts changes for the whole list, just throw in an override to check and see if the roster is of the sublist name. But, if instead, if an adept changes to a grunt inside of an actual troop and not an entire list, that is where I am having a problem.

Using my "Illegal example" from the crusader lsit above, If I swapped out the sgt in troop 2 with the unique Warlord Gerard model, then it would become legal. Cause Gerard has a special rule that says in an all crusader army, any adepts fielded in his personal troop do not count against the overall build adept limit.

My logic that I am trying to use in AB is, asking it from the point of view of the adept, and saying "if I am part of roster.crusader and the runtime leader of my squad is Gerard, then I am a grunt not an adept, else I am still an adept".

You asked me to try and give you some insight as to how the AB files are set up. I am not the original author, I have just been figuring out how the original author had things set up and adding on to it. But, I will give my best to try and explain what I have figured out.

See, in the beginning I never had to read any of the included tutorials or look at other game's AB files cause it was fairly easy to figure out how the original author had set things up. I wasnt building anything, I was just replicating what he had already built or massaging areas that he had already set up. It is not until now, that I am trying to add things that are not included in there that I am having to now go back and try to learn the insides and outs on this thing.

Although you wouldnt know it, I have now tried writing something here about 10 times without really knowing what to write. I think that in regards tot he actual file set up and such, it might be better if you asked specific questions that could lead you to what you are needing. Unlike the Warlord build rules, it is not easy for me to ttry and tell you how the AB files are made. I already heard the snoring from putting people to sleep with my earlier rambling. It would be worse i I tried to explain the AB files setup.

I will talk about my second GOAL of achievement in a separate thread so that I can try to keep them each on topic and less confusion.

Tutorials?
 

Actually, your descriptions have been extremely helpful. I think I now grasp the two fundamental issues here. I now understand how the Warlord system is structured sufficiently to also understand the problem with particular leaders causing units to change their behavior when taken with that leader.

Now, there is one critical thing remaining that I don't know about the existing Warload files. However, I'm going to provide an answer at a conceptual level anyways. Hopefully, you'll be able to take this explanation and map it to the existing Warlord files.

The actual classification of a unit as leader/elite/etc should almost certainly be done via tags. So the trick is going to be to delete the current classification tag and assign the correct new one via scripts tied to options. I believe there is a topic about this technique in the documentaion, but it's for something slightly different. The topic is entitled "Re-Classifying Units When They Are Allies". You want the same basic behavior, except for a slightly different circumstance.

The trick is going to be figuring out how to recognize and trigger the appropriate changes within the Warlord data files. From looking at the files, all units are placed into squads, with a squad containing some mixture of leaders, elites, etc. Unfortunately, this means that there is no direct linkage between the leaders and their followers. That means that there is no way to actually have Warlord Gerard trigger a modification of the adepts in his squad, nor is there a way to have the adepts recognize the precence of Warlord Gerard (using your example). So things become ugly. :-(

I assume there are squad rules in place that verify the composition structure is properly maintained for each squad. If so, then the solution will need to be in using a variety of accrued tags and checking those tags within the squad rules. For example, the Warlord Gerard could assign an accrued tag identifying his present, as could the soldiers are treated specially in his presence. In the squad rule, you would first get the counts of the different classifications (leader, elite, etc.). Once you have the totals, you would perform a series of tests that would modify these numbers. For example, you would test for the presence of the Warlord Gerard tag. If you found it, then you would get the count of the number of the soldiers that get re-classified. You would then subtract that number from the total number of soldiers.

After all of the appropriate adjustments have been applied, you could then apply the actual rule tests that verify the ratios are correct.

There is another mechanism you can use, but I'm not certain how helpful it would be. AB has something called "Aggregate Contexts". You'll find details on this within the docs. In a nutshell, you could write a global SquadDone script that does some of the aforementioned testing. Since you can add and remove tags within a SquadDone script, you could effectively re-classify units by adding and removing tags. Then those tags would be in place when the squad rules were tested.

Hope this helps,
Rob

Logically, it does help.

But implementation wise it does nothing for me. I apologize for my wording. But, my weakness with AB is that I dont know when or where to use a this.tag or a tag.this or unit.whatever... and it gets worse when you probably need something like a this.unit[tag].item[tag] or whatever other possible combos there are out there. I have tons of logic in me, its the trying to figure out how to actually use it that is keeping me from even being able to tinker to find my way along.

If I could learn how to use the scripts and codes then I could atleast start to tinker with it and try different things. But, I cant get past the syntax and correct usage to be able to even try.

Is there any part in those documentation that simply focuses on that part?

One question for clarification on the Gerard tag. Are you saying it is not possible to check or return the runtime value of the squad name of a model? Adding a model to Gerard's squad, where Gerards' squad name = Gerard. Check to see if the model is now included in the squad Gerard. If true then run override script that changes the model's personal type tag from adept to grunt.

?

Again thanks for your help.. Please have patience with me, as I really do want to learn this stuff.

Suggested way of going about the Gerard issue:

First define a string in the dat file, as an example:

unique id: gerard
text: Gerard

in the gerard unit prelink section (so it is actioned first):
squad.name = $gerard

(the reason behind this is so that when a comparison is made later on then you are only referencing one string and hence avoiding mistypes etc, plus the squad name and any references etc are always pointing to the same thing)

Next in the appropriate unit's postlink section (for the model that may be added to the gerrard unit):

~ first check the parent squad name, if gerard then action taken
if (parent.squad.name = $gerard) then

~define variable for tag assignment return
var retval as number

~remove any previous personal tags
retval = delete[personal.?]

~add new tag
retval = assign[personal.grunt]
endif

without knowing the mechanisms you are using to make the ration counts the above should work but may need to remove the 'parent.' bit, without testing with live code am not sure

I am trying to do what you are asking, cause it sounds just like what I am wanting to do. Couple of questions:

1. How and where do you do this? In Gerard's unit datacard, in the EDIT OTHER area, I can do a check box for uniqueness, and I can fill in a squad name, but ot sure if that is what you are talking about. Or do I do this in the PRE-Link area too?

2. Do I use "personal" or "type"? The types are created in the DEF file under Group tab.

Group ID : type
Group Name: Unit Type
with tags:
ID Tadept : Name Adept
ID TGrunt : Name Grunt
etc...

1. Open the def file in ABC (or a dat but will stick with the def file for ease), fourth to last tab on the top says 'String', click on that one and you can enter the string there

2. Sorry, that was me being unfamiliar with the overall tag sturcture of that particular datafile, from what you've put there is should be 'type'

Unfortunately, that did not work.

I tried it your way, and I also tried doing it as an over ride but the over ride did not like the syntax:

parent.squad.name

Maybe its a question of timing of when the Postlink is checked? I have seen in lots of places where the documentation says that placement of things is important cause it determines when in the process it gets checked. Is the postlink happening before the validation checks?

Tutorials?
 

At 01:23 PM 1/16/2007, you wrote:
There are three chapters specifically covering everything associated with the scripting. All are linked to from the main page of the documentation. There is a separate character covering the use of tags and tag expressions. Again, it is accessible from the main page of the documentation. There are extensive examples in the "How To" and "Tips & Tricks" chapters. Both of those chapters are linked from the main page.

I believe the examples are the most informative. You can refer to the other chapters for clarifications and to learn more about specific mechanisms.

-Rob

Tutorials?
 

At 02:42 PM 1/16/2007, you wrote:

Using a squad name is an extremely NON-efficient solution. It's also much more likely to break IMHO. Yes, it will work, but the use of an accrued tag is vastly better. Is there a particular reason that you feel the squad name is a better approach? I'm honestly curious, because you've been doing extensive work on the 40K files over the years and there may be issues/limitations I'm not aware of that justify this approach - in which case, Colen and I need to re-visit how things are handled in the engine. :-)

Thanks, Rob

Tutorials?
 

At 06:59 AM 1/18/2007, you wrote:

I don't believe doing this via an override will have any chance of really working.

The postlink is always invoked at the end of evaluation processing, but before validation. For specific timing details, see the topic Evaluation Sequence in the Fundamental Concepts chapter. You should also look at the debugging aids, since they will give you detailed info on the sequence in which things are occurring. These aids are outlined in the documentation.

As for helping you to solve this, I'll defer to Harkan, since this is his approach and I assume it's one he's used successfully in the 40K files somewhere. :-)

-Rob

Re: Tutorials?
 

lol, nah, to be honest comparing against a string instead of against a tag or similar is not an approach we'd use, was just trying to suggest a solution that would fit in to the way requested - a tagged solution would be a lot better and ensure a more efficient use of the system - saying that have asked for a copy of the files to see if there is a better way to implement this as trying to suggest methods without the code is a bit awkward :)

Here is a link to download the latest version of the files.

http://www.exodus-road.com/files/ab3...d1-10-2007.zip

Any help you can give is much appreciated !!!