[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Pingus Scripting Language
From: |
Ingo Ruhnke |
Subject: |
Re: Pingus Scripting Language |
Date: |
Thu, 08 Apr 2004 02:53:25 +0200 |
User-agent: |
Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) |
Jonas Bähr <address@hidden> writes:
> I mean that if you already have several blocks of code, why introducing an
> <function>-tag instead of simply nameing your existing blocks...
I don't see much advantage in reusing blocks, currently blocks are
just a workaround to get a single-root document, necesarry in xml
documents. For function I am thinking of:
Define a function with arguments x-pos and y-pos:
<function name="foo" x-pos="0" y-pos="0">
...
<return value="5" />
</function>
call this function and write return value to bar:
<foo x-pos="0" y-pos="0" return="bar" />
<print value="bar" />
'funcall' is currently just a workaround, I think we don't need to
have seperate namespaces for build-in functions and custom ones.
> Well, I can't say yet if globals will become nessesary, but if they
> do you got with the php-method only blocks of code in the first
> level and no global declarations floating around....
Globals are very important, since they would be global to a complete
level, ie. one trigger could set some variable, while another trigger
could request the value. Global variables are currently the only way
this communication would be possible.
> Ok, but if you simply take all childs of <insert-objects> and treat them like
> read from the level-file directly something like
> <insert-objects>
> <hotspot>
> ...
> <position>
> <x-pos> <value var="my-var" /> </x-pos>
> </position>
> </hotspot>
> </insert-objects>
> won't be possible... But ok, this may be a bit too complex but could be very
> intresting....
Should be to hard to add I hope, would just require to recurse over
the DOM and replace all occurences of <value ...> with its evaluated
value.
> Have you also planes how to remove exising objects or manipulating (like
> moving) them? Implementing access to the whole DOM would be a bit too much
> for the scripting-language...
Yep, especially since the DOM is gone once the level is loaded, ie.
the worldobj does really know nothing about the DOM.
> Maybe with unique id's:
> <hotspot id="hotspot-xy">
> ...
> <position>
> <x-pos>123</x-pos>
> </position>
> </hotspot>
>
> <block>
> <call name="replaceValue" arg1="hotspot-xy" arg2="position" arg3="x-pos"
> arg4="124" />
> <!-- remove -->
> call name="removeElement" arg1="hotspot-xy" />
> </block>
> Which will find the element with the id "hotspot-xy", then go to
> child "position", then to child "x-pos" and then set "124" (the last
> argument) as new child of the later.
Doing this via the DOM is impossible, custom function however should
be possible, ie.:
<hotspot id="foobar>
...
</hotspot>
...
<worldobj:set-position id="foobar" x-pos="100" y-pos="100" />
> Hmm... I think you're right... Even if it would be great to have
> differend kinds of random-levels as simple level-files it would
> burst the possibilities of an xml-based scripting-language....
You can always export a function with which one can configure the
random level generator, ie:
<generate-random-thing width="100" heigh="100" type="foo" />
--
WWW: http://pingus.seul.org/~grumbel/
JabberID: address@hidden
ICQ: 59461927