omegablast2002@yahoo.com 7d98628355
added a "while " tag for aslongas effects which are not supposed to be treated as oneshot abilities. adding it as a tag allows for maximum flexibility in the code. ...
while i was at it reworked the aslongas class completely, i promised myself if another bug popped up with aslongas i would rewrite it. 20 hours later, we have an aslongas which does not care about when cards come or go.
aslongas should never have used the added/removed to determine the validity of its effect. i allow update to sort it out now in the update function of aslongas...also added a new function to it called sorterfunction tho it looks as it could be reduced in code i would appreciate that it remains as it is, simply because of the nightmare i went through fixing the previous 7 bugs or more reported for aslongas. the logic was far to jumbled up. this i hope is atleast cleaner and easier to understand for the future devs that might work on it.
note: all test passed, all manual testing also passed.
new while tag is used as follows.
[card]
name=Emperor Crocodile
auto=aslongas(other creature|myBattlefield) all(this) sacrifice while <1
text=When you control no other creatures, sacrifice Emperor Crocodile.
mana={3}{G}
type=Creature
subtype=Crocodile
power=5
toughness=5
[/card]
this will denote that the ability is NOT a oneshot ability and should remain effective for the entire time the card is in the field.
Issue: 613
2011-03-27 14:37:12 +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
2011-03-13 21:19:02 +00:00
2011-03-13 21:19:02 +00:00
2011-01-21 18:01:14 +00:00
2011-03-27 14:37:12 +00:00
2011-02-02 18:22:08 +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
2011-02-25 18:40:23 +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
2011-02-08 15:12: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-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-01-21 18:01:14 +00:00
2011-02-14 09:35:43 +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-01-28 06:00:51 +00:00
2011-03-13 21:19:02 +00:00
2011-02-12 15:06:28 +00:00
2011-01-31 10:04:18 +00:00
2011-01-30 13:06:21 +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
2011-03-13 21:19:02 +00:00
2011-02-06 11:35:40 +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
2011-01-21 18:01:14 +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
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-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
2011-01-21 18:01:14 +00:00
2011-01-24 17:58:14 +00:00
2011-01-21 18:01:14 +00:00
2011-02-25 18:40:23 +00:00
2011-02-09 20:42:19 +00:00
2011-01-21 18:01:14 +00:00
2011-02-25 18:40:23 +00:00
2011-01-21 18:01:14 +00:00
2011-03-02 13:41:24 +00:00
2011-02-14 09:35:43 +00:00
2011-03-02 13:41:24 +00:00
2011-01-21 18:01:14 +00:00
2011-03-02 13:41:24 +00:00
2011-01-21 18:01:14 +00:00
2011-02-25 22:41:43 +00:00
2011-01-21 18:01:14 +00:00
2011-03-13 21:19:02 +00:00
2011-02-01 19:11:43 +00:00
2011-01-21 18:01:14 +00:00
2011-01-21 18:01:14 +00:00
2011-03-13 21:19:02 +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
2011-02-15 14:17:34 +00:00
2011-01-21 18:01:14 +00:00
2011-01-08 12:24:39 +00:00
2011-01-21 18:01:14 +00:00
2011-01-28 06:00:51 +00:00
2011-03-02 21:33:42 +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-01-21 18:01:14 +00:00
2011-01-21 18:01:14 +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-01-21 18:01:14 +00:00
2011-01-21 18:01:14 +00:00
2011-02-15 14:17:34 +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
2011-01-28 06:00:51 +00:00
2011-02-02 18:22:08 +00:00
2011-03-01 09:30:23 +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-02-05 06:42:53 +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-01-23 06:59:00 +00:00
2011-01-30 11:14:36 +00:00
2011-01-21 18:01:14 +00:00
2011-01-31 10:24:06 +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
omegablast2002@yahoo.com
7d98628355