GUI

Card scripting

This will be your "playground" now - to implement all features a card may have.

That means go to

• menu "Cards"

• chose menuitem "Edit Set"

• look for the set the card you want to edit is in and chose the one in the combobox

• a list of all cards of that set will be shown

• double click the card you want to edit

• and go to the second tab

• HERE is your playground :)

Here now a description what you see above and what you can and can't do.

Save

First I would like to draw attention to the various "Save" buttons. It is in general very annoying to program/ edit something and then for the changes to become lost and save everyting again.

Within the "Edit Set" - Window you have THREE save buttons.

• one to the top of the window just below the Set-ComboBox. With that save button you save the "Set" and save changes that you did in the first tab "Card detail" of the window. ALL other changes are NOT saved using this button!

• On Tab 2 "Card scripting" a "Save Card Script". Here you save all changes that you did to your scripting.

• On Tab 3 "AI Hints" is a "Save Hint" button. Here only the generated hints are saved

Each of these "Save-Features" save (programmatically) different entities, which in a (programmatical) way have no real relation to each other. The first one is the "entity"-Set, the second the entity-"Card" and the third one relates to "Hints".

If on the first tab, you double click an entry of the list - the other tabs are updated accordingly. Unsaved changes are LOST. You will not be warned!

Allways remember to save your work!

Clone

While implementing "new" cards, I discovered the "Clone" button is the single most important button in the whole program.

Many cards are actually similar to other cards. With this little clickable darling you can (Tatata!) clone one card to another card. In front of the clone button there is a small textfield. Here you enter the Gatherer ID of a known card to which to do the clone FROM. All card and hint information of that card is cloned to the current card. If the current card already has "information" (like Hints or scripts) the result is joined in the way, that "additional" previous information is kept and keys with new information are copied to the current card. For information which is available in both, the previous is overwritten with the new information.

In card scripts all references (that is gatherer ID and name of the card) is changed to the current cards values.

In JPortal each card uniquely belongs to a set

Meaning a card like "Alabaster Dragon" which is included in several sets - MUST be implemented seperately for each set! There is no such thing as:
Card XY belongs to set A and B and C.
Card and set relations are 1:1.

But cloning here makes life easier again. One button click and the "Alabaster Dragon" joins in a new form the new set!

Edit

Colorfull textarea (3) in above image. Here you can enter the source code of your script. Beware the editor is basic. That means for example NO UNDO mechanism is implemented.

The code you enter is allways associated with the set situation key (combobox above the editor). Prior to editing you must select the situation key you wish to edit. By selecting a situation key the editor "resets". So - if at some stage you want to switch after you edited - copy (clipboard) your code so you still have it *somewhere*.

Remember to "Save" the edited scripts!

Some code conventions

• Please wrap your codings a comments what situation key and what card ID the code is for, you will be glad you did it once you have to debug

• please add meaningfull loging / debuging outputs to your code (and a suitable debuglevel). I use debuglevel 3 for card coding.

Help

On the right side of the window (allways regarding tab 2) a section with another tab and some textareas is displayed. Most of the tabs are used to provide some basic "help".

Here variable-Names, classes, methods etc can be displays, which are deemed to be usefull for card coding.

Following sections (tabs) exist:

• Vars

  • Here a list of variables (and types) which are directly accessible from the scripts are listed.

• Match

  • here available methods from the Match-class are listed, divided into groups (sub-tabs)

    1. Ask - Methods to "ask" another player or the match, these usually lead to some further communication

    2. Move - Methods to move a card or a list of cards from one list to another (sometimes leading to new communication, e.g. if a card is moved to graveyard)

    3. Globals - Methods to place or retrieve information to a global (match related) variable

    4. Lists - methods to retrieve (Card-) lists from match (like graveyard)

    5. Player - Methods to access/set information of a player

    6. Other - Methods whoch could not easily be grouped to one of the above - but are still more or less often used

• Card

  • many of the Card-Methods are listed

    1. Volatile - Methods set/retrieve volatile card information, tap-state, buf state etc

    2. Other - Other methods of card which are often usefull

• CardList

  • Methods provided by CardList, like sorting, generating sublists etc

• Examples

  • assorted examples taken from the Portal-Set which can be viewed and learned from :-)

Test / Debug

This is tricky!

On the last tap of above mentioned section is a tab called "Testing", this is where you can do some interesting stuff with just developed scripts. Here you can test the script (card) you just developed without actually playing a real game.

(well sooner or later you should certainly test your card by playing - but for a quick check this is really fun :-) )

Testing

Actually what you can do here is, run your script using a "dummy" match. This can be done using two ways:

1. simply installing a match and from that call your script

2. actully RUN a match, start your script and let the match execute your script including all communication which may follow

Type b) is invoked by enabling the checkBox "Try as Communication". This type actually starts the match in an own thread and it is continued till it dies - or you press the small "X" button, which destroys the thread.

For "simple" debugging type a) should be work out just fine. If any communication is envolved, you probably must use type b)

Now...

In order to execute a "meaningfull" match some parameters are needed.

• "Match" - lets you define what saved match you will use (obviously a saved match of some kind must exist)

• "Player" - lets you define on what "side" you play

• "Phase" - likewise lets you define in what phase the match should be in (if "my" is checked it is your phase (from the view of your script) if not - its the phase of the opponent

• "Add Manual" - here you can define some situational circumstances. Meaning - when you enter the "defined" match - it is a new match, no creatures are tabbed, no mana is held in background etc. Here you can enter scripts to alter that initial settings. I provided a few examples, like taping some creatures...

• "Test" - starts (RUNS) the script in the defined environment, results are displayed in the below window

Debug
On the left side of the window on the bottom, there is another tab. Here you have quick access to a debug and a log output (and to the current settings of debug-level). Naturally output of the above mentioned testings which go to debug/log will be shown here.

Hints

See: AI Hints