pingus-devel
[Top][All Lists]
Advanced

[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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]