Inheritance limits (was Question about glob:)

[rjs at inorbit.com]

--- In armybuilder@egroups.com, "Russell Sparkes" <rjs@i...> wrote:
> --- In armybuilder@egroups.com, Rob Bowes <rob@w...> wrote:
> > >Fair enough - it will achieve the exact same result anyway (and
> > >keep Army Builder happy) It's just heaps more work... Thanks
> > >Rob.
> >
> > I'd really like to understand how this adds heaps more work, since
> > that means I need to give serious thought to better ways of
> > managing things for a subsequent release.

Following on from the previous discussion (the inherited units are
working fine so far instead of glob, thanks...)
The maximum number of atributes is 100 (from ConstKit.rtf), so I can
have at most 100 mirr: attributes set for my leader Inheritor... I
think I'll be pushing it
If I split the inheritor into two and have about 60 mirr: attributes
in each one, then do two inhl: attributes for each leader unit, will
AB choke on it (assuming there's more than 100 attributes in total)?

The way the files work is:
I have a heap of options assigned (via cost) to the unit inheritor.
Each option is restricted by lglx:race=?? I also have the same
options assigned (via auto) to the leader inheritor combined with a
mirr: attribute for each option.
Does AB discard the mirr: attribute if there's no associated option
(having previously been discarded by lglx:race=??) or does it try to
load the whole lot and then discard the illegal ones?

I guess I'm asking where the limit is. Is it a limit on a loaded
unit, or a limit in the file format (or something else...)

Am I making sense?

Cheers,
Russell.
----
Russell Sparkes, rjs@inorbit.com http://www.cfm-resources.com/r/rjs
"Experience is what you get just after you needed it" - Unknown


To unsubscribe from this group, email

armybuilder-unsubscribe@egroups.com

 

[rob]

[No message]

 

[rjs at inorbit.com]

--- In armybuilder@egroups.com, Rob Bowes <rob@w...> wrote:
> At 06:09 AM 1/10/01 +0000, you wrote:
>
> What?!?!? What on Earth are you doing with THAT many mirr
> attributes? That's ridiculous! It sure sounds like the method
> you're using is far from the best solution. Please explain to me
> what you're trying to accomplish that has you solving it this way.

The way you set the files up is (just in case you've forgotten):
Each race has a unit inheritor and a leader inheritor. Each Warp
Magic spell for that race is assigned to the unit inheritor via cost
and the leader inheritor via auto, combined with a mirr: attribute to
make sure the two always match for a given unit. It's a very neat
solution
However... There are some units (Orc Natives) that can be taken by
almost any army, and where possible, can have the host army's Warp
Magic cast on them. So I figured I'd need to link in EVERY Warp Magic
option to (almost) every unit and restrict each one with lglx...
Taking that one step further for Mercenaries and or Allies where I
can field units from almost any other army - and still have them be
affected by the Warp Magic of the host army, I need to extend the
original idea to include every Warp Spell for every race...
So instead of one inheritor for each race, I was heading towards one
inheritor...

But that's ridiculous (apparently .

Ideas?

Cheers,
Russell
----
Russell Sparkes, rjs@inorbit.com http://www.cfm-resources.com/r/rjs
"Experience is what you get just after you needed it" - Unknown



To unsubscribe from this group, email

armybuilder-unsubscribe@egroups.com

 

[rob]

[No message]