Forum - DDraceNetwork

My 1'st idea
to be able to change the transperency in the text like this: 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?

I heard that undo is bugy?

I heard replying is buggy too

but you can enable undo :c cl_editorundo 1 :c

it just saving it every x seconds :c

Savander wrote: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: Where OperationCode is:

---

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:

---

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: 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

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

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

@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

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

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