Engine Bug - undo until last shroud update

[sylph]

If you make a move and the move updates the shroud, should you be able to undo until the last shroud update even if part of the move updates the shroud?

[Wintermute]

I am really confused by your question, so maybe I am misunderstanding it, I just read it 4 times and I'm still not sure. But I think no: If the move updated any fog or shroud then you can't undo it.

Is that happening for you? If so what version of the game are you playing, do you have delayed updates turned on?

[zookeeper]

The only sensible interpretation for the question I can think of would be "if the last step(s) of a move do not reveal any shroud but the previous steps did, can you undo those last step(s) even if you can't undo the whole move?". Is that right?

[Anonymissimus]

Hm. I interpreted it differently; there are moves possible that update (or should update) (do they ?) shroud by "passing by", but not by the end position. So the midth of the move would have updated shroud, but still it's undoable, and that would be a bug ?
IMHO this question would only be understandable with some screenshots and cleaner speach (what sort of shroud update, manual, etc ?).

[sylph]

The only sensible interpretation for the question I can think of would be "if the last step(s) of a move do not reveal any shroud but the previous steps did, can you undo those last step(s) even if you can't undo the whole move?". Is that right?

"should" not "can"

It seems to me that undoing should revert to the last shroud update. Currently, undoing does not rewind until the change of the most recent shroud update. However, I don't know C++ or Wesnoth Engine, so I am not 100% confident that the code is not correct.

[sylph]

I asked this question:

If you make a move and the move updates the shroud, should you be able to undo until the last shroud update even if part of the move updates the shroud?

I naively expected somebody with some C++ knowledge to state an intelligently reply, such as:

No, it is unfortunate that undoing doesnt revert unitl the last shroud update. However, it has been the best of bad alternatives. Ambushed is calculated via coordinates. The undoing that you describe would be calculated hex by hex. Calculating shroud for each hex of movement cost more CPU for the server than it is worth. We didnt want different undoing for multiplayer and single player. So, that is why it is the way it is.

instead the dev replied:

IMHO this question would only be understandable with some screenshots and cleaner speach

I am not accustom to this level of competency. Hence, Anonymissimus, based on my standards, the problem is you and devs like you. From my perspective, it seems that the most valuable contibutions you can make to the Wesnoth project is not contributing at all. It seems that it would be best for the Wesnoth community if you be banned from vital operations, including the engine.

Still, it seems that the Wesnoth project has been rather successful. It seems that despite the quantity of delete code on GitHub that the commit process is considered favorable. So, perhaps, my standards of competency should not be applied.

I am not accustom to this level of rudeness. I made a thoughtful question about an engine bug and nobody attempted to answer the question. I expect that if a Wesnoth player asks a good question about an engine bug that a Wesnoth dev would answer the question! Collectively, the devs looked at a good question from a player and ignored the question! It seems that it is exactly the collective responsibility of the devs to answer such questions. Players who ask good questions, such as myself, deserve better treatment.

[zookeeper]

No one knew what you were asking, because your question was very unclear. It was not rude to say that your question is only understandable with screenshots and cleaner speech.

[iceiceice]

sylph: I did read this a month ago, and when I looked at it again I thought it meant something completely different.

1. Suppose I reveal some shroud, disabling undo, but then I do some more moves that don't reveal any more shroud. Can I undo those moves? (This is what I thought you asked the first time.)
2. Suppose I click once, and partway through the move, I reveal some shroud, but the remaining steps of the move don't reveal any shroud. Can I undo the final steps? (This is what I now think you were asking.)

Can you see that there is ambiguity, and it has nothing to do with C++ expertise?

I can tell you that the answer to (2) is no, it doesn't do that. Currently the engine stores each move order as a single unit, and doesn't break them up into individual steps. In principle we could do that, but it would make using the replay viewer cumbersome if you have to click for each step... I don't think its a bad idea to be able to undo individual steps, but it should wait until next replay viewer upgrade.

so I am not 100% confident that the code is not correct.

It's not about code correctness, it's about design. It's only designed to allow you to undo orders. There's nothing wrong with that design, and there's alot right with it. First of all this system is simple and it works, second of all, if you break every step up into a config, it will make all your save files and network transactions slightly larger, and add to the code complexity, so there's a definite tradeoff.

Edit:

Sylph, IMO you are way off base here. Multiple devs separately asked you to clarify your remarks, and you didn't, so understandably no one did anything. Then you wait a month and turn into a rage-o-saurus.

The idea that you should now call for someone to be banned because of this interaction is ridiculous. What did you do to help the project here? Did you file a bug report? Did you file a feature request? No. There are many ways to contribute to the game, and contributing detailed and precise bug reports and feature requests is a very important one. The devs will look at the forums, but you should expect that things written on the forums may be forgotten esp. if they don't constitute a valid feature / bug report. If we spent all day pondering things someone wrote on the forum that didn't quite make sense to us... we wouldn't have a lot of time to make the game. Multiple people already explained that they didn't understand what you were asking, insulting them will get you nowhere fast.

[sylph]

No one knew what you were asking, because your question was very unclear. It was not rude to say that your question is only understandable with screenshots and cleaner speech.

The rudeness, to which I was referring, was looking at a good question and upon clarification ignoring the question.

Can you see that there is ambiguity, and it has nothing to do with C++ expertise?

A. ambiguity

Can you see that there is ambiguity,

No, I thought my question was clear. Still, if people found that the original question was not clear, after the clarification:

The only sensible interpretation for the question I can think of would be "if the last step(s) of a move do not reveal any shroud but the previous steps did, can you undo those last step(s) even if you can't undo the whole move?". Is that right?

"should" not "can"

It seems to me that undoing should revert to the last shroud update. Currently, undoing does not rewind until the change of the most recent shroud update. However, I don't know C++ or Wesnoth Engine, so I am not 100% confident that the code is not correct.

The question is clarified.

B. C++ expertise

and it has nothing to do with C++ expertise?

yes and no. The question is about design, not about the implementation of the C++ programing language. Asking the question has nothing to do with C++ experise. However, understanding the engine design is requisite for answering the question intellegently. The engine is written in C++.

There's nothing wrong with that design, and there's alot right with it.

So, curently, the undo procedure can undo movement hex by hex. It is that the engine storing the orders does not fully support the undo funtionality.

It's not about code correctness, it's about design.

It is not a code bug, it is a design bug.

What did you do to help the project here?

I seems that asked a question which yielded the ascertainment of a design bug which is on millions of Wesnoth instances on every map with any era on every platform.

Did you file a bug report?

No. Do you think I should have filed a bug report on the IRC without understanding that the issue is how the engine stores orders?

Did you file a feature request?

No. It is not a feature, it is a bug.

[iceiceice]

sylph: You don't file bug reports on irc. You file them on bugs.wesnoth.org. http://wiki.wesnoth.org/ReportingBugs

And this is not a bug report. This is a feature request. This term "design bug" which you have introduced is nonsense, that's not how the programming world operates. A bug is when the program deviates from the specification intolerably. Not being able to undo steps doesn't violate the documentation, nor is it intolerable.

----------
Zookeeper:
`The only sensible interpretation for the question I can think of would be "if the last step(s) of a move do not reveal any shroud but the previous steps did, can you undo those last step(s) even if you can't undo the whole move?". Is that right? `
----------

"should" not "can"

It seems to me that undoing should revert to the last shroud update. Currently, undoing does not rewind until the change of the most recent shroud update. However, I don't know C++ or Wesnoth Engine, so I am not 100% confident that the code is not correct.

The question is clarified.

No, that doesn't clarify it for me. First of all you didn't directly answer zookeepers question, by saying "yes" or "no". And substituting should for can makes less sense there unfortunately.

Your sentence about reverting to the last shroud update... reflects the current behavior of the engine. It's just that steps themselves aren't individual events in the game, only in the animation.

I understand that you aren't familiar with the internal workings of the game, so how should you know that? Well that's why its very important to be EXTREMELY clear and even perhaps to use pictures when you want to discuss things like this -- the game looks pretty different from a C++ developer's point of view, and it is often in life hard to unsee what you have seen...

[zookeeper]

It wouldn't surprise me at all if there's no one who can tell off the top of their head how difficult it would be to fix/change it to work as you suggest, hence the lack of replies. I'm sure (almost) everyone agrees that it'd be nice if it worked that way, but there's not much else to say unless one happens to be familiar with that part of the code.

Also, if someone files a feature request or a bug report, I'd definitely suggest classifying it as a feature request, if only to avoid someone closing the bug because they don't consider it a bug. It'd be a very low-priority bug anyway, so classifying it as a feature request probably wouldn't hurt its chances of success anyway.

[Pentarctagon]

sylph, for future reference, things like this:

I am not accustom to this level of competency. Hence, Anonymissimus, based on my standards, the problem is you and devs like you. From my perspective, it seems that the most valuable contibutions you can make to the Wesnoth project is not contributing at all. It seems that it would be best for the Wesnoth community if you be banned from vital operations, including the engine.

are entirely uncalled for. If you have an issue, then address the issue without resorting to insults.

[sylph]

sylph: You don't file bug reports on irc. You file them on bugs.wesnoth.org. http://wiki.wesnoth.org/ReportingBugs

Sorry, I have never filed a bug report on Wesnoth before.

A bug is when the program deviates from the specification intolerably.

Your definition of the word "bug" is obscure. The Free Dictionary's definition of bug is, "an error or fault, as in a machine or system, esp in a computer or computer program."

Also, if someone files a feature request or a bug report, I'd definitely suggest classifying it as a feature request, if only to avoid someone closing the bug because they don't consider it a bug. It'd be a very low-priority bug anyway, so classifying it as a feature request probably wouldn't hurt its chances of success anyway.

A feature request, requesting that a bug be fixed? I don't understand.

[zookeeper]

Also, if someone files a feature request or a bug report, I'd definitely suggest classifying it as a feature request, if only to avoid someone closing the bug because they don't consider it a bug. It'd be a very low-priority bug anyway, so classifying it as a feature request probably wouldn't hurt its chances of success anyway.

A feature request, requesting that a bug be fixed? I don't understand.

I meant that it's better to classify it as a feature request because then there is no risk of time being wasted on disagreements on whether it's a bug or not.

[iceiceice]

Look, the intended behavior cannot be a bug, it's that simple. I'm not interested in discussing it further. Design flaw, perhaps, but requesting to improve the design means it is a feature request.

There are many legitimate bugs, known and unknown, in the engine, but this just isn't one of them.