Exult Forum

Hi everyone, I've been working on a usecode editor for a while off and on and I think I've come to the conclusion that its probably easier to just learn the language (by the way if you ever want to learn something real well just try to write in in code) and edit it in a text editor.

While I'm wasting everyones time with this post; I'm wondering if anyone else is working on a usecode editor and if they are having any more luck than I am.

I thought of writing a conversation editor that genertates the appropriate usecode funtions, but I decided that it wouldn't save me enough time to be worth the trouble. I may yet change my mind down the road, though.


-Karl

I would really like to have a conversation editor, but I guess that would evolve quickly to a full blown usecode editor, especially if you add flags and such to conversations...
A simple conversation editor would not save much time and a not so simple one might be too much of an effort.

What you might make is something integrated in ES which lets you select conversation paths, and adds the framework to a UCC file that you also edit with a text editor in ES (with syntax highlighting?). Then you fill in the blanks.

I think I'd prefer to just write code with a text editor. Keep in mind that we could change the language if you can think of ways to make it easier.

The one tool I've been thinking of (but haven't started) would be something like Director for creating the scenes like the 'Fawn Trial' in SI. But I'm still not sure if it would be better than a (possibly improved) language.

The thing is that simple conversations aren't really that simple.

First off for a dialog editor you need alot more funtions that just talking. Several of the usecode options come up while talking, Join commands, Flag setting, flag reading, number bars, ect, so yeah a dialog editor quickly changes into a full usecode editor.

Second thing, from what I found it is difficult to do a simple dialog tree. You often have multiple responses that will bring up the dialog option and with the flags it gets all the more complicated.

I haven't actually given up on writing this editor, I'm just going to take another extended break from trying to write it. I was just wondering if the powers that be were also working on one or did they come to the same conclusion as I did; that its easier just to learn the usecode language.

I am still going to work on an editor from time to time because programing is fun . . . expecially anything as frustrating as this .

An usecode editor would definitely be useful for people less experienced in programming. So, even as it is frustrating it is welcomed and appreciated whenever it is done

makes you wonder if this was the debate that happened before work started on the first IDE.

Dominus:
"I would really like to have a conversation editor, but I guess that would evolve quickly to a full blown usecode editor, especially if you add flags and such to conversations..."

And that's a bad thing? A usecode editor would be nice for the code impared, like me!

if you read one you get my point:
"A simple conversation editor would not save much time and a not so simple one might be too much of an effort."

I know what you mean, but it would be a good thing if it "would evolve quickly to a full blown usecode editor".
I think we should aim less at a conversation editor, and more of a usecode editor WITH a conversation editor built in.

What about a program that takes some sort of conversation script and creates a usecode template from this? I don't think that might be too much effort to implement. One can add functions like flags, party joining and such in the usecode afterwards...

As a matter of fact, most usecode (at least in SI) is NON-conversation usecode.

I think Skutarth made a point when he said to make a full blown usecode editor, which by extension supports conversations. I have no clue how you could make such an editor though.

Artaxerxes

> What about a program that takes some sort of conversation script
> and creates a usecode template from this? I don't think that might
> be too much effort to implement. One can add functions like flags,
> party joining and such in the usecode afterwards...

Any suggestions on what such a 'conversation script' would look like?

Another thing to think about would be a way to simplify conversation-writing using Usecode. Our Usecode language is mostly C-like, but there's nothing stopping us from adding some special-purpose syntax for game-support.

Well, I must confess I've never taken the time to look at usecode language, but I thought of something like defining "comments" first like

comm1{Blahblablahblah}

, and then defining some "layers" where the conversation options and possible flags required for options to show as well as branches to other layers are defined:

layer1{
AvatarComm1:MajorComm1("name")
AvatarComm2:MajorComm2("people",switchto:layer2)
AvatarComm3:MajorComm3("murder",!flag:solved,switchto:layer3)
emptyComm:MajorBye("Bye",exitconv)
}

The compiler would create a usecode template from this which can be editited to implement more complicated things like joining and can afterwards be included into usecode...