Rocks'n'Diamonds

asikierka wrote:
> You, Holger, can delete the CE data from .level file and move it to .cedata file.
[some confusing suggestions removed]

What the heck should this be good for?!

Sorry, but I'm afraid you did not understand what this is all about.

The R'n'D level file is build up from IFF style data chunks (just like the internal format of a WAV file, for example). Although this works fine for (nearly) any number of CEs and (nearly) any number of change pages, there are some limitations for the number of variables that can be stored in the CUS4 data chunk. The problem here is that the CE / change page structure that can be stored in the CUS4 chunk has a limited (fixed) size.

Zomis wrote:
> Holger: I guess it's time for a CUS5 chunk...

That's exactly how I will solve this issue, most probably already with version 3.1.2.

> And probably you should add some extra bytes for future
> CE-possibilities. (Especially more CE action parameters...)

Yep, I'll do... Until it's time for a new CUS6 chunk. ;-)

> (Especially more CE action parameters...)

BTW: Which additional CE action parameters are you thinking of?

If anything impotant is missing, please let me know, and I'll add it, if possible. :-)

- file 001.vars with variables for level and it's support. (Not big important if read-only but if read-write this will be really great to my levels, dynamite number, more timing)
- PLAYERS need to collect [+,*,/,=] [new amount of emeralds] ( i not add here minus because that is possible)

NEW:

- Put object X at direction aligned straight line to object Z

Holger wrote:BTW: Which additional CE action parameters are you thinking of?

Set CE Count to (average/sum/multiplicated/min/max) of CE (element type).

And an extra parameter for whether to keep current CE Count/score when changing the element (for the change part, not the action part).

Get CE Count from element on (left/top/right/bottom) of current CE.(maybe include these "elements" into the first idea in this post).

That's probably it for now, I'll let you know when more comes to my mind

Set CE count (+,-,*,/,%,=) to level score

(Since it's possible to set the level score as well, then this could be used to transfer CE counts between CEs... but it would still be good to have what I suggested earlier!)
Any news about future CE actions, Holger?

> And an extra parameter for whether to keep current CE Count/score
> when changing the element (for the change part, not the action part).

It's better to solve this the other way round (just like the "start moving: [previous]" thing): "[x] use last CE value after change". This way it's possible to have several change pages with some pages keeping the last value after change, and some pages which start with a new value.

BTW: I renamed "CE count" to "CE value", because "CE count" seems to suggest to be the number of CEs in the playfield... (The "count" value still exists -- being the number of elements in the inventory for a collectible CE -- but isn't used anymore in CE actions to prevent confusion. The new "CE value" is a newly added CE parameter.)

> Get CE Count from element on (left/top/right/bottom) of current CE.

This should now be possible using the "CE value of trigger element" as the action parameter value, which can be combined with the usual "trigger side" logic.

> Set CE count (+,-,*,/,%,=) to level score

Just added.

> Any news about future CE actions, Holger?

Yes, there are a few more like setting level wind (for the balloon and wind affectable CEs) and player shield -- see for yourself in the next pre-release version, which will be availabe Real Soon Now.

Attention to all pre-release testers: Be warned that your current "CE action" test levels won't work with the next pre-release version, because I changed nearly all values for the three "CE action" select boxes due to an internal redesign. (You just have to go to the change page, re-set the selectbox values for CE actions and save the level again.)

Great! Now all that's missing for the CE values modifications is those sum, average, and multiplicate functions (at least sum and average would be greeat... I don't think it could be made already using some technique... but I'm not sure yet)

But now I thought about one other thing...
For the Move player, set speed, set shield, set artwork actions, there's no current way to specify which player that should be affected. Since all those actions doesn't use any =,+,-,*,/ operators, why not make a player operator there instead?

> Now all that's missing for the CE values modifications is those sum,
> average, and multiplicate functions

Just to understand you correctly: You mean a function to set the specified value to the average or sum of the CE values (for example) of all CEs on the playfield?

Multiplicating a value with the CE value of the triggering CE is possible now, if I don't miss anything.

> For the Move player, set speed, set shield, set artwork actions, there's
> no current way to specify which player that should be affected.

Well, currently it's always the triggering player or, if the CE action was not triggered by a player, any player is affected by that action.

> Since all those actions doesn't use any =,+,-,*,/ operators, why not
> make a player operator there instead?

Your idea is not bad... But maybe it's a bit confusing to have the options "1", "2", "3", "4" and "=" (or "A" for "any" and "T" for "trigger player") in the same selectbox... (not that the rest of the CE actions stuff is not already slightly confusing in it's current state, that is... ;-) )

>Just to understand you correctly: You mean a function to set the specified
>value to the average or sum of the CE values (for example) of all CEs on
>the playfield?

Yes

>Multiplicating a value with the CE value of the triggering CE is possible now,
>if I don't miss anything.

Yep, but I meant like a "sum" function but instead of adding all CE values, it would make multiplication of all CE values (this is not as much needed as SUM and AVG, especially since multiplication of all CE values for some CEs could get veeery big).


>Your idea is not bad... But maybe it's a bit confusing to have the options
>"1", "2", "3", "4" and "=" (or "A" for "any" and "T" for "trigger player") in
>the same selectbox... (not that the rest of the CE actions stuff is not
>already slightly confusing in it's current state, that is... )

Yep, indeed it's confusing... it would be better to have a little bigger selectbox there... or maybe it could be solved in another way, I'm not just sure how. Or maybe it's not necessary to specify the player at all

It's beginning to be clear that we need dynamic widgets (aka gadgets) in the editor. E.g. when you select "restart level", all other selectboxes disappear - instead of just being empty. The same may apply for change conditions (not just change actions): if you select delay, the game shows only delay controls. That would however need some "conditions list", like it already is for changepages. Actually, it could maybe be possible to have even more actions in one changepage. For example, a changepage interface could look like:
(Note: It's difficult to make a text representation for some widgets. {...}v is selectbox)
PAGE (+){ 1 }v(-) (COPY) (PASTE) (NEW) (DELETE)
CONDITION (+){ 1 }v(-) (COPY) (PASTE) (NEW) (DELETE)
- { ce value is equal }v
-- to (+) 3 (-)
-- of element {???}
ACTION (+){ 2 }v(-) (COPY) (PASTE) (NEW) (DELETE)
- { extended change }
-- to elements {???}
-- replace when {empty}v
-- ...

Of course, you may use just fragments of this solution if some things are impossible.
And btw, have you already added key shortcuts? (Suggested it in my mail some time ago.)

Interesting...But what do you mean by "(COPY) (PASTE) (NEW) (DELETE)" for "CONDITION" and "ACTION"? Sub-pages of change pages for conditions and actions? Sounds a bit confusing to me at the first look... :-)

> And btw, have you already added key shortcuts? (Suggested it in my mail
> some time ago.)

Nope -- I have no idea how to add them in a systematic way. Any ideas?

> Sub-pages of change pages for conditions and actions?
Yes, it's confusing, and that's a big disadvantage, but I consider it also powerful and screen space saving. But I don't know the source enough to know if it's effective, feel free to not use it.
(Another advantage: currently there's just one condition of one sort at one changepage, e.g. you can't have two "touching" condition, although you can have one "touching" and one "delay" condition. Conditions list could solve that.)

Is there any technical advantage of one change page with two "touching" conditions over two pages with each one "touching" condition? Especially if you need one change page with two sub-pages with each "touching" condition, I really see no advantage - - in fact, the only difference seems to be that the visual presentation is even more confusing than it is now, if you use an even deeper hierarchy of pages and sub-pages, I'm afraid... :-/

OK then. No need to use every idea and you know the source better than me* so I believe you.
( * - well, I hope so. )
But what about the actions list? That *could* be more useful.

> OK then. No need to use every idea and you know the source better than
> me* so I believe you.

I think you misunderstood me -- I was not referring to the source code, but purely to the visual presentation of an interface as supposed by you.

My point was purely usability of the graphical user interface -- if an alternative way to define CE changes and actions is better, it's always possible to write this down into source code, so that's not the problem here. :-)

> But what about the actions list? That *could* be more useful.

Yea, you may be right. Another question: Was your main intention to use more than one action at the same time (for the same condition)? When looking at your scribble, I'm not sure if it's related to CE changes or CE actions (seems to be both), so probably it would be helpful if you could describe your intention here. :-)