Improved targeting interface

[ACG8]

For the newly planned functionality enabled by the spell dictionary, I want to create a nicer targeting function. The idea is that upon taking certain actions that require a target, the game will highlight all valid targets and then the player selects one by left-clicking on it. This gives much greater flexibility in allowing abilities to target things, and also is nicer interface-wise. I have already figured out how to do this from a coding standpoint; I have opened this issue to track changes that specifically address this interface.

One question to be discussed: currently, highlighting is used to indicate who owns face-down enchantments. Ideally, I would like to use highlighting strictly for the purposes of indicating which cards are legal targets (Long run, I also want the ability to highlight and click on zones, but I do not see any way to do this in the current version of OCTGN). The question is, do we absolutely need to highlight face-down cards to indicate ownership? After all players can already simply mouse-over a face-down card to see if it is theirs.

[sIKE23]

The highlighting of cards was done originally only on Facedown enchantments and prepared spells. I added the highlights to face up cards without action markers after spectating was introduced. I am not sure if we should turn this off. Couple of thoughts that rolled off the top of my head:

Maybe we could introduce a non-player color as the legal target color and the code handles the color manipulation?

Could the code not place targeting reticles on the cards that were legal targets?

I will think on this a bit more......

[ACG8]

Those are excellent suggestions. Another option is to just not have any highlighting/indication at all, and just give a message if the player selects an illegal target (after some thought, this might be a good way to avoid giving your opponent information on what you are considering).

Targeting reticles could work, though they will not work for cards that are covered by other cards, such as enchantments.

[sIKE23]

We can try it and see how it works.....I think the no highlight idea should work well, we would only prompt on an illegal choice....

I like transparent rules enforcement...

[sIKE23]

@ACG8 Something that we can make use of with the new 3.1.0.2 API is card.filter https://github.com/OCTGN/OCTGN/wiki/OCTGN-Python-3.1.0.2-API-Reference#cardfilter

It basically paints the color you choose transparently over the whole card.

[sIKE23]

@ACG8 This question is an ignorance (python based) question. In the modified_set.xml file I see something like:

    <property name="Range" value="0-1" />
    <property name="cTargets" value="m0,M1))TCreature||TConjuration" />
    <property name="Target" value="Creature or Conjuration" />

I see Range above and Target below, the cTargets property seems to be a merged duplicate of these two lines. Is this so you only have to perform one operation to get the data for target and range and is therefore much faster? If not what is the purpose?

This is just a learning question for me honestly. And one other!

Have you thought about a function that is run during OnDeckLoaded that reads each card into a dictionary that parses all of the card set data into a format like this in memory? Of course this just might be a crazy question from some one who has no clue of what he is asking here!

[ACG8]

That card.filter functionality is fantastic! That will be a much better way of highlighting valid targets.

Regarding cTargets: Yes, the idea is to simplify the acquisition of target/range data. But it isn't just about speed, it is also about moving the bulk of the targeting code from the python scripts to the xml files.

My idea here is that we give our python scripts xml data that can be translated in an easy way into targeting filters. At the moment, our python targeting code has a huge mess of exceptions for every possible value of the "Target" field. I want to simplify it so that it just translates the xml code into targeting instructions and then applies those. That way, when we add a new card, we don't have to go and change every targeting function. This will make expanding our card database much easier.

Regarding parsing card data during onDeckLoaded, that is sort of what I intended to do with my card data formatter, at least with assigning methods to cards, but it turns out OCTGN doesn't support that yet. I would prefer to write properties directly into card xml data whenever possible, as opposed to parsing them in-game, because it will take up less time. There is already sometimes a bit of a delay on the load time for games, so it would be good to reduce this burden. Currently, I am parsing the nickname and various pronoun properties in-game; I think I will remove this and simply write xml properties for these instead (using the mass editor, of course).

I should probably ask: are you all right with me adding all these xml properties? Does the format I have chosen seem like a good one? I am open to suggestions. Also, please feel free to let me know if there are functions you would like to see added to the xml mass editor.

[sIKE23]

I know there is a bit of delay with onDeckLoaded and it will only get worse as we add more mages, I have been thinking on how we can improve that part of the script, but honestly nothing has occurred to me. Matter of fact, that is one of the challenges that I was able to resolve with the new start game functionality, with the GameMode global variable. So we can branch deck validation for Arena and Academy, now I just have to figure out how to handle loading the wrong Spellbook (Arena into Academy) most importantly how to tell the difference and make it easy for players to build books for either going forward.

//FC

On Tue, Sep 15, 2015 at 10:05 AM, Ananda notifications@github.com wrote:

That card.filter functionality is fantastic! That will be a much better way of highlighting valid targets.

Regarding cTargets: Yes, the idea is to simplify the acquisition of target/range data. But it isn't just about speed, it is also about moving the bulk of the targeting code from the python scripts to the xml files.

My idea here is that we give our python scripts xml data that can be translated in an easy way into targeting filters. At the moment, our python targeting code has a huge mess of exceptions for every possible value of the "Target" field. I want to simplify it so that it just translates the xml code into targeting instructions and then applies those. That way, when we add a new card, we don't have to go and change every targeting function. This will make expanding our card database much easier.

Regarding parsing card data during onDeckLoaded, that is sort of what I intended to do with my card data formatter, at least with assigning methods to cards, but it turns out OCTGN doesn't support that yet. I would prefer to write properties directly into card xml data whenever possible, as opposed to parsing them in-game, because it will take up less time. There is already sometimes a bit of a delay on the load time for games, so it would be good to reduce this burden. Currently, I am parsing the nickname and various pronoun properties in-game; I think I will remove this and simply write xml properties for these instead (using the mass editor, of course).

I should probably ask: are you all right with me adding all these xml properties? Does the format I have chosen seem like a good one? I am open to suggestions. Also, please feel free to let me know if there are functions you would like to see added to the xml mass editor.

— Reply to this email directly or view it on GitHub https://github.com/sIKE23/Mage-Wars/issues/213#issuecomment-140422644.

[ACG8]

Regarding deck vailidation for Arena vs Academy, what if you just check the identity of the mage? Arena mages can't be used in Academy and Academy mages can't be used in Arena, so it would work as a pretty good test of whether the mage is appropriate for the chosen format.

[sIKE23]

That would all be in the set data of course. We have to figure out how to tell an Academy Wizard from an Arena Wizard without breaking all the existing Arena spellbooks.

//FC

On Tue, Sep 15, 2015 at 10:42 AM, Ananda notifications@github.com wrote:

Regarding deck vailidation for Arena vs Academy, what if you just check the identity of the mage? Arena mages can't be used in Academy and Academy mages can't be used in Arena, so it would work as a pretty good test of whether the mage is appropriate for the chosen format.

— Reply to this email directly or view it on GitHub https://github.com/sIKE23/Mage-Wars/issues/213#issuecomment-140436742.