omegablast2002@yahoo.com d078872dfc
this is the first draft of a simple ai combo system, ...
format is as follows
HINT#combo hold(blah|myhand)^until(blah|mygraveyard)^until(blah|opponentshand)^restriction{type(creature|mybattlefield)~morethan~2}^cast(blah) targeting(blah|mygraveyard)^totalmananneeded({g}{g}{r}{u}{2})
the ai can be told to hold more then one card, until as many condiations as you want are met, until( is a TC and can basically be used in a fasion of saying "hold arbor elf until you have a lord of atlantas in play and a gaint growth in you hand"
once the condiations are met you can later tell it to cast(gaint growth) targeting(arbor elf[fresh]|mybattlefield)...
I also included the whole of the games restrictions system...
so you can get really really creative with this so far.
the next thing I will do is ability targeting and card favoring.
2012-08-19 21:53:57 +00:00
2011-10-26 22:14:12 +00:00
2011-11-29 21:50:16 +00:00
2011-12-25 01:01:20 +00:00
2012-01-05 12:05:17 +00:00
2012-08-19 21:53:57 +00:00
2011-11-06 17:31:44 +00:00
2011-12-11 13:48:24 +00:00
2012-08-19 21:53:57 +00:00
2012-02-01 04:17:30 +00:00
2011-01-21 18:01:14 +00:00
2012-08-19 21:53:57 +00:00
2011-12-08 20:50:36 +00:00
2011-09-01 20:03:26 +00:00
2011-10-01 13:30:30 +00:00
2011-01-21 18:01:14 +00:00
2012-02-13 15:28:55 +00:00
2011-12-25 01:01:20 +00:00
2011-12-18 09:40:35 +00:00
2011-10-01 13:30:30 +00:00
2012-06-01 23:36:18 +00:00
2012-01-31 14:07:40 +00:00
2011-10-02 09:05:39 +00:00
2011-10-02 14:11:30 +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-11-23 19:11:48 +00:00
2012-02-20 07:32:14 +00:00
2012-01-29 17:01:48 +00:00
2011-05-06 06:40:00 +00:00
2011-02-10 17:19:11 +00:00
2011-11-23 19:11:48 +00:00
2011-01-21 18:01:14 +00:00
2012-04-01 17:39:41 +00:00
2012-02-05 11:16:43 +00:00
2012-03-20 23:10:05 +00:00
2011-12-15 11:11:08 +00:00
2012-01-27 23:47:02 +00:00
2012-01-27 23:47:02 +00:00
2012-03-21 14:41:38 +00:00
2012-08-19 21:53:57 +00:00
2011-12-11 13:48:24 +00:00
2011-01-21 18:01:14 +00:00
2012-02-01 00:38:02 +00:00
2011-01-21 18:01:14 +00:00
2011-01-21 18:01:14 +00:00
2011-10-01 13:30:30 +00:00
2011-10-01 13:30:30 +00:00
2011-10-01 13:30:30 +00:00
2011-12-31 08:21:00 +00:00
2011-10-01 13:30:30 +00:00
2011-10-01 13:30:30 +00:00
2011-10-01 13:30:30 +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-10-01 13:30:30 +00:00
2011-10-01 13:30:30 +00:00
2011-07-04 19:09:19 +00:00
2011-11-13 22:36:34 +00:00
2012-01-30 18:02:26 +00:00
2012-08-19 21:53:57 +00:00
2011-04-28 07:49:51 +00:00
2011-08-14 14:42:37 +00:00
2012-02-13 15:28:55 +00:00
2012-03-26 13:51:44 +00:00
2011-08-07 04:01:56 +00:00
2012-07-16 14:59:46 +00:00
2012-03-20 23:10:05 +00:00
2012-07-16 14:59:46 +00:00
2011-11-23 19:11:48 +00:00
2012-03-15 06:18:08 +00:00
2011-01-21 18:01:14 +00:00
2012-07-16 14:59:46 +00:00
2011-10-01 14:24:07 +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
2012-03-13 16:48:48 +00:00
2012-03-20 23:10:05 +00:00
2011-01-21 18:01:14 +00:00
2011-06-02 05:33:45 +00:00
2011-10-01 13:30:30 +00:00
2011-08-14 18:09:02 +00:00
2011-12-31 08:21:00 +00:00
2012-01-30 09:23:56 +00:00
2011-01-21 18:01:14 +00:00
2012-03-20 12:21:03 +00:00
2011-11-29 21:50:16 +00:00
2012-03-21 14:44:23 +00:00
2012-03-20 23:07:21 +00:00
2012-01-25 18:35:24 +00:00
2011-12-15 11:11:08 +00:00
2012-01-26 13:53:03 +00:00
2011-09-17 21:27:36 +00:00
2011-01-21 18:01:14 +00:00
2012-03-13 16:32:26 +00:00
2011-11-19 14:07:57 +00:00
2012-07-16 14:59:46 +00:00
2012-03-13 15:35:43 +00:00
2011-10-01 13:30:30 +00:00
2011-11-29 21:50:16 +00:00
2011-01-28 06:00:51 +00:00
2012-01-31 19:17:51 +00:00
2011-11-29 21:50:16 +00:00
2011-01-21 18:01:14 +00:00
2010-02-27 18:49:03 +00:00
2011-11-06 19:58:23 +00:00
2011-12-29 13:15:44 +00:00
2012-05-07 05:09:12 +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
2012-03-18 15:57:35 +00:00
2011-01-30 11:14:36 +00:00
2011-01-21 18:01:14 +00:00
2011-10-09 05:51:45 +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
2012-02-11 18:20:08 +00:00
2011-10-02 09:05:39 +00:00
d078872dfc