2 ideas.

[Aoe]

My 1'st idea
to be able to change the transperency in the text like this:

asdasdasdasd.png (668.39 KiB) Viewed 3016 times

2'nd idea
make "CTRL + Z" fit with the undo in editor

will someone do these for me ? <3
and if so admins, would you add to ddnet client?

[Fňokurka oo7]

I heard that undo is bugy?

[Lady Saavik]

I heard replying is buggy too

[Savander]

but you can enable undo :c cl_editorundo 1 :c

it just saving it every x seconds :c

[Fifi]

it just saving it every x seconds :c

D: okay...

I think that one, kinda reasonable implementation of undo is to keep track of all operations using a register and just doing them backwards if needed. It could be a stack constructed of:

Code: Select all

struct Operation
{
	enum OperationCode operationCode;
	float value; // I guess everything in Teeworlds is described using floats, am I right?
}

Where OperationCode is:

Code: Select all

enum OperationCode
{
	PARAMS_BEGIN,
	PARAMS_END,
	GROUP_OPERATION_BEGIN,
	GROUP_OPERATION_END,
	OPERATION_1,
	// (...)
}

---

If any operation requires more than one data "value" field - like, for example, placing a block (x coordinate, y coordinate, block ID, map group, group layer, additional values of tele/switch/speedup layers, &c.), we would fill its "value" field with dummy argument and put a params block after it. Such block would begin with "PARAMS_BEGIN", end with "PARAMS_END" and would be filled with the preceding operation data.
Example:

Code: Select all

{PLACE_BLOCK, 0},
{PARAMS_BEGIN, 0},
{PLACE_BLOCK_X, 12},
{PLACE_BLOCK_Y, 45},
{PLACE_BLOCK_BLOCK_ID, 22},
// &c.
{PARAMS_END, 0}

---

If any operation consist of multiple operations (like copying is in fact a multiple block placement), we will fill its "value" field with a dummy argument and then wrote down all atomic operations it's constructed of, surrounding them with "GROUP_OPERATION_BEGIN" and "GROUP_OPERATION_END". Optional group operation parameters could be put between its struct and the struct of "GROUP_OPERATIONS_BEGIN".
Example:

Code: Select all

{BLOCKS_COPY, 0},
{PARAMS_BEGIN, 0},
{COPY_X_1, 10},
{COPY_Y_1, 5},
{COPY_X_2, 30},
{COPY_Y_2, 15},
{COPY_MAP_GROUP, 2},
{COPY_GROUP_LAYER, 3},
{COPY_NEW_X_1, 40},
{COPY_NEW_Y_1, 20},
{COPY_NEW_X_2, 60},
{COPY_NEW_Y_2, 30},
{COPY_NEW_MAP_GROUP, 2},
{COPY_NEW_GROUP_LAYER, 3},
{PARAMS_END, 0},
{GROUP_OPERATION_BEGIN, 0},
{PLACE_BLOCK, 0},
{PARAMS_BEGIN, 0},
{PLACE_BLOCK_X, 40},
{PLACE_BLOCK_Y, 20},
// (...)
{PARAMS_END, 0},
{PLACE_BLOCK, 0},
{PARAMS_BEGIN, 0},
{PLACE_BLOCK_X, 41},
{PLACE_BLOCK_Y, 20},
// (...)
{GROUP_OPERATION_END, 0}

When user does anything in the editor, the relevant structs are put onto the stack. If user opens the undo list, the stack is displayed (in a user-friendly form, of course :3). If the user undoes anything, we just take structs back from the stack and do them backwards until we reach the one below that chosen by him.

Of course, it will be necessary to check if all operations are represented and handled by this code after every change in the editor, but I guess it's the price to pay (I don't see any way of doing it at compile-time, so we'll have to be careful not to add any functionality without adding it to the undo handler, as the user may damage its map by assuming that everything can always be undone). ^^

[mod=Soreu]When you have more than single line of code, please use

Code: Select all

 instead of [c][/mod]

[Chairn]

Go ahead now, the code is freely available at github .

[Fifi]

[quote="Soreu"]When you have more than single line of code, please use

Code: Select all

 instead of [c][/quote]
Thank you, I didn't know about it and had to made that crazy manual indentation. ^^

[quote="Chairn"]Go ahead now, the code is freely available at github ;).[/quote]
Okok. ^^ I don't really have time for the next couple of days, as I'm learning for one exam and coding my Bachelor's Work, but I'll try to implement this as soon as I finish my studies stuff.

[HMH]

@Fifi in my opinion this should rather be done polymorphic: You have one base class containing only an ID and then you derive all the editor-actions from it, which contain all arguments. The stack then contains a list of pointers to the baseclass, which can be casted to the actual action using their ID.

Qt for example uses this approach for its eventsystem: http://doc.qt.io/qt-5/qevent.html

[Fifi]

That would be more logical and objective (as my approach is rather C-like), but I'm a bit worried about the necessity of creating a new subclass for every editor action. :c

[HMH]

Well, not every action, just those with arguments. However if this is really not what you want you could do some c style voidpointer stuff: Every stackitem consists of a type and a void pointer, the voidpointer can then be casted accordingly to the type. For example to an int or for more arguments to a struct containing the arguments.

Though the c++ way is easier to read imo.

Btw, I posted this suggestions cause I do not like the groupparams stuff and well I am not sure if a float is sufficient for every editoraction xD