iiYO Community

Pages: 1 2

Looks like I have really messed things up after adding nesting for

Code:

<with ...>

, because

Code:

tests/move_command

is broken now and I don't really know how to easily fix it. This situation raises some questions I want to discuss.

First, let me explain the problem. I believed that

Code:

<trigger ... function="execute">...

is something very similar to

Code:

<trigger ... scene="..."/>

, however they are in fact very different.

Code:

<trigger ... scene="..."/>

is safe and neat, because commands from the scene are pushed to stack only when interpreter is ready. However, this is extremevy uninteractive for the same reason. Example: let's say we put something like

Code:

<alert/>

inside, and triggered keypress during some looooong movement animation. Alert will appear seconds after keypress, when interpreter is ready to enter the subscene.

Code:

<trigger ... function="execute">...

is different, it is executed in parallel with the game routine. This is not perfectly safe for that reason, because two stack operations can be done at the same time, two transforms can be casted on the same image, fadeout started for a sound while it is being fadein, etc. This mode may be perfect for very simple zero-time non-interactive stuff like

Code:

<var .../>

, for instant layer hiding or for showing something completely unrelated to the game like an options menu of some sort, but it is not that good for allowing user to call just any command from

Code:

out.functions.execute.allowedCommands

.

Those two triggers seems to be quite the same, but you would see the difference once you push a button several times not .

Code:

<trigger name="alert1" event="keyup" key="E" function="execute"><alert /></trigger>

    <trigger name="alert2" event="keyup" key="R" scene="alert" />

    ...

    <scene name="alert"><alert /></trigger>

And here comes my nested version of

Code:

<with ...>

, adding a stackframe to execute the right branch. This behaviour is really nice, i'm very satisfied with things you can do with it (see

Code:

tests/var_choice_commands

for example). This version of

Code:

<with ...>

compatible with

Code:

<scene ...>

, but you can't use it with

Code:

<trigger ... function="execute">...

.

A possible workaround may be in passing flag of some sort into

Code:

out.commands["with"]

to let it know if it is called from trigger by user or from scene by interpreter. To make things even more ~~complicated~~ easier, you can even make two different command implementation lists for triggers and for scenes, with the same functions for stuff like

Code:

<var>

and with different for

Code:

<with>

, so that zero-time commands would be executed separately.

And here comes another interesting topic: is any of those two behaviours right? Is it OK to do stuff while other commands is running? Is it OK to do stuff after waiting several seconds for running commands to finish? Let's take a look at

Code:

<trigger ... special="next"/>

. It triggers next statement after waiting for rinning commands to finish, without cancelling any of them. Recently I have tried converting to WSE a RenPy's game (http://cf.ichan.ru/games/vn/SpeedAddict/www/ , in russian language only), whose author loves to use 4second pauses. This looks like the game is not responding, when you left-click and nothing happens. So you click another time, and another. And after those 4 second wait is finished, some lines become skipped because of multi-clicking. Thi

As a result, I need a way (maybe optional, maybe not) to stop ongoing commands. This automaticly would also give us an interpreter which would be able (after cancelling background tasks) to start a subroutine by trigger both instantly and safe. In this case execute function for triggers can be just rewritten to add another frame to call stack and the old variant may be removed completely (execute may be also used in

Code:

<fn>

, but there is no point to do so, because it is no different from running the commands directly).

Sorry for lots of text, I just thought a lot about it and I really want to hear your opinion on it.

This is one of the main reasons why I want to rewrite the engine to use a real interpreter with its own syntax. You see, the thing that's currently in the engine doesn't really deserve the name interpreter. The new one would have to support some form of parallel execution.

Also, as I just mentioned in another thread, the MO5 library that was once a part of WSE is now much more sophisticated than the old version used in the engine. It can do all those things like stop, pause and resume animations (and other time-related stuff) at arbitrary points. The transform function in recent versions of the library all return a Timer object that makes it possible to control the transformation while it's running.

The new interpreter should probably use some sort of fake threads that can be suspended and have better control structures to make it easy to do timing stuff. Something like the following maybe?

<pre>

Code:

(para

    (command1)

    (seq

        (seq-command1)

        (seq-command2))

    (command2))

(another-command)

</pre>

Para would run all its stuff in parallel and only after everything is finished another-command would be executed. The normal mode of scenes would be like seq. Seq means all its commands are executed one after the other. So in the example above, it would all be executed like this:

<pre>

Code:

----------- command1 ----------

        /                               \

start --- seq-command1 --- seq-command2 --- another-command --- stop

        \                               /

         ----------- command2 ----------

</pre>

And for more sophisticated stuff we could have:

<pre>

Code:

(define my-parallel-task (fork some-function))

(start my-parallel-task)

(pause my-parallel-task)

(resume my-parallel-task)

(stop my-parallel-task)

</pre>

What do you think about that?

Well, that's quite interesting.

I'm not sure about the syntax. In one hand, rpy2wse performs conversion in 2 phases, first it collects renpy data, then generate the code, which means I can fast and easily rewrite it to use any kind of syntax, so you are free to change it if you want. In other hand, there are non-IT people who have already learned it and who can find it hard to relearn everything. I don't think something is really wrong with XML, except for not allowing to use HTML formatting in every attribute.

The things you propose are really related to engine architecture, not the syntax. And they are really nice. Doing several things in parallel with engine's control of it behaviour means that just everything can be properly and instantly paused or canceled with going to the final position of transform. This will provide us power to implement really awesome and useful stuff like pausing sound and animation on menu and adding a fast-forward button (useful to skip parts that player have already seen before or just find annoying Smile

).

I have only two question really:
* how much time do you think would it take? I'm not familiar with MO5 details, so I don't have a clue if it is easy to change engine or not.
* would just everything be rewritten from scratch? Should I pause my work then to wait on next-engine version to appear?

I was thinking about it and maybe it's a good idea just to remove "execute" function from triggers. It seems fine to me now when scene attribute works with triggers, so a subroutine with any commands is called when it's safe too call it. This would make current 0.4 build consistent and so you finally could already release 0.4.0 with long-awaited stuff like xAnchors.

Execute function is undocumented ( http://webstoryengine.org/language:functions ) and even var children of triggers are undocumented too (http://webstoryengine.org/language:elements:trigger).

I already started working on it but it will still take a long time, I guess.

To sum up what I have so far:
- A lot of ideas
- The interpreter is maybe 20% finished
- Audio is maybe 70% finished
- Canvas stuff is not even started
- Module system is finished
- Better timing facilities are usable

I try to keep the interpreter separate from the base stuff like assets. If you think you're up for the task when the API has been determined, it might be a cool idea to implement a Ren'Py interpreter as an alternative to the default language. Not sure if that's feasible though, I don't know enough about Ren'Py to predict that.

Of course the execute function and any commands inside of trigger are undocumented. I just added those in like 20 days ago and there hasn't been a release since then. It would be bad to document stuff that's still not released, at least when adding to the existing docs on the wiki.

Your changes to the stack handling made the execute function obsolete right after I added it in. It can now be removed.

C7N Wrote:I already started working on it but it will still take a long time, I guess.

Well, that basicly means that we (or just I) can continue developing 0.4.x (or even 0.x) while basis for the brand new version is being created.

C7N Wrote:If you think you're up for the task when the API has been determined, it might be a cool idea to implement a Ren'Py interpreter as an alternative to the default language.

Nice idea. I have already tried implementing a very simple RenPy subset interpreter in Lua many years ago, so supporting simplest stuff is surely possible, but complex constructions may be very tricky, forcing some architecture features in graphic subsystem to be implemented. Maybe a RenPy-like language is a better alternative, then playing unchanged RenPy files (anyway, changes are needed, because RenPy allows inserting raw python lines and blocks among other statements).

Simple RenPy script can be found at http://cf.ichan.ru/wse/the_question/game/script.rpy , this is a standard test game from RenPy SDK and it is already converted to WSE quite good ( see http://cf.ichan.ru/wse/the_question/ )

C7N Wrote:I just added those in like 20 days ago

Oops, didn't notice that.

C7N Wrote:there hasn't been a release since then

Do you plan any releases in some nearest future? There are lots of changes I'd like to document at wiki since it's open for editing, but without releases it is pointless.

C7N Wrote:Your changes to the stack handling made the execute function obsolete right after I added it in. It can now be removed.

Ok, I'll add that to the pull request.

https://github.com/lolbot-iichan/WebStor...315f5ffd39

tests works again, now using triggers that are calling scenes.

Cool. I think we should just make a feature freeze for 0.4, test it some more and release it.

Runned "the question" on my old phone, found&fixed some issues, please accept pull request. No new features this time, only fixes, i promise =)))

Pages: 1 2

_lb_

Guest

Guest

Guest

Guest

Guest

Guest

Guest

Guest

Guest