TripleA Needs your help!

We need help finding any remaining problems in the 2.0 beta. We'd like to release 2.0 imminently, we've almost all major bugs fixed. We're at a bottleneck where we don't have enough labor to test everything to get this release out. Your support of time and effort is really appreciated here and will help get 2.0 launched sooner.

We're inviting everyone to be an early release beta tester. We're asking you to:

• download the latest TripleA
• test anything/everything, all menus, all game play configurations, all rules, play a game through
• report any problems that you might find

Instructions

• Download the latest TripleA prerelease here: https://github.com/triplea-game/triplea/releases

• Run the installer, install to a folder named somethign like "TripleA-{Version}" or similar so you don't overwrite your existing TripleA installation.

• Launch the game, click on anything/everything, test everything!

• Report any problems that you see, new or existing: https://github.com/triplea-game/triplea/issues/new

Word of Caution

Since you are testing a beta, there could be stability issues, you might see crashes or other issues. We really want any of these to be reported so we may properly fix them.

Good luck and thank you to all those that step up to help.

We want TripleA to grow, to gain new features, game-play be easier, faster, maps more interesting and everything prettier.

So, how can you help?

• create bug requests directly into the bug tracker after a problem has been identified in any forum thread
• avoid having a dev do anything you can do yourself
• do not PM dev's asking for something to be done, instead create a bug tracker item

Background:

I would like to address and point out the scaling problem TripleA has. As TripleA has grown from a small project, where one person could handle the code, another could handle communication and submitting bug reports, as the volume of people and traffic has grown, this no longer works

Development is one of the slowest things to happen for TripleA. Most interesting features take perhaps anywhere from 10 - 50 hours of work. The way I see it, those that can code, we want them to spend time coding, not doing general communication on forums, not finding bug reports on forums and transferring them to bug tracking, not managing maps, and generally not doing anything that could not be done otherwise by the community.

The trick I think for scaling is we need to be sure that we update any process so that a team of people can handle the item rather than just an individual. If for example "Joe" handles all maps, then when the amount of map stuff is too much for "Joe", we'll see a backlog. If "Joe" goes on vacation, everything stops, and if Joe gets tired of spending 20 hours a week on maps and backs away, then everything grinds to a halt. Worse yet, if Joe leaves, all the know-how Joe had in his head leaves too, and suddenly not only is there nobody to manage maps, but nobody even knows how to manage maps.

Teams solve this, if all map items go to a queue, and a team works on the queue, people can take vacations, people can rotate in and out. The team has incentive to document how the team operates so that new team members can join and become effective and everything doesn't stop when one person leaves.

Without a team handling items, when it is individuals, we do not scale.

We see this problem mostly in bug reports and change requests in forums. If we rely on individual developers to read, distill and create bug reports, then we have a bottleneck and an individual responsible for a process. If that individual stops creating bug reports from problems reported in forums, then we won't get any new items in the bug queue. Notice, the bug queue is a process that goes to a team, all developers work on it. We could easily have the one developer not create a bug report and fix the problem, but then we are into the "silo" problem to an extreme.

We have a lot of map controls, unit size, search territory, unit highlight, map zoom, that are buried behind magic keys or various view menus. These are difficult to find and easily adjust.

I'm opening this thread to discuss options. Some were discussed in context of unit flags and movable unit highlight in this thread: https://forums.triplea-game.org/topic/1524/toggle-flags-and-toggle-highlight-movable-units-updates/30

Needed are good ideas of where we can place the various items and what kind of UI treatment we can provide.

So we need:
(a) a survey of the various settings and features that are better pulled out from the menus and placed behind a UI control
(b) a mock-up and ideas of how/where everything can be placed and what kinds of UI controls would be good for containing those elements.

Background: TripleA QA team has been operating for some time:
https://forums.triplea-game.org/topic/268/volunteers-needed-early-release-testing-group

We have coordinated mostly via gitter channel: https://gitter.im/triplea-game/QA

We coordinate testing via a pretty simple google spreadsheet:
https://docs.google.com/spreadsheets/d/1CSZ4s7wBLcvgue_IHwl-CbjQd95qj8hhR8m89ngCzbU/edit#gid=0

When there are multiple green bars lining up, meaning multiple people have reasonably checked as much of the game as they can, that version of the game can become the latest release.

Opening a dedicated thread to discuss these ideas.

From: https://forums.triplea-game.org/post/29462
@Hepps created this mockup:

I like the idea of action buttons, but I don't think we'll be able to agree just yet which ones should be on the game screen and which ones accessible in menus.

Let's focus here then on the minimap. Moving the tabs and map to bottom probably won't be that difficult. The translucent background might take a bit more work, but could be possible. It probably would make sense to make that a setting so that users can control translucent vs not.

Please add in any extra 2 cents, or thoughts on this topic.

Why the QA team?

The QA team is essentially a way to coordinate multiple people to test the software before it is released. The team was created in response to a number of problems.

• Development team had trouble tracking results and general confusion on "is it safe to release?". With a defined policy and tracking, we can now look at the testing results and know when a specific version has been confirmed to be okay for release.
• the TripleA code base is very difficult to modify and repeated releases kept introducing small but extremely significant bugs. Regression testing for any of these is a huge effort, and needs to be done repeatedly as the code base is constantly modified. It's too large of a task for just one or two developers, hence the QA team.

How will we know if the QA team is successful?

• The number of major bugs reported by users to github issues will go down and head towards zero
• The number of times a release is 'rolled back' will go down and head to zero

Where is the QA team heading?

• Still formalizing how we operate, but we're getting pretty close to a stable operating process
• Long term try to work with development team to reduce the number of items being hand tested
• Short/medium term, formalize testing a bit, a few things are getting through, perhaps a testing check list of all features and cases that need to be checked would be a good start

We'll be getting a spotlight from the Legendary Games podcast in the coming weeks/months.

In the meantime they've done an interview with Larry Harris that would be of interest to everyone here (and will be interviewing David Jensen of 'A&A.org' soon too!)

The Larry Harris interview is available at:

• itunes
• google podcasts
• spotify

Wargaming is a niche, it's not for everyone, but there are people like you and me who love it - and for these people I make my games. "
- Larry Harris

The game notes are a bit awkward to have in the game XML in a massive CDATA block. Having them be in their own file perhaps could make it a lot easier. Particularly since one could open the file in a web browser and be able to see how the HTML would render.

Any thoughts about this?

I think the only challenge would be solving how we can associate a game-notes file with the corresponding XML.

You can now download 2.0 from the triplea-game.org website

Changes are listed on the release notes

Just a heads up, it looks like there is opportunity to drop assets distributed with the game engine. I'll be focusing mostly on removing sound files that are only used by a few maps and will instead move those assets to the map itself.

I'll post a zip of the assets before removed and will add a list here of the files removed & moved to specific maps. The net result is that the images/sounds distributed with the game will be a bit fewer and will need to be included by maps specifically if they would want to use them.

Ah, just saw the responses : )
The variable route would work, you are still duplicating the territory names, but at least it's more concise.

@Jason-Green-Lowe not currently

There is a proposal on the table to consolidate territory attachments into the territory tag itself. Adding a blockade zone attribute would be a natural move and is part of that discussion: https://forums.triplea-game.org/topic/2266/proposal-combine-tags-into-territory

To turn all territories by default to blockadeZone would require something else though. I think then we're talking about a way to perhaps set custom defaults. Something like:

<territoryDefaults>
  <production value="0" />  <!-- already default, just for example -->
  <isWater value = "true" /> <!-- example by default today this is false -->
  <blockadeZone value="true" />
</territoryDefaults>

But even then, you'd have to turn off blockade zone for land territories, so that implies that there should be a difference between water and land territories. Namely that the two should be physically separate tags because their attributes are different.

We'll be getting a spotlight from the Legendary Games podcast in the coming weeks/months.

In the meantime they've done an interview with Larry Harris that would be of interest to everyone here (and will be interviewing David Jensen of 'A&A.org' soon too!)

The Larry Harris interview is available at:

• itunes
• google podcasts
• spotify

Wargaming is a niche, it's not for everyone, but there are people like you and me who love it - and for these people I make my games. "
- Larry Harris

There were a few reasons to bring in 1.8 compatibility:

• we are getting about one error report a week for players launching 1.8 maps. The 1.8 maps keep coming up:

  • https://github.com/triplea-game/triplea/issues/7132
  • https://forums.triplea-game.org/topic/2234/need-help-to-convert-an-old-game?_=1600642324318

• we should never have assumed that we can upgrade all maps in bulk, we do not 'own' all maps. Not all maps are in the repositories

• it's been a long running design principle that maps should never be broken. The mechanisms to support this had some big problems and we dropped it in 1.9 as it was not scaling and really just was not cutting it.

As mentioned, 2.3 has a new map parsing architecture that makes supporting 1.8 maps much easier. Adding in that support resolves the above problems and gives us a proving ground for being able to support more XML variations going forward.

As a bonus, now that the map export is fixed, because players can launch 1.8 maps, if they want to upgrade them, they only need to now launch the map and can then re-export the XML.

tripleabuilderbot created this issue in triplea-game/triplea

closed 2.1.20365: GameParser#parseMapProperties - SAXParseException: game: Test1, line: 190, column: 26, error: Element type "attatchmentLis... #7132

@Panther the files in source forge was the source for the migration into github. Source forge is the old download location, they've been obsolete for some years now. Afaik they nearly all exist in github, the maps in github are updated. The github maps have histories, you can check the commit list even to see the updates.

"1.8" maps refers to maps that have things like "attatchment" in them. When we upgraded Triplea from 1.8 to 1.9 we also bulk moved all maps from zip files in source forge to github repositories. After doing that we then updated the XML of those files as well to fix things like the 'attatchment' spelling, but the maps in source forge were left unaltered. If you download a map from source forge (a 1.8 map), it'll crash in 1.9 through 2.2

Does that clear things up?

With all of the above being said, now that 1.8 maps are supported again, help is needed to ensure that we have all of the legacy 1.8 rules correctly ported in the code and that we're not missing anything.

@RogerCooper The way the XML export was being done was not sustainable. In combination we were getting a decent number of bug reports of players playing 1.8 maps that were crashing on them and there is a desire to expand and simplify the XML structure. With all that being the case, in 2.3 we have redesigned the architecture of how map XML parsing is done.

The new design introduces an intermediate step into the parsing that allows us to more easily create XML tag aliases and is bi-directional so we can read and write XML data from a single data structure. This was certainly in part inspired by the bug report you submitted: https://github.com/triplea-game/triplea/issues/7480. A surgical fix there would not be worth that much as it's unlikely for it to remain correct, hence a deeper fix where the system can just export data natively from the intermediate format that is used to also read data. This will help ensure that the read and write paths of XML stay in sync since the data structure is now unified, it is bi-directional.

With all that being said, the export functionality will hopefully be expanded, but in the meantime we now have the capability to instead of saying "1.8 maps do now work", they can now work.

There is some history behind this as previously there was a somewhat broken strategy for all maps to always work. Essentially the game bundled all previous versions of the game in itself and would launch old game versions. This was a bit of a broken strategy as there is not enough information to always know exactly which version to launch, and beyond that there were other issues. As of 1.9 we dropped this as that functionality had some major breakages where the fix really was beyond the capabilities of that design (so we dropped it and decided to do a hard-cutover of maps). Now as of 2.3, we can support changes and differences in the XML natively and with far less intrusion. The two layer approach allows for the lowest XML layer to deal with tags that might be spelled differently and unify this for the next layer. This means changes to at least the XML spelling is isolated to one layer that now has automatic testing. This implies we can make changes there, they are now isolated and no longer require manual regression testing where we verify that hundreds of maps still can be loaded, that is done automatically now. Furthermore, this opened a door for bi-directionality where no only can we read from this layer, but we can write to it as well.

RogerCooper created this issue in triplea-game/triplea

closed Export game.xml creates flawed code #7480

That IllegalArg is likely the bot trying to connect to lobby. Do you know which URI you have configured for the lobby?

The arg for lobby URI should be something like "triplea.lobby.uri" with value "https://prod2-lobby.triplea-game.org"

@Mathias-Sven note the port already in use error. The bot should have terminated in this case but kept running in a zombie state. Try killing all have instances and then try again