The feature would have put a left/right arrow on the screen with a count of how many unused units there were. Hotkeys would have been mapped to these, and hitting space bar would proceed to the next one. So you could scroll through all units and then 'skip' a unit you do not want to move.

There was a bug with the hotkey system where the main window would lose the listener and the hotkeys would stop working until the map was clicked. That delayed/broke the feature, so I've some old code in a branch hanging out for this but it'll take some time to revive that and to fix the hotkey problem (which was our oldest open bug tracked in github).

Other TripleA priorities are more pressing, I don't rightly know when I'll get back to this, but I would like to.

Good news and a bit of a conversation pivot. How bug reports make it into the tracker will soon be a problem for just admin/dev.

We're introducing an http server to the mix and that let's us build a few things pretty quickly. The first feature to make use of this is a 'error report' feature for the client that is in progress.: https://github.com/triplea-game/triplea/projects/4

The original idea was to upload stack traces to the server, with a little bit more we can add a text field on to it to get a free-form input so we can submit bug reports directly from in the game. Hence, it'll be up to dev/admin how the reports are processed after they are entered, they will in a DB and we could potentially do things like automatically create bug tracker tickets when new items show up.

A logical add-on to this would be to add the capability to capture and upload a save-game while uploading the error-report. The http-server/client components are looking far enough along that we can potentially start thinking about how that process would look.

Why those next steps?

Well, how should this get fixed? We need something, concretely how to instruct the computer what to do.

If we update the help menu to have a forum link for reporting bugs, then that will be where bugs go. Sadly, this is not bug tracking software and issues are going to get lost/missed (recall when map updates were driven by forums, I counted that a good percentage were just dropped and never actioned, that was largely in part that forums track active conversations, they are not designed for priority and task tracking).

So the answer seems to be to have the help links be the single "submit a new bug report" link that we once had. I'm wondering how to work in "see the forums if you are unsure of what to do and if you are not sure this is a bug", but that confuses everything and gets back to the problem that eventaully we will not move everything to bug tracking and that will cause items to be lost (and if lost, then reporting here is just not going to be as successful as it could be).

This is for sure an open conversation, I can be pursuaded, but my current thinking is:

• it will not be successful to do task tracking in forums, we need a bug tracker for it.
• we can route tickets through forum if we have a real and sustainable and formal process to move those tickets into bug tracking
• over the long run, even short term, getting such a formalized definition and sustaining it for the life of the project (hopefully a few more decades at least) will eventually fail
• splitting the instructions to route things to forums makes those instructions more difficult to follow and maintain, it adds to the confusion and the 'trust no documentation' because we have 5 copies of it all and all are slightly out of date

I think that leaves trying to make our bug tracking queue very obvious and the one place where we do that kind of reporting /tracking. Just not necessarily seeing how we can solve it otherwise without running into additional problems (and thinking historically to how tracking failed with the SVN bug tracking, and noting how things ran when we had no active forum and only github issues; things work better when there is process clarity and transparency)

@cernel Thanks for tracing that through, hard not to chuckle at the absurdity.

The bug report link had the virtue it was simple. The above flow is broken, I don't think we solve that by creating a 'bug reports' section on forum though as it implies this is the place for bug reports and that becomes confusing. A formalized process of moving bug reports from one place to another I do not think will be sustained over the long-term (in the short it does not seem to be working, I note a number of bugs that are being 100% worked on here, and did not get proper tracking visibility).

If we really want to unify logins we can have forums to use github API for login, then that could be the one login for every TripleA system. There are some real benefits to that as we have less custom code to maintain and that would reduce our engineering costs.

So I think the bottom line is having a 'bug reports' forum section here is well-intended, but fundamentally confusing as this is not our flow/process for reporting and tracking bugs. Merging this category with 'help' section and fixing the bug reporting flow so it takes a person to the right place the first time would be good next steps.

@rogercooper said in Terms: Nation - Resolved -:

As there is really no perfect term, we might as well leave it as "player".

To one extent I disagree, as "player" is the name for something else, eg: Bob and Jill are playing a game, Bob is playing as the allies and Jill is playing as the axis. We then have "player" meaning two different things on which context.

But... the code is pretty consistent about using "player" to mean playable nation/faction/power. Multiplayer came along later, which is when/where 'player' comes in with the more common understanding to mean the people playing the game (the players), as opposed to the roles they are playing. That's why the code got the terminology wrong, in a single player game, the players are "US" "UK" etc... in a multiplayer game the other/more common meaning comes into conflict. TripleA does not label the alliances to the user anywhere, so we've managed to get away with not needing a decided external name for this concept. That means internally to the code (and map XML) player will retain a pretty well defined meaning, and what is called a "Node" will always be a bit misnamed/weird.