Tutorials?

[rob]

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

[stubbdog]

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.

[harkan]

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

[stubbdog]

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

1.

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

unique id: gerard
text: Gerard

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.

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

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

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...

[harkan]

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'

[stubbdog]

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?

[rob]

At 01:23 PM 1/16/2007, you wrote:

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?

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

[rob]

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

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

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

[rob]

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

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?

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

[harkan]

Originally Posted by rob

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

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