Newby Questions

Alkalurops

Hey,

For my first mod I'd like to create an item store that doesn't use gold as a currency, but instead trades "valuable" items for other items.
It is my understanding this is impossible to do using the standard shop interface, so I'm resorting to a dialog tree.

This is the current structure of my dialog file:

// at this point you have asked to describe one of the items
IF ~~ THEN BEGIN DescribeTome

SAY @600 // description of item 1
IF ~~ THEN

REPLY @601 // I want to buy it
DO ~SetGlobal("BuyingItem", "LOCALS", 1)~ // indicate that the player wants to buy item 1
GOTO PaymentOptions

IF ~~ THEN

REPLY @602 // I don't want to buy it
EXIT

END

// Payment options display the ways to pay for the item
IF ~~ THEN BEGIN PaymentOptions

SAY @700 // how do you wish to pay?
IF ~PartyHasItem("BOOK04")~ THEN

REPLY @701 // I want to trade this tome of exercise
DO ~SetGlobal("SellingItem", "LOCALS", 1)~
GOTO Confirmation

// many other options, all going to Confirmation
END

// Confirmation
IF ~~ THEN BEGIN Confirmation

SAY @800 // "Please confirm if you wish to complete this transaction"

IF ~~ THEN

REPLY @801 // Yup
GOTO TransactionBegin

IF ~~ THEN

REPLY @802 // nope
EXIT

END

// Pay for item
IF ~~ THEN BEGIN TransactionBegin

IF ~Global("SellingItem", "LOCALS", 1)~ THEN // if the player wishes to sell tome of exercise

DO ~TakePartyItem("BOOK04")~
DO ~RemoveItem("BOOK04")~
GOTO TransactionEnd

// many other sell options

END

IF ~~ THEN BEGIN TransactionEnd

IF ~Global("BuyingItem", "LOCALS", 1)~ THEN // if the player wishes to buy item 1

DO ~GiveItemCreate("GS#Tome", Player1, 0, 0, 0)~
DO ~SetGlobal("Bought[1]", "LOCALS", 1)~
GOTO MainEntry

// many other item options

END

The idea is that a player selects an item he wishes to buy, then selects an item he wishes to sell, and then confirms the transaction.
After confirming, the appropriate items are exchanged (TransactionBegin will remove sold item from inventory and TransactionEnd will add purchased item to inventory)

So I try to compile this with Weidu, and I get a parsing error at the Transaction states.
I think this is because TransactionBegin and TransactionEnd don't have a SAY statement.
The Weidu readme seems to indicate that SAY is required, while REPLY isn't (automatic transition).

I wanted to centralize the transaction functionality in 2 states, to avoid having to write an insanely large script, where each possible bought & sold item combination must be handled separately. If SAY statements are required, is there an elegant solution to my problem?

Alkalurops

Is my question this stupid?

Wisp

Yes, SAY is mandatory. You can also only have a single DO in each transition. However, a DO can contain multiple actions. Also, the way you use LOCALS is highly unreliable. In dialogues, actions are placed in a queue, which is effectively processed asynchronously. If state N-1 adds an action to the queue, it may not necessarily have been processed by state N, or even state N+1 or later. Unfortunately, there is not a good solution to this problem. Options include exiting and restarting the dialogue and buckling down with the combinatorial explosion.

Alkalurops

@Wisp WeiDU doesn't complain when I compile a script with multiple DO statements in a single transition.
Decompiling my own script still shows all actions intact (although they have been merged into a single DO statement). So as long as it's working as intended, I'll stick to multiple DO statements, since I think it looks cleaner.

Basically, if I understand correctly, to solve asynchronous actions I have to:
DO ~SetGlobal("State", "LOCALS", 1)~ // where "1" identifies which state I want to enter
DO ~StartDialogueNoSet(LastSeenBy())~
EXIT

and then each state should check if ~Global("State", LOCALS", 1)~ matches the state id?

Wisp

@Alkalurops
I suppose you could, but the resulting dialogue would be awful playing through.

A better way would be to e.g., set the buy and sell variables and then exit the dialogue under the pretence of having the shopkeeper fetch the item from the back of the store, or something. When the dialogue is restarted (the shopkeeper returns), the variables will be set and you can run through your transaction states.