Re: Pingus Scripting Language

[Jonas Bähr]

Am Donnerstag, 8. April 2004 00:49 schrieb Ingo Ruhnke:
> Could you elaborate on how you want to replace the function tag?

I think it's suffisant to give every block an attribute "name", like this:
<block name="my-func">
  some stuff....
  <return value=".." />
</block>

<block name="other-func">
  <call name="my-func" arg1="lalal" arg2="234" return="var" />
  do something with var....
</block>

instead of:

<block>
  <function name="fib">
    some stuff...
  </function>

  <funcall name="fib" />
</block>

I mean that if you already have several blocks of code, why introducing an 
<function>-tag instead of simply nameing your existing blocks...


> > If global variables are needed, I propose not to declare them outside the
> > blocks (like you do in C) but to import them in the particular block
> > (like php does). Therefore you need a new tag but you can be sure that
> > <script> only got <block>'s as childs:
> > <global local-name="localVar" global-name="externalVar" />
>
> Shouldn't be hard to implement, but it sounds however like overkill.
> After all this whole thing is meant for very little scripts and
> triggers and a few global variables don't hurt there.
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....

> > You could also add some predefined externals like "MaxPingusToSave"
> > 
> Functions will be easily add-able, so whatever is needed should be
> implementable without to much problem.

You're right... something like this
<global local-name="max-save" global-name="MaxPingusToSave" />
could also be done with
<call name="getMaxPingusToSave" return="max-save" />

> Functions exported from C++ can take a whole xml-tree as argument, so
> you could do stuff like:
>
> <insert-objects>
>  <hotspot>
>   <surface><resource type="datafile">
>     <resource-datafile>entrances</resource-datafile>
>   <resource-ident>entrances/snow_front</resource-ident>
>     <modifier>ROT0</modifier>
>   </resource></surface>
>   <position>
>     <x-pos>143.688</x-pos>
>     <y-pos>157.332</y-pos>
>     <z-pos>100</z-pos>
>   </position>
>   <speed>-1</speed>
>   <parallax>1</parallax>
>  </hotspot>
> </insert-objects>
>
> To insert an hotspot.

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....
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... 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.

> Stuff like random levels are better done on the C++ site, after all
> one could need some non-trivial there to check that the geometry is
> more or less useable, from an xml-script that would be pretty much
> impossible.

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....

Jonas