omegablast2002@yahoo.com 1e0268eb07
added parents and children TargetChooser ...
ok this target chooser is set apart from the others becuase it focuses on relationship between cards instead of other forms of checking, also i made sure to add a method for deeper Targeting.
it is the same as any other target chooser when it comes to writeing the syntax and can be used in almost every way a normal one can.
here is what i mean by deeper targeting
this targetchooser allows you to denote a nested targetchooser.
target(children[targerchooser])
all(parents[targetchooser])
it is plural becuase i do allow maxtargeting to be denoted here. lets say you want to have a domain that lets you do the following
"2 of my target inhabitants get +1/+1 until end of turn"
you can do this...
auto={0}:target(<2>children) +1/+1 ueot
how about even more complex?
auto={0}:target(<2>children[elf[power=1]]) +1/+1
2 of my children that are elves with power equal to 1.
the same goes for parents, you can also lord( with this targetchooser.
if you want to say
"the inhabitants of this domain gain flying"
auto=lord(children) flying
here are some example coding that you can play around with.
[card]
name=Forest
text=G
auto=lord(children[elf]) +3/+3
auto={0}:target(<2>children) +12/+12
type=Basic Land
subtype=Forest
[/card]
[card]
name=Tidal Kraken
abilities=unblockable
target=land|mybattlefield
auto=connect
auto={0}:target(parents) destroy
text=Tidal Kraken is unblockable.
mana={0}
type=Creature
subtype=Kraken
power=6
toughness=6
[/card]
[card]
name=Arbor Elf
target=<upto:3>land|mybattlefield
auto=connect
auto=foreach(parents[forest]) 1/1
mana={0}
type=creature
subtype=elf
power=1
toughness=1
[/card]
*above, arbor elf can target upto 3 domains...for each one you choose to connect him to that is a forest, arbor elf would gain 1/1..
so as you can see it is pretty indepth.
note: all test pass.
2011-09-10 23:23:40 +00:00
2011-09-01 20:03:26 +00:00
2011-09-01 20:03:26 +00:00
2011-09-01 20:03:26 +00:00
2011-08-14 18:09:02 +00:00
2011-03-13 21:19:02 +00:00
2011-09-01 20:03:26 +00:00
2011-01-21 18:01:14 +00:00
2011-09-10 21:28:20 +00:00
2011-04-22 13:12:36 +00:00
2011-09-01 20:03:26 +00:00
2011-07-04 19:09:19 +00:00
2011-01-21 18:01:14 +00:00
2011-07-30 14:29:12 +00:00
2011-08-21 09:04:59 +00:00
2011-07-14 21:21:24 +00:00
2011-01-21 18:01:14 +00:00
2011-04-22 13:12:36 +00:00
2011-07-29 17:43:45 +00:00
2011-05-23 11:46:04 +00:00
2011-05-23 11:46:04 +00:00
2011-01-21 18:01:14 +00:00
2011-01-21 18:01:14 +00:00
2011-01-28 06:00:51 +00:00
2011-02-10 17:19:11 +00:00
Resuming on my threading support work with the card caching mechanism. This change unfortunately touches quite a few files, but I needed to get it out of the way before things got out of hand: one significant hurdle is the assumed lifetime of a JQuad pointer. In a single threaded model, the life time of the pointer is clear: you fetch it into the cache, the cache makes room, you use the pointer immediately. In a multithreaded context however, it's unsafe, as the drawing thread can request a few JQuads, and the cache operating on a separate thread can potentially bounce a JQuad out of the cache before the draw routine is done using it, which ends up in an access violation when you attempt to draw using an invalidated quad pointer. To prevent this, the bulk of this change swaps out the use of naked JQuad* pointers in the code with a JQuadPtr, which is basically a typedef to a boost shared_ptr<JQuad>.
2011-02-01 10:37:21 +00:00
2011-06-03 20:01:50 +00:00
2011-05-06 06:40:00 +00:00
2011-02-10 17:19:11 +00:00
2011-01-21 18:01:14 +00:00
2011-01-21 18:01:14 +00:00
2011-04-24 10:33:38 +00:00
2011-09-04 02:45:18 +00:00
2011-09-01 20:03:26 +00:00
2011-08-21 09:04:59 +00:00
2011-09-04 02:45:18 +00:00
2011-09-06 21:08:25 +00:00
2011-09-05 22:04:10 +00:00
2011-09-04 02:45:18 +00:00
2011-08-21 09:04:59 +00:00
2011-01-21 18:01:14 +00:00
2011-08-14 18:13:28 +00:00
2011-01-21 18:01:14 +00:00
2011-01-21 18:01:14 +00:00
2011-07-04 19:09:19 +00:00
2011-01-21 18:01:14 +00:00
2011-01-21 18:01:14 +00:00
2011-01-21 18:01:14 +00:00
Resuming on my threading support work with the card caching mechanism. This change unfortunately touches quite a few files, but I needed to get it out of the way before things got out of hand: one significant hurdle is the assumed lifetime of a JQuad pointer. In a single threaded model, the life time of the pointer is clear: you fetch it into the cache, the cache makes room, you use the pointer immediately. In a multithreaded context however, it's unsafe, as the drawing thread can request a few JQuads, and the cache operating on a separate thread can potentially bounce a JQuad out of the cache before the draw routine is done using it, which ends up in an access violation when you attempt to draw using an invalidated quad pointer. To prevent this, the bulk of this change swaps out the use of naked JQuad* pointers in the code with a JQuadPtr, which is basically a typedef to a boost shared_ptr<JQuad>.
2011-02-01 10:37:21 +00:00
Resuming on my threading support work with the card caching mechanism. This change unfortunately touches quite a few files, but I needed to get it out of the way before things got out of hand: one significant hurdle is the assumed lifetime of a JQuad pointer. In a single threaded model, the life time of the pointer is clear: you fetch it into the cache, the cache makes room, you use the pointer immediately. In a multithreaded context however, it's unsafe, as the drawing thread can request a few JQuads, and the cache operating on a separate thread can potentially bounce a JQuad out of the cache before the draw routine is done using it, which ends up in an access violation when you attempt to draw using an invalidated quad pointer. To prevent this, the bulk of this change swaps out the use of naked JQuad* pointers in the code with a JQuadPtr, which is basically a typedef to a boost shared_ptr<JQuad>.
2011-02-01 10:37:21 +00:00
2011-09-01 20:03:26 +00:00
Resuming on my threading support work with the card caching mechanism. This change unfortunately touches quite a few files, but I needed to get it out of the way before things got out of hand: one significant hurdle is the assumed lifetime of a JQuad pointer. In a single threaded model, the life time of the pointer is clear: you fetch it into the cache, the cache makes room, you use the pointer immediately. In a multithreaded context however, it's unsafe, as the drawing thread can request a few JQuads, and the cache operating on a separate thread can potentially bounce a JQuad out of the cache before the draw routine is done using it, which ends up in an access violation when you attempt to draw using an invalidated quad pointer. To prevent this, the bulk of this change swaps out the use of naked JQuad* pointers in the code with a JQuadPtr, which is basically a typedef to a boost shared_ptr<JQuad>.
2011-02-01 10:37:21 +00:00
2011-08-04 05:57:10 +00:00
2011-01-24 17:58:14 +00:00
2011-07-04 19:09:19 +00:00
2011-07-03 08:47:51 +00:00
2011-09-01 20:03:26 +00:00
2011-04-28 07:49:51 +00:00
2011-08-14 14:42:37 +00:00
2011-05-07 11:58:37 +00:00
2011-09-09 10:34:05 +00:00
2011-08-07 04:01:56 +00:00
2011-09-10 19:37:44 +00:00
2011-08-21 09:04:59 +00:00
2011-09-01 20:03:26 +00:00
2011-08-04 05:57:10 +00:00
2011-06-02 07:01:42 +00:00
2011-01-21 18:01:14 +00:00
2011-09-10 21:28:20 +00:00
2011-01-21 18:01:14 +00:00
2011-03-13 21:19:02 +00:00
2011-04-23 08:43:34 +00:00
2011-04-20 07:50:00 +00:00
2011-01-21 18:01:14 +00:00
2011-01-21 18:01:14 +00:00
2011-05-10 17:08:08 +00:00
2011-01-21 18:01:14 +00:00
2011-06-02 05:33:45 +00:00
2011-01-21 18:01:14 +00:00
2011-08-14 18:09:02 +00:00
2011-04-29 17:30:57 +00:00
2011-04-20 07:50:00 +00:00
2011-01-21 18:01:14 +00:00
2011-09-01 20:03:26 +00:00
2011-05-10 17:08:08 +00:00
2011-09-01 20:03:26 +00:00
2011-06-04 16:22:45 +00:00
2011-09-04 23:13:22 +00:00
2011-01-28 06:00:51 +00:00
2011-01-21 18:01:14 +00:00
2011-01-21 18:01:14 +00:00
2011-05-16 23:19:08 +00:00
2011-01-21 18:01:14 +00:00
2011-09-10 23:23:40 +00:00
2011-05-26 12:27:44 +00:00
2011-07-03 08:47:51 +00:00
2011-01-21 18:01:14 +00:00
2011-01-28 06:00:51 +00:00
2011-07-27 14:31:27 +00:00
2011-01-28 06:00:51 +00:00
2011-01-21 18:01:14 +00:00
2010-02-27 18:49:03 +00:00
2011-01-21 18:01:14 +00:00
2011-08-22 12:33:39 +00:00
2011-04-20 06:27:44 +00:00
Resuming on my threading support work with the card caching mechanism. This change unfortunately touches quite a few files, but I needed to get it out of the way before things got out of hand: one significant hurdle is the assumed lifetime of a JQuad pointer. In a single threaded model, the life time of the pointer is clear: you fetch it into the cache, the cache makes room, you use the pointer immediately. In a multithreaded context however, it's unsafe, as the drawing thread can request a few JQuads, and the cache operating on a separate thread can potentially bounce a JQuad out of the cache before the draw routine is done using it, which ends up in an access violation when you attempt to draw using an invalidated quad pointer. To prevent this, the bulk of this change swaps out the use of naked JQuad* pointers in the code with a JQuadPtr, which is basically a typedef to a boost shared_ptr<JQuad>.
2011-02-01 10:37:21 +00:00
2011-09-01 20:03:26 +00:00
2011-01-30 11:14:36 +00:00
2011-01-21 18:01:14 +00:00
2011-09-06 21:08:25 +00:00
Resuming on my threading support work with the card caching mechanism. This change unfortunately touches quite a few files, but I needed to get it out of the way before things got out of hand: one significant hurdle is the assumed lifetime of a JQuad pointer. In a single threaded model, the life time of the pointer is clear: you fetch it into the cache, the cache makes room, you use the pointer immediately. In a multithreaded context however, it's unsafe, as the drawing thread can request a few JQuads, and the cache operating on a separate thread can potentially bounce a JQuad out of the cache before the draw routine is done using it, which ends up in an access violation when you attempt to draw using an invalidated quad pointer. To prevent this, the bulk of this change swaps out the use of naked JQuad* pointers in the code with a JQuadPtr, which is basically a typedef to a boost shared_ptr<JQuad>.
2011-02-01 10:37:21 +00:00
2011-08-21 09:04:59 +00:00
2011-08-21 09:04:59 +00:00
omegablast2002@yahoo.com
1e0268eb07