Updates on the way.
Moderators: BAgate, drool66, Aswan jaguar, gmzombie, stassy, CCGHQ Admins
Re: Updates on the way.
by Korath » 12 Oct 2016, 23:28
It's the coordinate mapping that's the main problem, yes. (Vehicles will need some work on the hardcoded side, too, but that part's easy.) There's instructions in DuelArt\Duel.dat.
-
Korath - DEVELOPER
- Posts: 3707
- Joined: 02 Jun 2013, 05:57
- Has thanked: 496 times
- Been thanked: 1106 times
Re: Updates on the way.
by drool66 » 13 Oct 2016, 00:47
Thank you; going over it now. I'll work my way through the process over the next few days.
The latest images for Manalink will be here.
The latest Manalink installation directory will be here. Well, not quite, anymore. Check the latest patches.
The latest Manalink installation directory will be here. Well, not quite, anymore. Check the latest patches.
-
drool66 - Programmer
- Posts: 1163
- Joined: 25 Nov 2010, 22:38
- Has thanked: 186 times
- Been thanked: 267 times
Re: Updates on the way.
by drool66 » 13 Oct 2016, 22:32
How are these?
https://www.mediafire.com/?cul457rb2gh514e
Attached screenshots are from Deckbuilder (I just replaced the appropriate files in my CardArt/modern folder)
I'm assuming you will make any necessary changes to any other files (eg. drawcardlib, menus.txt), correct? Also, I imagine showing the P/T box on a noncreature artifact is one of the things for the hardcoded side? I couldn't figure out how to make it happen otherwise.
https://www.mediafire.com/?cul457rb2gh514e
Attached screenshots are from Deckbuilder (I just replaced the appropriate files in my CardArt/modern folder)
I'm assuming you will make any necessary changes to any other files (eg. drawcardlib, menus.txt), correct? Also, I imagine showing the P/T box on a noncreature artifact is one of the things for the hardcoded side? I couldn't figure out how to make it happen otherwise.
- Attachments
-
- Small.jpg (12.68 KiB) Viewed 16998 times
-
The latest images for Manalink will be here.
The latest Manalink installation directory will be here. Well, not quite, anymore. Check the latest patches.
The latest Manalink installation directory will be here. Well, not quite, anymore. Check the latest patches.
-
drool66 - Programmer
- Posts: 1163
- Joined: 25 Nov 2010, 22:38
- Has thanked: 186 times
- Been thanked: 267 times
Re: Updates on the way.
by Korath » 24 Oct 2016, 01:31
Those will work, but there's room for improvement: the bottom edge of the text box on the fullcard is much too tall, and see here for the sort of hack you have to do to get the bottom edge of the smallcard right without having either to display part of the type box, or extend the art all the way to the bottom.
I haven't looked at the frames you pm'd me the other day yet, though.
---
The Manalink KLD release is going to take a long time. Panharmonicon can be done in this engine, but only just barely. Since triggers happen immediately instead of being put on the stack, there's basically two ways to implement it: dispatch the enters-the-battlefield trigger as a whole extra times, while making the extra ones happen only for permanents controlled by Panharmonicon's controller; or rewrite every single card with an enters-the-battlefield trigger so they check for Panharmonicon themselves. The former, which I went with in Shandalar, is (obviously) much less labor-intensive; the latter, which project lead decided on for Manalink, is probably more robust, especially with linked abilities.
I can do a Shandalar-only release in the meantime, but it won't be runnable from the same installation as Manalink anymore and will significantly increase the size of the Shandalar distribution, so I'm pretty reluctant.
The delay's given me time to finish up the rest of the cards with abilities activated while in players' hands; to implement most of the voting cards from Conspiracy and Conspiracy: Take the Crown, which I'd been planning on skipping; and to add a proper framework for modal spells. I haven't done any of the strange variants of those yet:
Numerically, I'm rapidly catching up to Manalink (which has 12963 cards, plus most of the 267 in Kaladesh; Shandalar has 11009 including KLD). There's still a much higher percentage of simple, nearly-vanilla cards in Shandalar, though; and graveyard interaction, damage prevention, planeswalkers, and additional and alternative costs stand out as gaping holes, with 3826 Manalink cards still not in Shandalar (again, not counting anything from Kaladesh). It still feels like tangible progress.
I haven't looked at the frames you pm'd me the other day yet, though.
---
The Manalink KLD release is going to take a long time. Panharmonicon can be done in this engine, but only just barely. Since triggers happen immediately instead of being put on the stack, there's basically two ways to implement it: dispatch the enters-the-battlefield trigger as a whole extra times, while making the extra ones happen only for permanents controlled by Panharmonicon's controller; or rewrite every single card with an enters-the-battlefield trigger so they check for Panharmonicon themselves. The former, which I went with in Shandalar, is (obviously) much less labor-intensive; the latter, which project lead decided on for Manalink, is probably more robust, especially with linked abilities.
I can do a Shandalar-only release in the meantime, but it won't be runnable from the same installation as Manalink anymore and will significantly increase the size of the Shandalar distribution, so I'm pretty reluctant.
The delay's given me time to finish up the rest of the cards with abilities activated while in players' hands; to implement most of the voting cards from Conspiracy and Conspiracy: Take the Crown, which I'd been planning on skipping; and to add a proper framework for modal spells. I haven't done any of the strange variants of those yet:
- spells where the mode is chosen by an opponent (mostly from Alliances, like Fatal Lore - the main problem is that the mode is chosen before targeting or paying the casting cost, and you can just cancel during either of those if you don't like the chosen mode)
- spells like Clan Defiance where multiple modes can be chosen, other than the simple case of "Choose one or both" where I just consider it a third mode
- spells where multiple modes must be chosen (the Cryptic Command cycle and the similar one from Dragons of Tarkir, let alone the Righteous Confluence cycle where modes can be rechosen)
- mechanics like entwine (Tooth and Nail) or escalate (Collective Defiance) which impose additional costs, since I haven't implemented additional costs at all yet. On the other hand, additional and alternative costs have to be handled at the same time as the mode choice, relative to other events sent by this engine, so this was a necessary first step toward those.
- Cards added | Open
Numerically, I'm rapidly catching up to Manalink (which has 12963 cards, plus most of the 267 in Kaladesh; Shandalar has 11009 including KLD). There's still a much higher percentage of simple, nearly-vanilla cards in Shandalar, though; and graveyard interaction, damage prevention, planeswalkers, and additional and alternative costs stand out as gaping holes, with 3826 Manalink cards still not in Shandalar (again, not counting anything from Kaladesh). It still feels like tangible progress.
Last edited by Korath on 25 Oct 2016, 06:47, edited 1 time in total.
-
Korath - DEVELOPER
- Posts: 3707
- Joined: 02 Jun 2013, 05:57
- Has thanked: 496 times
- Been thanked: 1106 times
Re: Updates on the way.
by lujo » 24 Oct 2016, 13:52
A very nice list of cool stuff, with a random: "Oh, cool, Funeral Charm!" from me.
Some thoughts on the potential release:
I'm kinda slowly working my way through the cadrpool and testing it, and there's random bugs I'd really love to have fixed. For instance, Triangle of War is bugged and it fits perfectly into the newly tweaked up Alt-a-kesh with added delirium I've been tinkering with. Thief of Hope soulshift isn't working. Every deck I put together seems to have at least one or two of these, so a bugfix release would actually be quite nice all on it's own. On the other hand, the more I tinker with stuff the more bugs I'm likely to dredge up, so a longer wait isn't necessarily a bad thing.
On the other hand, I'm also kinda waiting on some stuff which should make quite a bunch of deckbuilding easier, like the changelings (they seem to be done for the next release?). Not just them, you know how it is, even the inconspicuous things can quietly enable something or patch up a hole in some concept.
Is there a way to do a bugfix release which adds whatever you've got that doesn't interfere with manalink? Too much hassle?
Some thoughts on the potential release:
I'm kinda slowly working my way through the cadrpool and testing it, and there's random bugs I'd really love to have fixed. For instance, Triangle of War is bugged and it fits perfectly into the newly tweaked up Alt-a-kesh with added delirium I've been tinkering with. Thief of Hope soulshift isn't working. Every deck I put together seems to have at least one or two of these, so a bugfix release would actually be quite nice all on it's own. On the other hand, the more I tinker with stuff the more bugs I'm likely to dredge up, so a longer wait isn't necessarily a bad thing.
On the other hand, I'm also kinda waiting on some stuff which should make quite a bunch of deckbuilding easier, like the changelings (they seem to be done for the next release?). Not just them, you know how it is, even the inconspicuous things can quietly enable something or patch up a hole in some concept.
Is there a way to do a bugfix release which adds whatever you've got that doesn't interfere with manalink? Too much hassle?
---
My Shandalar deck pack folder is avaliable here:Dropbox
Leave feedback on particular decks here: Google doc
Ask for instructions, give feedback and complaints here: Thread
My Shandalar deck pack folder is avaliable here:Dropbox
Leave feedback on particular decks here: Google doc
Ask for instructions, give feedback and complaints here: Thread
Re: Updates on the way.
by lujo » 25 Oct 2016, 12:46
Sure, looking forward to the deathtouch touchups.Korath wrote:I can do a bugfix release for Hall of the Sultan. Reopening the Dragon's Lair branch would be a definite hassle.
Also, don't put it out before you do something about the Rise of Eldrazi "levelers", please. The AI keeps adding counters to them after it's reached max level, which it really shouldn't (it's visibly affecting performance, tying up counterspell mona and so on). I'll add a bug report. They're quite usable all in all, but not if they're not capped at their max level.
Shame about the changelings. Those would have probably made decks all over the place
--
Oh, and I've carpet bombed you with feature requests that have been piling up since forever that I didn't want to bother you with for all sorts of reasons. If what we're looking at is "only" a bugfix release, this might be a good time to look into those, they'd all be rather handy if doable.
---
My Shandalar deck pack folder is avaliable here:Dropbox
Leave feedback on particular decks here: Google doc
Ask for instructions, give feedback and complaints here: Thread
My Shandalar deck pack folder is avaliable here:Dropbox
Leave feedback on particular decks here: Google doc
Ask for instructions, give feedback and complaints here: Thread
Re: Updates on the way.
by drool66 » 26 Oct 2016, 01:22
Sorry about that, I mixed up my .dat files when I made those pictures. The files I PM'ed you follow exactly the process you linked to, and they actually look like this:Those will work, but there's room for improvement: the bottom edge of the text box on the fullcard is much too tall, and see here for the sort of hack you have to do to get the bottom edge of the smallcard right without having either to display part of the type box, or extend the art all the way to the bottom.
I haven't looked at the frames you pm'd me the other day yet, though.
- Screenshot (17).png (42.87 KiB) Viewed 16765 times
The sets I sent you also include hologram files. It's up to you if you want to include them - the holos get a little squashed and cut off on the small cards.
Since the M15 frames aren't in the regular distribution, should the vehicles folder also include a full suite of frames in case a vehicle gets, say, Chaoslace 'd or Song of the Dryads 'ed?
The latest images for Manalink will be here.
The latest Manalink installation directory will be here. Well, not quite, anymore. Check the latest patches.
The latest Manalink installation directory will be here. Well, not quite, anymore. Check the latest patches.
-
drool66 - Programmer
- Posts: 1163
- Joined: 25 Nov 2010, 22:38
- Has thanked: 186 times
- Been thanked: 267 times
Re: Updates on the way.
by TheKillerNacho » 27 Oct 2016, 14:32
Oooooo... I just noticed Korath cleared out the bug reports. Does that mean a new update is imminent? 
Sorry I know you don't like to be rushed Korath I just get excited
Sorry I know you don't like to be rushed Korath I just get excited
With much cheese,
TheKillerNacho
TheKillerNacho
-
TheKillerNacho - Posts: 76
- Joined: 14 Feb 2016, 19:26
- Has thanked: 17 times
- Been thanked: 18 times
Re: Updates on the way.
by lujo » 27 Oct 2016, 15:29
He did clear out some, but I've found a pageful more since then, many of them are honest-to-god proper bugs , with some mishandlings very likely to be due to wrong phases flagged rather than a currently unfixable systemic issue. Since I'm playtesting a number of brews and deck tweaks right now, judging by the rate yesterday, there could be a pageful more in the next couple of hours. EDIT: Lol, I just typed this, alt-tabbed to the playarea and found another proper one (An ability with tap in it's cost is being played for "0" instead)
(An ability with tap in it's cost is being played for "0" instead)---
My Shandalar deck pack folder is avaliable here:Dropbox
Leave feedback on particular decks here: Google doc
Ask for instructions, give feedback and complaints here: Thread
My Shandalar deck pack folder is avaliable here:Dropbox
Leave feedback on particular decks here: Google doc
Ask for instructions, give feedback and complaints here: Thread
Re: Updates on the way.
by KenC59 » 06 Nov 2016, 15:05
Can you please post or link to a full-install zip for the entire package of Shandalar/Manalink? I'm struggling to correctly follow the series of instructions of install this / patch that / install this other thing to get to the anything that actually works for Shandalar. I'm getting "Fatal error / Couldn't malloc 3750 bytes of memory for card_coded".
Thanks
Thanks
Re: Updates on the way.
by TheKillerNacho » 06 Nov 2016, 15:16
I zipped up my Magic folder for someone else not too long ago...KenC59 wrote:Can you please post or link to a full-install zip for the entire package of Shandalar/Manalink? I'm struggling to correctly follow the series of instructions of install this / patch that / install this other thing to get to the anything that actually works for Shandalar. I'm getting "Fatal error / Couldn't malloc 3750 bytes of memory for card_coded".
Thanks
https://drive.google.com/open?id=0B08oi ... mc2Y1BiYk0
Should be as simple as extract and run.
With much cheese,
TheKillerNacho
TheKillerNacho
-
TheKillerNacho - Posts: 76
- Joined: 14 Feb 2016, 19:26
- Has thanked: 17 times
- Been thanked: 18 times
Re: Updates on the way.
by KenC59 » 06 Nov 2016, 15:46
Thanks for the zip. It seems to work in low-rez mode. I'll try to do the high-rez update.
In addition, Norton found that manalinkex.dll contained a security threat - Heur.AdvMl.B, high risk. This is likely a false-positive hit.
In addition, Norton found that manalinkex.dll contained a security threat - Heur.AdvMl.B, high risk. This is likely a false-positive hit.
Re: Updates on the way.
by Korath » 11 Nov 2016, 03:15
Let me search that for you.
---
What I've been working on:
The good:
I've got a mostly-working system in place to make triggers use the stack. This both cleanly separates their announcement from resolution (so, say, cards like Man-o'-War interact properly with cards like Skulking Ghost) and - since they're now distinct objects - lets triggers be selected by things like Stifle and Strionic Resonator. (But see below.) Almost as an afterthought, I can delay triggers getting put onto the stack until a player gets priority (so untap triggers like Wake Thrasher's work right, i.e. not during the untap step), and properly allowing the order of multiple "simultaneous" triggers from the same source (as recently reported here for Manalink) is no more complex than any other card that has multiple unrelated triggers.
Mostly, though, I did it to simplify programming other cards - delayed resolution of triggers is much, much easier to program for than the immediate model used in the fourth-edition era. The reason is that nothing is really "simultaneous" like it's meant to be: cast an Evacuation or Wrath of God and the program has to move the creatures off the battlefield one at a time. This gets complicated very, very quickly when one of them is something like Faceless Butcher, and even more so if the creature returning to the battlefield has an enters-the-battlefield trigger too.
For most triggers, everything just happened immediately. Destruction and damage triggers had to support the 4th-edition regeneration and damage prevention steps, so they already got delayed; unfortunately, if the trigger has to remember anything besides the mere fact that it's triggering for a particular card - most damage triggers need to know what was damaged or how much damage was dealt, for example - all the queued-up triggers have to share storage space somewhere in the original card, since there aren't separate trigger objects to put the data into. Now I can just create a trigger card for each damage event, store just the data for that particular trigger event, and not have to worry about whether or what else the same card is damaging. And when the triggers move onto the stack, it's now correct that they do so one at a time in a well-defined order.
Plus, it's a pretty good excuse to make purple cards.
The bad:
I'd gone to some trouble to make the triggers in cards I've programmed go through a uniform series of macros, rather than directly responding to events from the engine. The idea was that, once I'd written a stack-based trigger system, I'd be able to just change the macros, rather than deal with every individual card.
I wasn't careful enough, though: while the triggers already in the engine always execute in the context of the triggering card, stack-based ones under modern rules have to refer both to the triggering card and the trigger object on the stack. When Cloudchaser Kestrel's trigger resolves, it has to destroy the enchantment targeted at announcement of the trigger and stored on the trigger object, not whatever permanent it's currently targeting with its activated ability; conversely, when Skulking Ghost's trigger resolves, it has to be the Skulking Ghost that gets sacrificed, not the trigger object.
So I've ended up having to individually update all the existing triggers anyway, and there's something more than two thousand to deal with. At least it was going fairly rapidly, at about 150 day, since the existing macros were pretty close to what I need in most respects. On the other hand, the motherboard of the machine I'd been developing on died on Tuesday, so I'm back in recovery mode instead of actively working on the game for a while more yet. At least I didn't lose any hard drives this time.
(I am still reasonably confident that the similar macros I've been using for spells and activated abilities will be sufficient for Deflection/Rings of Brighthearth/etc.)
The ugly:
A couple things.
The stack in this engine isn't really self-contained. Each function that puts a spell or activation onto the stack is also responsible both for allowing a response to it, and for making sure it gets resolved; they all assume that the same object they put on the stack is still on top of it at that point. Activation is reasonably well-behaved, in that most of the work of resolution is done by a general function we've long labelled as "resolve_top_card_of_stack()", which in turn only does activation-specific stuff if the top object's an activation. Normal spell-casting, though, does most of the spell-specific stuff in the calling function, and it completely ignores whatever's on the stack - it calls the function of the spell it put on the stack and passes it the information of the object that's actually currently on top of the stack. So I have to jump through a lot of hoops to make sure that exactly the right number of trigger objects get popped off the stack and in the right place, and that's dreadfully easy to get wrong.
I haven't yet figured out how to stop resolution of everything on the stack once anything starts to resolve. So not only are you still unable to do something like activate Mangara of Corondor, Twiddle it, let the Twiddle resolve, and then activate Mangara again; if something triggers during resolution, then you can't respond to that trigger, even if I call the function that usually allows response. (If something triggers as a result of announcing a spell or activation, though, it goes onto the stack and then you can respond, just like you should be able to.)
Players still don't get priority at all the right times, sometimes get it at times they shouldn't, and generally don't get it in the right order. Out of scope for this feature.
---
On the Manalink side, the Great Rewrite-the-World for Panharmonicon project is midway through dragons_maze.c. That's 21% done, counting by lines of code, and the first commit was on October 14; at that rate, even if nothing else at all gets worked on, there won't be a new version until late February. That's much longer than I'm willing to put off Shandalar for, so I'll do a release in the meantime, but installation will be messier than usual.
---
What I've been working on:
The good:
I've got a mostly-working system in place to make triggers use the stack. This both cleanly separates their announcement from resolution (so, say, cards like Man-o'-War interact properly with cards like Skulking Ghost) and - since they're now distinct objects - lets triggers be selected by things like Stifle and Strionic Resonator. (But see below.) Almost as an afterthought, I can delay triggers getting put onto the stack until a player gets priority (so untap triggers like Wake Thrasher's work right, i.e. not during the untap step), and properly allowing the order of multiple "simultaneous" triggers from the same source (as recently reported here for Manalink) is no more complex than any other card that has multiple unrelated triggers.
Mostly, though, I did it to simplify programming other cards - delayed resolution of triggers is much, much easier to program for than the immediate model used in the fourth-edition era. The reason is that nothing is really "simultaneous" like it's meant to be: cast an Evacuation or Wrath of God and the program has to move the creatures off the battlefield one at a time. This gets complicated very, very quickly when one of them is something like Faceless Butcher, and even more so if the creature returning to the battlefield has an enters-the-battlefield trigger too.
For most triggers, everything just happened immediately. Destruction and damage triggers had to support the 4th-edition regeneration and damage prevention steps, so they already got delayed; unfortunately, if the trigger has to remember anything besides the mere fact that it's triggering for a particular card - most damage triggers need to know what was damaged or how much damage was dealt, for example - all the queued-up triggers have to share storage space somewhere in the original card, since there aren't separate trigger objects to put the data into. Now I can just create a trigger card for each damage event, store just the data for that particular trigger event, and not have to worry about whether or what else the same card is damaging. And when the triggers move onto the stack, it's now correct that they do so one at a time in a well-defined order.
Plus, it's a pretty good excuse to make purple cards.
- Most of the cards since my last post have untap or target triggers, to test aspects of this | Open
The bad:
I'd gone to some trouble to make the triggers in cards I've programmed go through a uniform series of macros, rather than directly responding to events from the engine. The idea was that, once I'd written a stack-based trigger system, I'd be able to just change the macros, rather than deal with every individual card.
I wasn't careful enough, though: while the triggers already in the engine always execute in the context of the triggering card, stack-based ones under modern rules have to refer both to the triggering card and the trigger object on the stack. When Cloudchaser Kestrel's trigger resolves, it has to destroy the enchantment targeted at announcement of the trigger and stored on the trigger object, not whatever permanent it's currently targeting with its activated ability; conversely, when Skulking Ghost's trigger resolves, it has to be the Skulking Ghost that gets sacrificed, not the trigger object.
So I've ended up having to individually update all the existing triggers anyway, and there's something more than two thousand to deal with. At least it was going fairly rapidly, at about 150 day, since the existing macros were pretty close to what I need in most respects. On the other hand, the motherboard of the machine I'd been developing on died on Tuesday, so I'm back in recovery mode instead of actively working on the game for a while more yet. At least I didn't lose any hard drives this time.
(I am still reasonably confident that the similar macros I've been using for spells and activated abilities will be sufficient for Deflection/Rings of Brighthearth/etc.)
The ugly:
A couple things.
The stack in this engine isn't really self-contained. Each function that puts a spell or activation onto the stack is also responsible both for allowing a response to it, and for making sure it gets resolved; they all assume that the same object they put on the stack is still on top of it at that point. Activation is reasonably well-behaved, in that most of the work of resolution is done by a general function we've long labelled as "resolve_top_card_of_stack()", which in turn only does activation-specific stuff if the top object's an activation. Normal spell-casting, though, does most of the spell-specific stuff in the calling function, and it completely ignores whatever's on the stack - it calls the function of the spell it put on the stack and passes it the information of the object that's actually currently on top of the stack. So I have to jump through a lot of hoops to make sure that exactly the right number of trigger objects get popped off the stack and in the right place, and that's dreadfully easy to get wrong.
I haven't yet figured out how to stop resolution of everything on the stack once anything starts to resolve. So not only are you still unable to do something like activate Mangara of Corondor, Twiddle it, let the Twiddle resolve, and then activate Mangara again; if something triggers during resolution, then you can't respond to that trigger, even if I call the function that usually allows response. (If something triggers as a result of announcing a spell or activation, though, it goes onto the stack and then you can respond, just like you should be able to.)
Players still don't get priority at all the right times, sometimes get it at times they shouldn't, and generally don't get it in the right order. Out of scope for this feature.
---
On the Manalink side, the Great Rewrite-the-World for Panharmonicon project is midway through dragons_maze.c. That's 21% done, counting by lines of code, and the first commit was on October 14; at that rate, even if nothing else at all gets worked on, there won't be a new version until late February. That's much longer than I'm willing to put off Shandalar for, so I'll do a release in the meantime, but installation will be messier than usual.
-
Korath - DEVELOPER
- Posts: 3707
- Joined: 02 Jun 2013, 05:57
- Has thanked: 496 times
- Been thanked: 1106 times
Re: Updates on the way.
by TheKillerNacho » 11 Nov 2016, 15:31
Thanks for the update! 
Your dedication to this project never ceases to amaze me, and has brought me countless hours of amusement. Will the next release be a bugfix only release, then?
Your dedication to this project never ceases to amaze me, and has brought me countless hours of amusement. Will the next release be a bugfix only release, then?
With much cheese,
TheKillerNacho
TheKillerNacho
-
TheKillerNacho - Posts: 76
- Joined: 14 Feb 2016, 19:26
- Has thanked: 17 times
- Been thanked: 18 times
Who is online
Users browsing this forum: No registered users and 26 guests