Feature Requests & Ideas

• 

  Guidelines and Feature Request List
  • redrum

  3
  3
  Posts
  182
  Views

  

  ill start a few at a time
  zoom in yes

  idle timer yes

  fix the lag caused by new joiners yes

  three is enough for now

• 

  Remaining Requests from Hepster
  • Hepps

  5
  5
  Posts
  92
  Views

  

  @frostion Yah that is the idea. In my example the BB would actually change twice...

  Unit starts as a BB

  Turns into BBdamaged

  Then turns into BBhvydamaged

  This idea could be used in other ways as well for something like a production facilities which could have far more hit points... like 16 HP changes to a lower producing version with 8 or more damage.

• S

  This topic is deleted!
  • slitherioo

  3
  3
  Posts
  47
  Views
• 

  Unit Option Which Suicides Only When It Registers A Hit (Mines)
  • Hepps

  12
  12
  Posts
  117
  Views

  

  @prastle Don't see how those would help in this situation. That is definitely good as a solution for a bombard capability and is a feature already included in GD in various ways. Explain to me how you would alter its behavior in an XML to perform as a mine?

• 

  Visualization for Bombing runs
  • Hepps

  15
  15
  Posts
  216
  Views

  

  @cernel @Hepps Changes should be in the pre-release now. It would be nice to group units that are the same and have the same damage but that would require significant work. A scroll bar should pop up if you have more than about 10. I took a look at showing max damage as well but unfortunately it would take a decent amount of work to add.

• 

  UnitAttachment Which Allows/Requires Another Unit To Move
  • redrum

  58
  58
  Posts
  913
  Views

  C

  @hepps I saw that, due to the purchase limits of the old Fodder AI", with the triggers bringing back the stuff, when it is going to be assigned to the players. But this is another matter yet. As I said, the two "requiresUnits" here are just useless. You could remove them both, and nothing would change, for those units. As I said, this is really a marginal matter, we/you can solve any ways you prefer (most likely, what is wanted is removing the first occurrence only), doesn't really matter and it's no problem; it was really not the focus of my post.
  As a matter of my proposal, if you want just to keep it as it is, the change would be this one (but this would equal not having it):
  <option name="requiresUnits" value="spanishEntrenchment:spanishCombatEngineer" count="1"/>

• 

  Diplomacy Extensions
  • RoiEX

  10
  10
  Posts
  197
  Views

  

  @cernel I agree we should increase the major version number, but for a different reason:
  The work and infrastructure changes that are required for such a change would be massive, that's why the version would be completely incompatible.

• 

  Land Transport Improvements
  • redrum

  20
  20
  Posts
  662
  Views

  

  @redrum So if you are working on this... while also trying to keep the same functionality....

  Are you at the same time trying to find a way to create a method of specifying which units can transport which units?

  IE. Let's say you have a train (don't know why I might choose that as an example) ;) and the train is capable of transporting; tanks, Infantry, trucks, artillery, .... But you also have a truck which can potentially only transport Infantry and artillery.

  Will there be a way to specify which type of transport can carry which type of unit?

  I am thinking something like this...

  <attachment name="unitattachment" attatchTo="Truck" javaClass="games.strategy.triplea.attachments.UnitAttachment" type="unitType">
  <option name="movement" value="2"/>
  <option name="attack" value="0"/>
  <option name="defense" value="0"/>
  <option name="canBeDamaged" value="true"/>
  <option name="maxDamage" value="1"/>
  <option name="canDieFromReachingMaxDamage" value="true"/>
  <option name="isLandTransport" value="true"/>
  <option name="isLandTransportfor" value="Infantry:Material:Artillery:AAgun"/>
  <option name="TransportCapacity" value="2"/>
  <option name="transportCost" value="2"/>
  <option name="isInfrastructure" value="true"/>
  <option name="requiresUnits" value="germanFactory"/>
  <option name="requiresUnits" value="russianFactory"/>
  <option name="requiresUnits" value="japaneseFactory"/>
  <option name="requiresUnits" value="chineseFactory"/>
  <option name="requiresUnits" value="britishFactory"/>
  <option name="requiresUnits" value="italianFactory"/>
  <option name="requiresUnits" value="americanFactory"/>
  <option name="requiresUnits" value="spanishFactory"/>
  <option name="requiresUnits" value="swedishFactory"/>
  <option name="requiresUnits" value="turkishFactory"/>
  <option name="requiresUnits" value="brazilianFactory"/>
  <option name="isAAmovement" value="true"/>
  </attachment>

  I'm not great at what makes for good coding.... I am just going off of some of the stuff that is already in current XML's.

• 

  Improve the default casualty selection of the last combat round
  • Frostion

  2
  2
  Posts
  46
  Views

  

  @frostion Yeah, this has come up before and is probably a good idea. I think the AI actually already does this (you might want to test that out) so it would probably be pretty easy to add the same logic to default selection provided to the player.

• L

  Open website confirmation message - should we keep it, or just open the browser window?
  • LaFayette

  3
  3
  Posts
  62
  Views

  

  Yes keep it.

• 

  Remove Space Bar for casualties confirmation
  • prastle

  20
  20
  Posts
  402
  Views

  L

  @cernel said in Remove Space Bar for casualties confirmation:

  If that doesn't happen for you, it has to be either a bug or something is not clear about that option's description.

  Well, I posted the screenshot of the setting and tried the alternative. The two variables I can think of are:

  OS, I'm running Ubuntu 16 Look and feel, currently set to system default instead of substance.

  I'll need to check if either of those two are the reason. Thank you for confirming that @Cernel and @prastle

  For combat, you need to hit space bar twice for a mis-confirmation, and politics once. I would suggest it's a majority use case where two players are spamming space bar to get through a combat phase rather than either one chatting. If you play multplayer games instead of 1v1, you may have a different experience, but looking at lobby games at any time less than 25% to less than 10% of games are more than 2 players.

  So, we need to be sure:

  we keep combat fast, players need to be able to confirm casualties with keyboard shortcuts quickly. We need to keep in mind that space bar is an OS default to activate the currently selected control. Getting the UX correct here may be tricky. we need to keep in mind there are cases where players are chatting, single click confirmations are effectively broken, double space bar confirmations not as bad but still can lead to accidental confirmations.

  Summarizing that, I cut a tracking ticket so we don't forget this: https://github.com/triplea-game/triplea/issues/2293

  Please add any 'requirements' to the list if any are missing, the problem at least is well defined, the task I documented is mainly to investigate possible fixes and to propose something that fits the listed requirements.

  DanVanAtta created this issue in triplea-game/triplea open Fix accidental Space bar confirmation (problem while typing, eg: chatting) #2293
• 

  Drop old jar functionality
  • RoiEX

  20
  20
  Posts
  285
  Views

  L

  But as long as it is possibe to always install a legacy version, there should be no need to keep old jars with the latest release and pre-releases

  @panther I think that is a very good point. Our new website, installer, and that we print the engine version in the game UI makes this all a lot easier compared to the SVN days.

  will the next major release affect all the maps the same as the last one?

  Likely not. We're in a better position to avoid a number of those problems now. We can still and always could introduce non-backward compatible XML changes. The last iteration required a re-download since we unbundled every map with from the game engine and we re-hosted. We took that opportunity to add in some non-backward compatible changes since all the maps needed to be updated anyways.

  I think soon we will introduce an XML schema versioning system directly into the XML . That would allow us to start upadting XMLs in non-backwards compatible ways, but still play 'old' map XMLs that had not been updated. Today the game engine and XML code need to stay in pretty much lock step, doing that we could let the game engine code move forward but still 'remember' how to parse the old XML spec.

  @RoiEX I would check on the live lobby a few times to get more player input on this one. I think the question at the moment is whether everyone agrees with

  "But as long as it is possibe to always install a legacy version, there should be no need to keep old jars with the latest release and pre-releases"

• 

  TUV for Units That Have consumesUnits Property
  • redrum

  30
  30
  Posts
  809
  Views

  C

  @redrum Actually, I don't think so. Usually, complex tech maps unlock units. It is more a thing for small/simple maps to have silly technologies like that in the moment you get JetPower all your Fighters magically turn into JetFighters. A more advanced map would probably, instead, unlock an additional JetFighter unit. So, I think the unit upgrade, meaning a same unit that becomes better thanks to tech, I believe it is relevant for simple maps not less than more complex ones.

  But, what I was saying, the matter is that the thing should better be consistent.

  If you decide that TUV should represent the value, then the TUV should stay the same when you get Shipyard and should increase when you get SuperSub (it would be up to the mapmaker to assingn a referring value, there).

  If you decide that the TUV should represent the cost, the TUV should decrease when you get Shipyard and should stay the same when you get SuperSubs.

  So far, the second has been true, as the TUV, up until now, has never been anything related to any kind of value, but just the picture of the total current costs (thus TUC would have been a better name for it), as Veqryn confirmed when he said that he is perfectly fine with your TUV sinking in the moment in which you get Shipyards (I agree that is kinda silly).

• N

  Version for Raspberry Pi
  raspberrypi new version triplea raspbian • • Nedhudir Falasren

  5
  5
  Posts
  121
  Views

  

  Now I'm inclined to blow the dust of my raspberry and try it myself ^^

• 

  Forum Recent Active Topics Widget
  • prastle

  1
  1
  Posts
  50
  Views

  No one has replied

• 

  Handling of AI players not meant to be played - Github request.
  • Frostion

  37
  37
  Posts
  1497
  Views

  

  @Frostion Hoping to release in the next week. We are going through some testing and fixing a few bugs that were found. You should be able to make a PR in github or make the changes local and not upload them then wait til its released.

• L

  Ideas for a 'show combat' button?
  • LaFayette

  15
  15
  Posts
  264
  Views

  C

  @LaFayette said in Ideas for a 'show combat' button?:

  @redrum Always on-top could be an option, yes. IIRC there was an issue where multiple always on top windows competed, so long as that is not the case that is a good alternative.

  It was me that reported that issue relatively to the "Game Notes" window. The case is different here, and I suggest having the on top and, then, see if it causes any issues or not. I think that if the window closes automatically when the battle is over, then there should be no issues at all for sure.

  But, we also should consider the spectator case, an always on top combat window would be really annoying, so some conditional logic would seem called for to always on-top only if you are involved in the battle.

  As long as you can still click to minimise the window, I believe that is not a problem. Anyways, if it is feasible, I agree to limit the always on top for the two referring players of the battle only, of course.

• D

  Moderate luck option?
  • David_VanDyke

  61
  61
  Posts
  2452
  Views

  

  @David_VanDyke I don't believe anyone is currently working on it but I think we have a general consensus on the 2 main ways to implement it from this post: https://forums.triplea-game.org/topic/212/moderate-luck-option/20

  Its hard to say if/when someone will pick it up to work on it but it is on the unprioritized feature list: https://forums.triplea-game.org/topic/182/guidelines-and-feature-request-list

  I'm currently working on: https://forums.triplea-game.org/topic/159/tuv-for-units-that-have-consumesunits-property

  I may eventually make a poll for folks to vote on feature requests they'd like to see prioritized.

• L

  Drop: Substance UI "Look and Feel"?
  • LaFayette

  36
  36
  Posts
  839
  Views

  

  @LaFayette You can customize the color scheme of any L&F and making nimbus darker is described here:

  https://stackoverflow.com/questions/36128291/how-to-make-a-swing-application-have-dark-nimbus-theme-netbeans https://docs.oracle.com/javase/tutorial/uiswing/lookandfeel/color.html
• C

  Missing Image Crashes
  • CrazyG

  7
  7
  Posts
  138
  Views

  C

  @Cernel
  Bingo. I got an error when viewing the history, the top line was about the image not being available, but what actually caused the error is something else