Re: [Enigma-devel] Lua API

[Ronald Lamprecht]

Hi,

Andreas Lochmann wrote:
> > > > Consecutive naming of objects (building object groups)
> > > >
> > > >   wo[pos] = {"st_chess", color = 0, name="Atrax#"}
> > > >
> > > >   For each call of the line above the new object will be named with 
> > > > a unique
> > > >   number appended after the "#" giving "Atrax#1", "Atrax#2", 
> > > > "Atrax#3", ...
> > > What happens if I set "Atrax#2" directly and then create "Atrax#"?
> > >
> > > And, if I create "Atrax#1" and "Atrax#2", then delete "Atrax#1" and
> > > create "Atrax#" again, which will be the new name?
> > >
> > > Can I access a group like a lua-table, like in:
> > >  for j, v in pairs(no["Atrax#"]) do
> > >    ...
> > >  end
> >
> > "Atrax#" uses *unique* numbers appended to the name. If "Atrax#2" 
> > already exists this number/name will not be reused. If "Atrax#1" gets 
> > deleted and further "Atrax#" objects will be created the name of 
> > "Atrax#1" will be reassigned to the first new object.
> Ah, okay. So, when there are "Atrax#1" to "Atrax#5", and "Atrax#2" is 
> removed,
> then after deletion there will be "Atrax#1" to "Atrax#4", with the last 
> objects
> being renamed? I.e., I can't be sure that "Atrax#3" is always the same 
> object?

No object will ever be renamed by the engine. But unused names will be 
recycled - but only on behalf of the level author who issues a second 
"Atrax#" auto naming request.

Yes, you can't be sure that "Atrax#2" is always the same object? In all 
Enigma releases the names of objects are passed on to successor objects 
even without the level authors request. Additionally the author has 
always been able to kill an object and to reuse its name for a new object.

But the new API allows you to keep a persistent object reference. This 
reference is all time unique. The reference of an existing object will 
never be equal to any other existing or previously killed object.

> > > Is it neccessary to switch from "openclose" to "open_close" etc?
> >
> > It is not necessary to switch. All namings of classes, attributes, 
> > messages and functions in the draft are preliminary and subject of 
> > common aggreement.
> >
> > For all messages that toggle objects between two states like onoff, 
> > openclose,... we will introduce an additional common messages 
> > "toggle". This allows sending this most common message to groups mixed 
> > up of different objects.
> We already have "trigger", which is used to toggle many objects ... ?
>
> What does it mean to "toggle a fourswitch"?

When I listed all used messages and attributes a few weeks ago I noticed 
that we have a really mess concerning the messages names. And "trigger" 
is the worst case:

The message "trigger" is an internal message that occurs in pairs - with 
a raising and a trailing edge. It has an argument that describes the 
direction from which the trigger did take place. Currently the only 
"official" trigger source is the st-bolder (this may the reason for its 
name). Unfortunaly the target that has urgent need of the direction, the 
stoneimpulse, uses the inverted direction and due to a clear typo it 
pushes a bolder back instead of leaving it silent at its side.

Furtheron many authors of other objects did add a support for a trigger 
message because they thought it is a single message without argument 
that requests a toggle of the receivers state.

But we still have the "signal" that sets states and all the object 
specific messages like "onoff", "openclose",...

For this reason I try to separate the different usages. "trigger" as a 
message with raising and trailing edge, and "toggle" as a universal 
messages suited for the target-action paradigm that takes no argument 
and is a request to toggle to the receivers next state.

Thus "toggle" opens a closed door, closes an open door. It turns a 
mirror and a fourswitch.

Greets,

Ronald