Messages

Just get rid of the module code. The plugin has already defined that header script. That's the reason for the error.

[Download v1.1.1!]

Ah, there's nothing like a cup of bugs in the evening.

I've uploaded a new version that fixes a couple of bugs I noticed a few hours ago. Download v1.1.1!

Changes:
- Fixed crash with empty fields in the variable window.
- Fixed dialog option drag & drop: when dropping below the current place on the same level, the option was moved one place too far.

Thanks for the offer, we'll keep it in mind!

Well, we haven't given up on it but right now we're too distracted by other shiny things. I've been trying to start working on it again for a couple of weeks now, and luckily this discussion has given me some more inspiration. It's becoming quite clear that what killed the production last autumn is the same thing that's preventing me from starting it up again: dialog. Also, every time I mention writing dialog to MadReizka, he goes silent. So, I guess I'm just going to have to start with the first puzzles in the second half of the game. Ideally, we would be able to finish scripting the puzzles etc. for the first three parts (out of four) of the game before summer, and then we could really start to think how we're going to pull off these damn video cutscenes.

Wow, great to hear this little thing has inspired you!

We chose the current frame rate (actually it changes a bit depending on the animation) because of two reasons: less frames equals smaller file size, and more importantly, it feels more classic adventure gamey. If the animation was smoother, it'd feel too much like the characters are actually filmed and not hand animated. That's also the reason why the game is low res. We want the characters to feel like they fit in that world as much as possible, and I think smoother animations (or a higher resolution) would make them seem too realistic.

Well, I might as well let you guys know where the project is heading today: nowhere. As expected, studying (actually mostly not studying) destroyed our nice little fantasy world where the production would never have stopped before the thing was finished. Hopefully, we might be able to kick ourselves back to work soon. No promises though. What I can promise, however, is that there's a 99% chance the game won't be released this year.   (This is my attempt to yet again make myself a liar by actually finishing the game before next year.)

Thanks, I'm glad to hear that!

That's kind of why there's the ability to convert the lines for export. For example, if you want different lines to be spoken with a different speaking animation you could do this:

1. Create your speech function: Character.SayStyle( string text, SpeechStyle style )

2. Include the style in your dialog lines, for example:

Code: ags

ego-eSpeechHappy: I'm happy!
ego-eSpeechSad: Well, not that happy.

3. Write the line conversion regular expressions: (these might be buggy)

Code: ags

Search pattern:
(?<name>[^:-]+)-(?<style>[^:]*):\s*(?<line>.+)

Replacement pattern:
  c${name}.SayStyle("${line}", ${style});

Now, the lines will be converted automatically to:

Code: ags

  cEgo.SayStyle("I'm happy!", eSpeechHappy);
  cEgo.SayStyle("Well, not that happy.", eSpeechSad);

I don't think it's really worth the extra work to have the ability to define your own custom speaking functions just to support them in the preview, which is exactly why I added the conversion feature. Actually, I don't think it's documented in the help file but the conversion only works if the line format is: "[text]:[more text]".

You mean you want to use Character.Say calls in a dialog and have those lines appear in the preview? In that case, I suppose Display calls should be supported as well. I'll think about it.

I'm happy to hear you like it!

Yay, I'm glad it works!

New version is up with some of the suggestions implemented: "say" checkbox if you want the option title spoken automatically, condition/variable errors during preview are now only warnings, boolean variables are now supported. Also, script editor undo/redo functionality has been added, it may or may not work as expected. I've encountered some very minor glitches only.

Thanks for all your enthusiasm, largopredator! Especially since you're currently the only user I'm aware of. Actually, I'm secretly happy this hasn't got any more attention than it has, since that usually means less bug reports and less work for me. On the other hand, it's a bit puzzling since the internal dialog editor drives me nuts. Anyway, the point of this rant is, if you haven't tried it yet, give it a go and see for yourself how much easier it'll make your life*.

*) Doesn't make your actual life easier, just the dialog writing aspect of it.

Okay, I've uploaded a new version that might fix the crash (check the first post). I haven't been able to test it myself since it's always worked for me. Try it out and see if it works now.

Thanks for the report! As I'd thought, it's apparently a problem with WinAPI calls, so I guess I'm going to have to do some extra work to eliminate the need for those.

Yay, that's the same error my friend got on Windows 7. I guess I'll have to investigate this further.

Thanks, I'm glad you find it useful!

- Clicking directly on the dialog option in the tree does not let me edit it, only double-clicking in the text field does? And that only works if the text field is empty?

Huh? Works fine for me. When a dialog option is selected in the tree and you click on it and wait a bit it goes into edit mode. F2 does the same.

- There's nowhere to set if a dialog option should be spoken or not. I use that distinction quite a lot for my dialogs.

I never use that feature so that's why I didn't include it. But yeah, I can add it if you need it. I figured it would be used mostly out of laziness to type the line twice, so that's why you can right click on the script and automatically copy the first line of dialog to the option text to keep it easily up to date. I don't think that's even mentioned in the help file... lousy documentation, I admit.

- A minor thing, but, I use the hack of adding a blank dialog option at the end to force dialogs to always show the option selection GUI always, even if there is only one option. But in AGS this option would not be visible if you leave it blank, but here it is (and selectable).

Oh, I wasn't aware of this hack. I'll change this behavior to match AGS in the next version. Also, I think I probably should have a "game.show_single_dialog_option" checkbox somewhere.


I'm not promising anything but I'll probably have enough free time early next week to get a new version released.

[==]

Okay, the undefined variables bug should now be fixed. I've uploaded a new version, see first post.

Cool, though I'm still a bit confused regarding the conditions. You say the variables can only be integers, how do the conditions work? I would assume you would have implementations of the standard conditional operators (==, !=, >, >=, <, and <=) but then all of those evaluate as boolean and you said that "player.HasInventory(iKey)" wouldn't work in the preview "since it's a boolean and not an integer". How then are the conditions evaluated?

Sorry, I should have been a bit more specific: the current condition parser doesn't recognize boolean literals, only integers. Every variable name is replaced with its value, resulting in something like: "1 == 0 || 2 < 3", which the parser can handle. "0 || 2 < 3" or "false || 2 < 3" doesn't work. Of course an easy way to include boolean literal support is to actually replace those variables with "1==1" for true and "1==0" for false. This might be implemented in a later version.

I actually would expect "player.HasInventory" to be ignored for the preview (unless as you say a variable as such was defined and given a value) and just treated as false (or 0 to be an integer). I'm not expecting your tool to implement full AGS scripting of course. So if it helps, I would expect it to just be ignored by the preview, but still implemented in AGS.

If the preview is allowed to ignore it, you can just write it as normal AGS script (obviously, this doesn't work with "show on condition" but the whole point of that is to affect the preview):

Code: ags

  if ( player.HasInventory(iKey) )
    doSomethingNasty();

instead of the custom command for defined variables:

Code: ags

#if ( player.InventoryQuantity[iKey.ID] > 0 ) { blah; }

Plus this one works only with dialog script commands. It's there for the ability to control the flow of the dialog based on variables and nothing else.

-edit-
On second thought, I'll probably make it so that if any invalid conditions or undefined variables are found during preview, errors will be shown for the user only after the preview has ended. I think that's the easiest way to let you ignore them and still give the necessary feedback in case they were actual mistakes.

I don't know what you mean by "update the project tree" exactly. You mean that once dialogs have been added/removed AGS doesn't reflect that?

Yes, that's the problem.

As for the dialogs being cached, I don't know about that, but I'm sure if you asked CJ he could probably implement a way to read them from the project instead of the cache.

Well, maybe he'll read this thread. I don't really want to bother him with this. Not yet anyway.

In any case, nice tool. How does it work with, for example, the new ability to do normal scripting in dialogs? Does it allow that? Obviously I wouldn't expect it to try and compile it or anything, but just curious whether it detects it as AGS script or gets confused what you're doing.

Normal scripting is highlighted in the script editor in italics and won't be run during preview. So no problem using normal scripting.

Also regarding the conditions, how does that work? Does it allow the condition to be based on AGS script such as player.HasInventory(iKey) or does it create variables for its own conditions? Again I wouldn't expect it to verify the authenticity of AGS script, just wondering on that....

If you want to use them in the preview, you can create a variable named "player.HasInventory(iKey)" and assign a value to it in the variables window. For now variables can only be integers, at least for the preview to work. Then you can modify its value with custom script commands and use it in dialogs. If you don't create the variable, then... the preview will apparently crash. Heh. I'll get that fixed. Anyway, those custom script commands will be converted to AGS if-statements (etc.) when you export the script.

For example, you have dialog option A and it has a child option B. B is set to be shown if a condition is true: "player.HasInventory(iKey)". This won't actually work in the preview, since it's a boolean value and not an integer, but it should be converted just fine during export. When that dialog is exported the condition is converted to these lines of script for dialog option A:

Code: ags

  if (player.HasInventory(iKey)) {
option-on 2
  }

I hope this clarifies some things. I'll get those "undefined variables" bugs fixed asap.

So you don't need AGS. Plus I don't think it's possible to do this without changes to the plugin api. At least I wasn't able to find a way to update the project tree, and the dialogs seemed to be cached somewhere rather than read from the project structure every time.

[Dialog Designer]

Hello, everyone!

I'd like to present to all of you a very special Christmassy utility that I mostly made in August, then forgot about it, and now finally finished for release. It's called...

Dialog Designer

Dialog Designer is a utility to help design and write dialog scripts. It contains many useful features that make the process easier and faster. Also, since it's a separate utility, it allows you to collaborate between other writers without needing to use AGS and still being able to preview the dialogs and see if they even work like they're supposed to.

I can already write dialogs with AGS. Why should I use this?

Well, in addition to the points I made earlier, you've probably sometimes been frustrated when you've had to add new dialog options to your dialog, and you have to go through a big hassle if you want to place them somewhere else than the bottom of the list. Those days are over now! With Dialog Designer you can add options anywhere you want and you can organize them into a tree that clearly shows the structure of your dialog.

Even better, you can move and delete options, and Dialog Designer keeps track of all the references made to any options. Let's say you have two options and in the first one you turn on the second one (option-on 2). Now, if you move the second one above the first one, the reference is automatically changed (option-on 1). I bet you can already see the time saved flashing before your eyes. If, on the other hand, it's your life flashing, I really can't help you with that.

There's also a bunch of custom script commands that work as shortcuts to a bigger bunch of AGS script commands.


How exactly is this going to make collaboration on writing scripts easier?

By allowing you to preview the dialog directly in Dialog Designer! In order to support more complex stuff, you can also define variables and use them in your dialog with custom script commands. The dialogs are saved into basic XML files and can be shared easily.


XML files? How am I supposed to get them into AGS?

That's easy! To setup the included AGS Editor plugin, you need to do the following:

1. Copy AGS.Plugin.DialogDesigner.dll to your AGS directory.
2. Run AGS, open your project.
3. Double click Dialog Designer node in the project explorer tree.
4. Select Dialog Designer.exe.

Then you can start writing dialogs and exporting them directly to AGS:

5. Write your dialog.
6. File -> Export to AGS -> Settings -> Set the dialog name.
7. Make sure AGS is open and your project is loaded.
8. In Dialog Designer, select File -> Export to AGS -> AGS Plugin (or Ctrl+E)
9. Switch to AGS, there should be a pop-up saying the dialog was imported successfully. You should see the dialog in your tree view.
10. To edit a dialog that you've already imported, open the dialog in AGS and double click on Dialog Designer in the project explorer tree.

You can also export the dialog in two other ways, either only the script into a text file or the entire dialog directly into your AGS project. If you choose to export into a text file, you will have to manually create or modify the dialog options in AGS. This step can be eliminated by exporting directly into your AGS project file. You can choose to create a new dialog or replace an existing one if you're only doing an update.


I'm still not convinced.

Then I guess you can f*ck off. Seriously though, what more do you need? Oh, maybe the ability to convert normal dialog speech lines to some other format, like Character.Say calls, during export? That's very much possible with Dialog Designer.



Features
Okay, now that we're done with the marketing speech, let's recap the main features:

- Dialog options are organized in a treeview that clearly shows the structure of the dialog
- Syntax highlighted dialog script editor
- Dialog preview
- Basic AGS dialog script commands work in the preview: option-on, option-off, option-off-forever
- Additional script commands that make writing scripts even easier
- Automatic dialog option reference management
- Variables and showing dialog options automatically if a specified condition is true
- Exports AGS compatible dialog scripts. If conditions or other advanced functionality is used, the minimum required AGS version is 3.1.1.
- Dialog speech line conversion



Known issues

- File -> Export to AGS -> Project does NOT work with AGS 3.4 due to changes in the project file structure. Please use the editor plugin instead.




If you're ready to give it a go, make sure you have the required .NET Framework 2.0 installed.

>> Download Dialog Designer << New version 1.3.0!

Change log available here: http://www.serpentpictures.net/dialogdesigner/




Feel free to post if you have any problems, comments, suggestions or bug reports!
I wish you all a very productive Christmas or any other holiday that may or may not be happening in the near future!

Yes, when you export the script to AGS all the option-on commands will be automatically generated, so you don't have to worry about them for that specific purpose. Of course, this program is not exactly what Guyserman82 asked for since you can only have one parent per dialog option, but it's a very useful tool anyway. What the heck, here's a feature list if anyone's interested...

- Dialog options are organized in a treeview which clearly shows the structure of the dialog
- Syntax highlighted dialog script editor
- Dialog preview (easy collaboration between writers, you don't need to send any other project files)
- Basic AGS dialog script commands work in the preview: option-on, option-off, option-off-forever
- Additional script commands that make writing scripts even easier
- Automatic dialog option reference management: if you reference other dialog options in a script, the references are updated if the index of the referenced option changes
- You can define variables used in your project and use them to conditionally turn dialog options on or off
- Dialog options can be shown automatically if a specified condition is true
- Exports AGS compatible dialog scripts. If conditions or other advanced functionality is used, the minimum required AGS version is 3.1.1. You can also export directly to you project file so you don't have to manually change dialog options in the editor.
- Dialog lines can be converted to any other format if needed. For example you can change export settings so that the line ego: I'm happy. will be automatically converted to cEgo.Say("I'm happy."); when you export the script. Or myfunction(cEgo, "I'm happy.");, whatever you want.

I guess I should hurry up releasing my dialog designer. By the end of this week, I promise.. I predict.. I probably hope so. Just needs proper documentation and it's done.


One of the main features is that you can organize the dialog options into a tree and have an option automatically show any options that are directly below it.