CE Action: move element [X]

[Sascha]

Hallo!
A new CE action would be nice:

[ ] [move element] element: [X]: [1] places [right.]
....................................................[2]...........[left...]
....................................................[3]...........[up....]
....................................................[n]...........[down]

What do you mean?
Sascha

[Francesco]

Which instances of element X should be moved, and in what time?
It's quite easy to avoid such questions: simply make a CE that moves according to the event of another CE, and you're done. So no need for such an option. Well, just my opinion.

[Zomis]

I think that the [x] parameter is not necessary, and that only the current element should be moved [n] steps in [direction]

[Francesco]

If the element that carries such an action is also the target of the action, I don't see the need for a "dedicate" option. We already have moving CEs and changepages. They already do the job, I think.

[Holger]

I think that this would be a very "special" option and, as Francesco already described, that it is probably not worth the programming and layout work, as everything that such an option can do is already perfectly possible with the current options and possibilities.

[Tomi]

I already posted something like this to the 'change actions' thread. Some thoughts: the action should only move "self". Speed should always be the move/fall speed from config page 2. Essentially, it should work like 'move player' action, but it wouldn't move the player, but the CE. In my opinion, it is useful, and my version doesn't even require any new widgets/layout.

[Francesco]

Tomi, could you make one usage example that gets a result that is not possible to achieve with "normal" moving CEs?

By the way, I think that Holger meant "programming" and "layout" about the engine, for the gameplay, not just about the editor (which would be the easiest thing).

[Holger]

In fact, I meant both.

Making the editor more and more complex (and complicated), also in a "visual" way (more and more options, selectboxes and other widgets), for no real new functionality, is a bad thing IMHO. It's already too complex... :-/

[Tomi]

It doesn't make new features possible, it just makes it possible with less CEs. You already can change to a CE that's identical, but moves in some direction, and changes back in X frames, but this is easier.
An example how to use it: various custom moving patterns. For example, you can make an object that moves on a special pre-programmed path, or something similar. I think it could be useful.

[Holger]

Hmmm... Then I will rethink that idea again, maybe in a more generic way...

[Francesco]

Well, indeed it would save CEs... expressed in this way, your example is really nice, Tomi. In effect it adds to the CEs the ability to move in certain cases, and to stay still otherwise... hope that this could be done with not too much coding struggle.

It would be nice if that option could be added without changing the actual 3 fields action definition. I think it could be discussed a little.

"Easy to set" solution: we could make it move using the settings of CONFIG2 - just like said by Tomi some posts above. In such a case, the new action would be just like this:
[move] [seconds/frames] [amount of seconds/frames]
Drawback effect: you are tied to one kind of movement (only "left", only "along right side" and so on).

"Flexible" solution: we could add an action for each type of movement, so that the first dropdown list holds several different actions like [move left] and [move maze runner style].
Collateral effect: this would make the actions list quite long.

The middle field (the really small one) doesn't need to change, as it could simply hold an "f" or an "s" to mean "frames" and "seconds".

Both the above solutions would:
- need to change the last dropdown list in a number field.
- have another drawback effect: you are tied to one moving speed (as it should use the one set in CONFIG2).

And now, to get rid of the above drawback effect relating the speed... "Hell of editor rearrangement" solution: allow setting the kind, the speed and the duration of the movement, all from the changepage...

All in all, good idea, Sascha!

[Francesco]

Addon to the idea above...

Given that the "Hell of editor rearrangement" solution would be the best one, I have an idea to make the actions list a bit more "clever".

We already have the second and the third fields that change according to the way you set the first one.

The idea is to let the first list show just the "type" of actions, in this way...

Code: Select all

NO ACTION
[LEVEL ACTIONS]
[PLAYER ACTIONS]
[MOVE ACTIONS]
[CE ACTIONS]
[ENGINE ACTIONS]

...and then, when you select one type of action, the list should stay open, expanding the relative section, in this way:

Code: Select all

[ANOTHER TYPE] or [UP ONE LEVEL] or alike
MOVE LEFT
MOVE RIGHT
[...]
MAZE RUNNER STYLE
MAZE HUNTER STYLE

"when dropped/thrown" and "when pushed" should be kept out of this, I think, in any way we would implement this new feature (if we would, but I definitely think we should).

[Tomi]

> Both the above solutions would:
> - need to change the last dropdown list in a number field.
That's not exactly true. The user should be able to choose even things like 'CE value' or 'CE score of target element'. This is also true for actions like 'set CE value' - the user should also be able to choose a normal number, not just the predefined ones. So the ideal choice would be some sort of a "combo box" where you can type numbers but when you press the dropdown arrow, the regular dropdown list appears. However, this isn't an easy thing to implement. (I think that I already posted this combo-box idea, didn't I?)