I'll add it to the todo list.

引用自 Chthon：

I'll add it to the todo list.

The implementation in "More QoL Improvements" is really incomplete -- it only applies to ground vehicles, and only when one unit is selected. It wasn't hard to make it apply to all things that can move. But making it work with multiple units selected is trickier than anticipated (i.e., what I thought should work doesn't work, I don't know why it doesn't work, and the log says it *is* working, which doesn't help). I'm probably going to put this on the back burner rather than hold up the bugfix patch.

I was aware it didn't work on multiple units, but still having it work on one unit was still nifty...such as a dog or scout vehicle.

Having it work with multiple units would be very nice, of course.

But I wouldn't say this is a hugely important feature either.

Thank you for looking into it deeper.

I figured it out. Looks like WW cut Q-move loops from RA because the queue logic really doesn't work right with loops. So, the log was right -- I was successfully getting things into loop mode; things went wrong after that. So...

Step 1 is going to be fixing queue looping logic. I think I've got a rough idea what needs to be done.

Step 2 is going to be fixing the input method. Clicking a unit to activate loop mode is really, really awkward. I'm probably going to change it to Q+clicking a cell that's already in that unit's queue. That way you can just double Q+click. Not sure whether it's worth keeping "click the unit itself" as an alternate input method.

Step 3 probably should be Q-attack-move mode so you can use this for base defense.

Since #3 sounds pretty awesome in my imagination, step 4 should probably be porting all of this to TD.

Seems like I've just made a lot of work for myself...

If feasible, having some sort of waypoints in TD is probably more important than having loops in RA.

I agree that clicking the unit to make the loop is awkward.

引用自 Chthon：

Seems like I've just made a lot of work for myself...

:D

Got the new input method working. (Q+click a cell that's already in the queue.)

Mostly dejankified the loop logic. Much better now. Have a few more changes to test.

It's better to get this 100% working right in one game before trying to port to the other. Trying to do both at once leads to unnecessarily duplicated labor.

Petroglyph wanted to port Q-moves to TD, but they didn't have time. They did leave a stub function in the dll interface for the purpose of picking up [Q]'s up/down status. Assuming the GlyphX client is calling that for TD (or can be made to call it via xml), it should be relatively straightforward to get working.

Wow, excellent news. I didn't know about Petroglyph wanting to do that. This mod/patch is really coming along nicely. I don't think I could ever go back to vanilla remastered now.

I think loop logic is now 100% correct. Next step: Q-attack-move!

Nice. That attack-move has really come in handy. I didn't think I would use it much, but now I'm attack-moving all the time... and when aircraft was able to attack-move, and the mine layers was able to do it... I was sold! :D

General purpose Q-attack-move and Q-attack-move-loop are now working. I need to sort out the special cases like aircraft and dogs and whatnot, then it's time to port to TD.

Wow, amazing. You did this much faster and better than I would've even expected.
I think this will become the definitive patch-mod. :)

I think I've finally got all the bugs worked out. Please test this test build[github.com].

Brief documentation:

General:

• Attack-move now works with Q-move and Q-move-loop. Shift+Q+click to both add a cell to the nav queue and put the unit into attack-move mode.
  
• Units in Q-attack-move (or Q-attack-move-loop) can be put back into plain Q-move (or Q-move-loop) by Q+clicking (without shift) to queue another destination.

If QMOVE_LOOPS=1, then

• To put a unit into loop mode, Q+click its current destination or any cell in its nav queue. (The easiest way is to simply Q+click the same spot twice in a row.)
  
• The loop will consist of the current destination plus all queued cells.
  
• You can continue adding cells to the loop by Q+clicking. New cells will always be inserted before the original destination (regardless of where the unit is in the loop right now).
  
• You can make a loop consisting of only one destination (the current one). However, the unit will break out of loop mode upon reaching that cell if you haven't added at least one more cell by then.
  
• The nav queue has room for 10 cells. If you try to add an 11th, when QMOVE_LOOPS=1, the oldest queued cell will be evicted to make room for the new one. This applies to both regular Q-moves and Q-move-loops. (The vanilla behavior evicts the youngest cell.)
  
• Minelayers can't Q-attack-move-loop because it makes no sense with their special attack-move behavior.

If AIR_QMOVE=1, then

• Aircraft can Q-move and Q-attack-move. They can also Q-move-loop and Q-attack-move-loop if QMOVE_LOOPS=1 too.
  
• If aircraft in Q-attack-move(-loop) run out of ammo, they will head home to reload.

If AIR_QAML_RECALL=1, then

• When aircraft in Q-attack-move-loop go home to reload, they will REMEMBER their nav queue and go back to Q-attack-move-loop mode once fully reloaded. (Allows for aerial base defenders kind of like Emperor: Battle for Dune.)

Breaks save compatibility with prior versions. Sorry!

Very nice, well done! I love how you considered the aircraft as well. I might be able to do some testing this weekend.

Porting Q-move stuff to TD is going badly. It turns out that while TD has a stub function to receive the up/down status of the Q key, the GlyphX client in TD mode isn't sending that info in the first place. So I'm forced to use the keybind for "Mod Command 1" instead. Unfortunately, the way GlyphX handles "Mod Command X" doesn't quite work the way one would hope, and it leaves me with nothing but bad options for the input method.

(Since it can be anything, I'm going to refer to whatever key is bound to "Mod Command 1" as "[KEY].")

What we'd like is up/down status for [KEY] like we have for Shift, Ctrl, Alt, and Q in RA. If we had that, we could use it as a "modifier key" and do everything exactly like RA -- hold down Q, issue a bunch of Q-move orders, release Q. But GlyphX doesn't give us up/down status. All we get is one call when [KEY] is pressed.

I can think of two things that can be done with that:

Option A is to make [KEY] a replacement for Q+click. You don't click; you just put the mouse in the right place and press [KEY].
The major drawback to this is that it doesn't work for issuing orders through the radar map. (Instead you get an order issued to whatever cell is behind the radar map display.) I'm maybe 60% confident I can figure out how to distinguish when the mouse is over the radar map when [KEY] is pressed and then redirect the "click" to the corresponding location. But I'm 99% sure it's going to give the wrong visual echo, and that it's going to work wildly wrong at non-default radar zoom, and that I won't be able to fix either. I'm also concerned it may not work in LAN multiplayer or may wind up resolution-dependent.

Option B is to make [KEY] a "pre-modifier" key. Press and release [KEY], then click. [KEY]'s effect lasts until the next click or hotkey (which allows [KEY] to cancel itself), or until some arbitrary number of ticks have elapsed. I think I can make this work perfectly as described. The problem is that "press, release, click" is pretty meddlesome. [Edit: On further thought, you could also do "press & hold, click, release," which would be less annoying and closer to RA's behavior. You'd just have to remember to release and re-press between every order.]

Thoughts, anyone?