• Please note: In an effort to ensure that all of our users feel welcome on our forums, we’ve updated our forum rules. You can review the updated rules here: http://forums.wolflair.com/showthread.php?t=5528.

    If a fellow Community member is not following the forum rules, please report the post by clicking the Report button (the red yield sign on the left) located on every post. This will notify the moderators directly. If you have any questions about these new rules, please contact support@wolflair.com.

    - The Lone Wolf Development Team

Item and Option interaction

  • Thread starter Thread starter Teatime at portentmail.co
  • Start date Start date
T

Teatime at portentmail.co

Guest
Hi all,

Another newbie for the mill! Hopefully that means my queries are
simple to answer...

General expression of the problem: I am working on a new datafile for
an existing system. I have both Options and Items that modify stats
through the base: and stat: options respectively. In order to remain
faithful to the mechanics of the game system the stat modifications
activated by the Options really need to be evaluated before the
modifications made by the Item. Unfortunately I find that the Item
always takes priority and the resulting stat is miscalculated.

Questions:
1. Is there a way of having an Item activate an Option? If there were
I could hide an option with the appropriate priority and have it do
the stat modification instead.

2. Is there a way of changing the priority of an Item so that it is
evaluated after an Option? I tried a ipri: and going through a Tweak
to no effect. I wouldn't want the Item evaluated after ALL Options,
as there are some where it is appropriate to calculate it first.

3. Is there some other solution to my problem? I am a newbie after
all. It would be ugly to change the Item to an Option instead, since
it wouldn't match all the others of its type. I'd prefer not to have
an option that must be activated manually by the user after they've
bought the item.

Background to the problem: I've input a new warband for Mordheim, the
Norse Reavers. The Frenzy ability doesn't calculate Attacks properly
generally (order should be stat mods, then *2 for frenzy, then add
weapons) but I've fixed that by creating my own set of Attack
increase options with a higher priority and then a frenzy option that
lies between the stat increase and the weapon options. This works
fine for units that start with frenzy, the problem comes when other
units buy a Skill that allows them frenzy.

Thanks for any asistance!

Cheers,
Teatime



------------------------ Yahoo! Groups Sponsor ---------------------~-->
Buy Ink Cartridges or Refill Kits for Your HP, Epson, Canon or Lexmark
Printer at Myinks.com. Free s/h on orders $50 or more to the US & Canada. http://www.c1tracking.com/l.asp?cid=5511
http://us.click.yahoo.com/l.m7sD/LIdGAA/qnsNAA/IMSolB/TM
---------------------------------------------------------------------~->

To unsubscribe from this group, email

armybuilder-unsubscribe@yahoogroups.com

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
 
> 3. Is there some other solution to my problem? I am a newbie after
> all. It would be ugly to change the Item to an Option instead, since
> it wouldn't match all the others of its type. I'd prefer not to have
> an option that must be activated manually by the user after they've
> bought the item.

I think your best 'option' would be to use both an option and an item to
represent items that give the bearer frenzy rather than trying to fit the
item directly into the order of options (I'm not sure if that's even
possible). Basically, you will create your item as normal, and give it a
type describing it, ie the attribute 'type:frenzy' or some such.

Next, create an option at the appropriate priority level and give it the
'glob:incl' and 'utyp:frenzy' attributes and also have it modify the
attacks stat *2 or whatever you require.

Hope this helps!

Mark

=====
WF6 Army Builder File Manager
Direwolf FAQ Council - Army Builder Liaison
-
Warhammer Club - Vancouver, BC
http://www.WCP-Vancouver.com

__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com

------------------------ Yahoo! Groups Sponsor ---------------------~-->
Buy Ink Cartridges or Refill Kits for Your HP, Epson, Canon or Lexmark
Printer at Myinks.com. Free s/h on orders $50 or more to the US & Canada. http://www.c1tracking.com/l.asp?cid=5511
http://us.click.yahoo.com/l.m7sD/LIdGAA/qnsNAA/IMSolB/TM
---------------------------------------------------------------------~->

To unsubscribe from this group, email

armybuilder-unsubscribe@yahoogroups.com

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
 
At 11:43 AM 9/3/2003 +0000, you wrote:

>General expression of the problem: I am working on a new datafile for
>an existing system. I have both Options and Items that modify stats
>through the base: and stat: options respectively. In order to remain
>faithful to the mechanics of the game system the stat modifications
>activated by the Options really need to be evaluated before the
>modifications made by the Item. Unfortunately I find that the Item
>always takes priority and the resulting stat is miscalculated.
>
>Questions:
>1. Is there a way of having an Item activate an Option? If there were
>I could hide an option with the appropriate priority and have it do
>the stat modification instead.

There is indeed. Give every unit that can take the item an option linked
with 'auto', so it's automatically included, that hides itself and depends
on a type to activate. So the attributes of such an option would look like:

hide
utyp:SomeType
stat:X+14

(You can either use the glob:auto attribute to assign the option to all
units, or manually assign it, or use inheritance (the 'clon' unit local
attribute), or something similar.) Then have the item assign the type
'SomeType'. When the type SomeType is assigned, the option takes effect.

>2. Is there a way of changing the priority of an Item so that it is
>evaluated after an Option? I tried a ipri: and going through a Tweak
>to no effect. I wouldn't want the Item evaluated after ALL Options,
>as there are some where it is appropriate to calculate it first.

I'm afraid not. All items are processed before all options.


--
Colen McAlister (colen@wolflair.com)
Lone Wolf Development www.wolflair.com



------------------------ Yahoo! Groups Sponsor ---------------------~-->
Buy Ink Cartridges or Refill Kits for Your HP, Epson, Canon or Lexmark
Printer at Myinks.com. Free s/h on orders $50 or more to the US & Canada. http://www.c1tracking.com/l.asp?cid=5511
http://us.click.yahoo.com/l.m7sD/LIdGAA/qnsNAA/IMSolB/TM
---------------------------------------------------------------------~->

To unsubscribe from this group, email

armybuilder-unsubscribe@yahoogroups.com

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
 
--- In armybuilder@yahoogroups.com, "Mr. Green" <mach_5@r...> wrote:
>
> > 3. Is there some other solution to my problem? I am a newbie
after
> > all. It would be ugly to change the Item to an Option instead,
since
> > it wouldn't match all the others of its type. I'd prefer not to
have
> > an option that must be activated manually by the user after
they've
> > bought the item.
>
> I think your best 'option' would be to use both an option and an
item to
> represent items that give the bearer frenzy rather than trying to
fit the
> item directly into the order of options (I'm not sure if that's even
> possible). Basically, you will create your item as normal, and
give it a
> type describing it, ie the attribute 'type:frenzy' or some such.
>
> Next, create an option at the appropriate priority level and give
it the
> 'glob:incl' and 'utyp:frenzy' attributes and also have it modify the
> attacks stat *2 or whatever you require.
>
> Hope this helps!
>
> Mark

Yep, that's exactly what I needed. I'd tried this route before using
the olgl: attribute, but of course the option wasn't getting added to
units because they didn't possess the correct type at creation. I'd
also made the assumption that utyp: would only reveal an existing
option without activating it, much like the show: attribute - glad to
see I was wrong on that one.

Thanks for the help!

Cheers,
Teatime


------------------------ Yahoo! Groups Sponsor ---------------------~-->
Buy Ink Cartridges or Refill Kits for Your HP, Epson, Canon or Lexmark
Printer at Myinks.com. Free s/h on orders $50 or more to the US & Canada. http://www.c1tracking.com/l.asp?cid=5511
http://us.click.yahoo.com/l.m7sD/LIdGAA/qnsNAA/IMSolB/TM
---------------------------------------------------------------------~->

To unsubscribe from this group, email

armybuilder-unsubscribe@yahoogroups.com

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
 
--- In armybuilder@yahoogroups.com, Colen McAlister <colen@w...>
wrote:

> There is indeed. Give every unit that can take the item an option
linked
> with 'auto', so it's automatically included, that hides itself and
depends
> on a type to activate. So the attributes of such an option would
look like:
>
> hide
> utyp:SomeType
> stat:X+14
>
> (You can either use the glob:auto attribute to assign the option to
all
> units, or manually assign it, or use inheritance (the 'clon' unit
local
> attribute), or something similar.) Then have the item assign the
type
> 'SomeType'. When the type SomeType is assigned, the option takes
effect.

Mr. Green was a little quicker on the trigger, but thanks for the
reply ;) I did indeed tackle the problem this way with the desired
result. If you're interested in feedback concerning ABCreator: it
wasn't clear to me from the description of the utyp: attribute that a
previously un-linked option could be enabled at run-time, nor that
the desired option would also turn up in the selected state. I am
willing to entertain the idea that perhaps I was being a bit thick,
and should have just tried it anyway :)

> >2. Is there a way of changing the priority of an Item so that it is
> >evaluated after an Option? I tried a ipri: and going through a
Tweak
> >to no effect. I wouldn't want the Item evaluated after ALL Options,
> >as there are some where it is appropriate to calculate it first.
>
> I'm afraid not. All items are processed before all options.

Roger, thanks.

>
> --
> Colen McAlister (colen@w...)
> Lone Wolf Development
www.wolflair.com

Cheers,
Teatime



------------------------ Yahoo! Groups Sponsor ---------------------~-->
Buy Ink Cartridges or Refill Kits for Your HP, Epson, Canon or Lexmark
Printer at Myinks.com. Free s/h on orders $50 or more to the US & Canada. http://www.c1tracking.com/l.asp?cid=5511
http://us.click.yahoo.com/l.m7sD/LIdGAA/qnsNAA/IMSolB/TM
---------------------------------------------------------------------~->

To unsubscribe from this group, email

armybuilder-unsubscribe@yahoogroups.com

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
 
At 08:38 AM 9/4/2003 +0000, you wrote:
>--- In armybuilder@yahoogroups.com, "Mr. Green" <mach_5@r...> wrote:
> >
> > > 3. Is there some other solution to my problem? I am a newbie
>after
> > > all. It would be ugly to change the Item to an Option instead,
>since
> > > it wouldn't match all the others of its type. I'd prefer not to
>have
> > > an option that must be activated manually by the user after
>they've
> > > bought the item.
> >
> > I think your best 'option' would be to use both an option and an
>item to
> > represent items that give the bearer frenzy rather than trying to
>fit the
> > item directly into the order of options (I'm not sure if that's even
> > possible). Basically, you will create your item as normal, and
>give it a
> > type describing it, ie the attribute 'type:frenzy' or some such.
> >
> > Next, create an option at the appropriate priority level and give
>it the
> > 'glob:incl' and 'utyp:frenzy' attributes and also have it modify the
> > attacks stat *2 or whatever you require.
> >
> > Hope this helps!
> >
> > Mark
>
>Yep, that's exactly what I needed. I'd tried this route before using
>the olgl: attribute, but of course the option wasn't getting added to
>units because they didn't possess the correct type at creation. I'd
>also made the assumption that utyp: would only reveal an existing
>option without activating it, much like the show: attribute - glad to
>see I was wrong on that one.
>
>Thanks for the help!
>
>Cheers,
>Teatime
>
>
>
>To unsubscribe from this group, email
>
>armybuilder-unsubscribe@yahoogroups.com
>
>Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/



------------------------ Yahoo! Groups Sponsor ---------------------~-->
Buy Ink Cartridges or Refill Kits for Your HP, Epson, Canon or Lexmark
Printer at Myinks.com. Free s/h on orders $50 or more to the US & Canada. http://www.c1tracking.com/l.asp?cid=5511
http://us.click.yahoo.com/l.m7sD/LIdGAA/qnsNAA/IMSolB/TM
---------------------------------------------------------------------~->

To unsubscribe from this group, email

armybuilder-unsubscribe@yahoogroups.com

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
 
Back
Top