Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
New REMOVE_RANGE command for range removal #2156
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
New REMOVE_RANGE command for range removal #2156
Changes from 21 commits
3fd7f54
03f9ced
019acf6
4d90e61
3c4156c
9fa89e6
a747e8c
82762a3
5dfa83a
133a210
14a3367
d5eeae2
bc5b37c
c855fcd
cc376a3
2046214
ebf7633
da2e251
b1a84c0
6d1a259
818726d
286ec98
d6b052f
b2f405f
72aaf17
9fa74af
07d06f7
9cc92ba
084737b
8786b35
e3a93a8
0b1943a
2e1e979
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If you skip this event on purpose so that "invalid" orders are dropped silently then that's also fine, but if that is the case then I would still want the case where
firstIndex >= queue.size()
to be considered valid. This is because you can use theremove(5, math.huge)
idiom to cull the queue to 5 orders regardless of how many there are in the queue at the moment, and it's still a "success" if there was nothing to do.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, unsure what to do there... could maybe run it only in that case, or either maybe run the callin in all return early cases but that'd be a bit cumbersome. Even if considered "valid", since it doesn't do anything, do you really think it needs the UnitCmdDone callin there? Not sure it's really needed if nothing really happened, unless we want to send it unconditionally so the sender can always do smth after this is resolved one way or another...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would prefer if it produced an event because it feels arbitrary that a valid command would just silently disappear with no trace if it just so happened its conditions were already fulfilled. Perhaps check what happens if you give a move command onto the unit's current position, or a "set firestate to holdfire" command if it's already holdfire etc. (I don't know what happens but I would assume they both produce an event), and then make remove behave consistently with that.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Tricky since state commands never send any CmdDone, and move probably always sends since it wouldn't consider same position as a fail condition.
Maybe ATTACK is a good example, it does send CmdDone through FinishCommand when returning early because of any bad parameters.
On the other hand, INSERT and REMOVE didn't generally send any callins, there could be some cases where queue manipulation led to other commands ending and sending CmdDone themselves.
Anyways I'm leaning more towards adding CmdDone in all early returns too, just to be generally consistent inside CMD_REMOVE, like attack does. I think not having something here was probably a problem/bug, and regarding INSERT.
Will have to check how lua finds out about the queue changing, but there doesn't seem to be a good mechanism for the general case. I guess it finds out because it knows the command is about to be given, but not because the command was already processed.