[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Enigma-devel] Lua API

From: Ronald Lamprecht
Subject: Re: [Enigma-devel] Lua API
Date: Wed, 24 Oct 2007 21:52:52 +0200
User-agent: Thunderbird (Windows/20070728)


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

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



reply via email to

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