omegablast2002@yahoo.com 6ea7e00803
added countertrack(counterstring) MTGAbility ...
what this does currently is remove a counter of the type counterstring and when the ability is destroyed it puts the counter back for us.
meant for weapons used as follows.
auto=teach(creature) countertrack(0/0,1,hand)
when the creature is equipped with this weapon it will remove a hand counter from the creature, when you remove the weapon, or the weapon is destroyed or whatever...it will put a hand counter back on the creature.
added dualwielding thisdescriptor...
auto=this(dualwielding) 2/2
auto=this(dualwielding) firststrike
enabled "restriction{" on phasebased triggers @next and @each...
i will work more on countertrack to extend it to domains if it currently isnt possible to use it in this case(haven't tested it on domains)....
2011-09-13 14:33:13 +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-13 14:33:13 +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-13 14:33:13 +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-11 14:36:52 +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-09-13 14:33:13 +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
6ea7e00803