• RFC: merging skins with maps

    17
    2 Votes
    17 Posts
    2k Views
    C
    @LaFayette The alternative skin for 270BC is an example of changing also the units. There may be others. Here you can find a map-skin for RSoC that is actually about making the map bigger: https://github.com/Cernelius/red_sun_over_china-big_skin The current map-skin feature allows changing everything in the skin, and that is good. What is not very good is that it obliges you changing everything, so forcing duplication if you don't actually want to change everything. It is true that most map-skins are only about changing the map details, but I think this is beside the point (Of course, some things are more used or useful than others.).
  • TripleA Rules Sets

    15
    1 Votes
    15 Posts
    3k Views
    LaFayetteL
    @LaFayette said in TripleA Rules Sets: What would be ideal is to have a table describing different behaviors by rule set. We are actually on our way there. We have example maps that follow each rule set, all we need to do is to start teasing apart the behaviors that are different and then answer for each map, "does this follow that behavior, yes or no?" If we find that some rule sets are only very slightly different, simpler is better. The 'v3' moniker will be difficult to drop, if we can keep it simple and say "old edition", "revised edition" and "new edition", it could be easier to adopt. At this point though, without knowing what the rule sets actually are, it seems to be a first priority to know which rules are in each rule set before we do much of anything else.
  • Storing Maps as Folders only rather than as either Zip or Folder

    10
    4 Votes
    10 Posts
    2k Views
    djabwanaD
    @Cernel As we unzip a file, we will be doing a lot of checks (are all the required folders there? is there a centers.txt, etc.?) and as part of that process, we could enforce a casing convention. I have a tool that fixes capitalization. When I got image assets from @GenerationKILL sometimes the casing was a bit off, so I would just run this tool and it would conform every unit to a convention like this: Unit-Name.png regardless of the OS and regardless of the original naming. We could implement a similar normalization process at the map parsing level (though it might be hard to get map makers on the same page about which casing convention should be used). https://github.com/jdimeo/triplea-map-tools/blob/master/src/main/java/jdimeo/triplea/util/FixFileNames.java
  • GameData.acquireReadLock usage?

    3
    0 Votes
    3 Posts
    861 Views
    T
    So, would you be ok with removing some locks if it can be shown that the data is actually read only? I'm currently looking at ResourceList which is what GameData#getResourceList returns. The class has only one setter and it is only called during the game parse process and a test method. The data that ResourceList stores is a map of Strings and Resources. And Resource is a value object. ResourceList doesn't appear to need any sort of read lock since I don't see any way for it to change. If I see locks around GameData#getResourceList, can I just remove them? Would you like me to tag Resource and ResourceList somehow (such as @Value) to indicate that they are read-only objects?
  • Replace Console Logging with a File

    25
    2 Votes
    25 Posts
    4k Views
    TheDogT
    @LaFayette Dont forget to add triplea.log to the list of files to uninstall.
  • Questions from a know-nothing beginning programmer/developer

    8
    0 Votes
    8 Posts
    2k Views
    LaFayetteL
    That said, is there a particular reason (other than a chunk of code not really necessary to functionality) that save game files don't work that way? Java serialization was once popular, it was an initial design decision to use it, it was somewhat easy. We would actually like for save games to work more like you have described. It's a very large project, that is all, and we have a large backlog of small and large projects that we are working on and collectively there is not that much development labor available. Re: performance requirements These are the wrong things to focus on. First focus on functionality, what are you going to built? What value will it provide, how will it be used? You need a good product for anything else to matter. Then I'd encourage to stop worrying about specs. Simple and well done architectures are fast and perform well. Simple code is usually fast code. Once you have a reasonable design in place and functioning, then you can start analyzing where the performance bottlenecks are and where to go to optimize. It's a ways to get to that point, and once you are there the process is to measure, change, repeat. Humans have generally very bad intuitions for where performance problems will arise. It's also easy to try and fix all performance problems as optimization problems when they are really design problems. One can look at a block of code and wonder "how can I make this faster", and sometimes the right answer is, "how can I avoid needing to execute this in the first place?" That is why keeping things simple and working is very important, it lets you reason about what your code is doing. For example TripleA does a lot of calculations twice, why? Because there are 15 layers of call indirection separating the two which creates several thousands of lines of code in between the duplication. Bottom line OUr time is short in just about every way imaginable. I'm pretty sure and somewhat regrettfully going to say, if you want something that interoperates with TripleA, it's potentially one of and likely all of: untractable and/or a truly huge project We have wanted to for example to allow TripleA to run on web browsers, or phones. That project is probably 3-8 years away from being completed if it were started today.
  • Combine casualty selection dialogs?

    2
    2
    1 Votes
    2 Posts
    897 Views
    TheDogT
    Its a good idea, I like it.
  • AA Auto Casualty documentation?

    1
    1 Votes
    1 Posts
    752 Views
    No one has replied
  • AA and targets with multiple hit points, how many dice?

    8
    0 Votes
    8 Posts
    2k Views
    LaFayetteL
    I think you may have to look at which maps have the combination of properties set to see how it is used. I can imagine a few different variations of how such behavior would be used. Generally, if the intent were to be able to shoot down a multi-hit-point air unit, it would make more sense to me for the AA to do more than 1 damage.
  • When should support be allocated?

    10
    0 Votes
    10 Posts
    1k Views
    LaFayetteL
    Sounds right, though I think this is a simpler way to think about it: before a unit rolls, it looks to see if there is an available support, if so, it consumes that support.
  • Why does all aa attack values must divide into attackAAmaxDieSides?

    5
    0 Votes
    5 Posts
    880 Views
    T
    @alkexr , thanks for those forum posts. It does look like this warning is no longer valid.
  • 2 Votes
    6 Posts
    2k Views
    N
    @LaFayette said in I would like to start helping out with tripleadevelopment but don't know where to start: Are you familiar with doing feature branches in git? Were you able to compile and run the game from scratch? No to both of those. I guess I need help.
  • Implementing UI Visual

    Moved
    32
    1 Votes
    32 Posts
    9k Views
    MirkoBrunerM
    @RoiEX I have read your specs, Issue seems to be closed at least for now. How do we proceed from that? Any Idea? I have already my questions about your navigations and other annotations. Regards @RoiEX .
  • PR help

    14
    1 Votes
    14 Posts
    2k Views
    LaFayetteL
    There are three ways to merge branches: merge fast forward merge rebase git merge <remote> <branch> and git pull <remote>/<branch> AFAIK are the same thing and are both merges. git pull --rebase <remote> <branch> is a proper rebase. This is the one you should prefer to avoid having 'merge commits'. A fast forward merge is really similar to a rebase, and you do that with a -ff flag to merge, ie: git merge -ff <remote> <branch> There is also a proper 'rebase' that can be done. AFAIK these two are the same: git pull --rebase <remote> <branch> and git rebase <remote> <branch> Unfortunately it is fundamentally a bit confusing as it depends on exactly how the rebase is done and with which flags. This is a place where a GUI can get in the way.
  • Development setup

    27
    0 Votes
    27 Posts
    7k Views
    F
    @Trevan I am glad you know your way around! I never would have found that.
  • Is there a flowchart or similar for the AIs?

    7
    0 Votes
    7 Posts
    1k Views
    aardvarkpepperA
    @TheDog Thanks. Quite handy.
  • Factory/Town building in version TripleA v2.3+

    7
    1 Votes
    7 Posts
    1k Views
    TheDogT
    Awh shucks (looks down & shuffles feet)
  • First stab at 2.0 AI

    2
    2 Votes
    2 Posts
    727 Views
    ubernautU
    @redrum so here's stab #3 AI got moscow again in stab #2. this is v3 btw figuring that the most advanced version of the game that AI can play effectively. playing as allies with no bid maybe i should started as axis but i wanted to see the AI's initiative and figured giving some kind of handicap to AI was probably warranted. noticed that the AI is definitely stronger than before but still seems to have some weakness in the area of protecting transports. i know we've discussed it before but seems like there must be some way to prevent AI from spending all it can on facility repairs as well makes the AI very susceptible to strat bombing. autosaveBeforeEndTurn.tsvg
  • Usage of "Submarines Defending May Submerge Or Retreat"?

    7
    1 Votes
    7 Posts
    1k Views
    C
    @Trevan Yeah, this is a very old problem. V1.III is not something I can be sure, but I'm almost sure you should be able to submerge regardless whether or not you are able to retreat. As far as "Submersible Subs" goes, my suggestion was to keep the name as an archeproperty and split it into a series of new properties.
  • 0 Votes
    36 Posts
    5k Views
    C
    @Trevan I suggest you not to make changes if you don't know what's the matter about it, especially in the moment that the change is not going to fix any known problems. The auto-elimination steps should rather be generally revised, maybe from scratch, so to solve the known problems and creating a system actually enforcing the correct rules (that will need to be interpreted, to some extent). Thinking hard about this, the only situation of only infrastructures remaining needing auto-elimination of non-infrastructure units I can think of is the case of defending units refusing to partake in air battles.

Recent Posts

  • @LaFayette Why is there chosen for this release strategy? What are the pros and cons? In other programs, there is a release strategy I like that notifies you every now and then of an update (like every 1-2 weeks). Then, as the user, you have the option to install the update, ignore it for now, or ignore it completely and not be reminded of it anymore.

    I think there are definitely people who would like to have the latest features and fixes, and if they get only notified like once every three or six months, they would have to go to the website themselves to see if there is a later version, somehow find out what has changed, and decide if it's worth updating.

    It would be better I think to have definitely not less than 4 releases a year. Probably more like 6 or 12 (simply every month). If we would do monthly releases, in an ideal world, players would get a pop-up the next time they start TripleA after a release, stating that there is a new recommended release, along with an overview of what has changed. Then, players have the option to install it (also ideally, let the program automatically uninstall the current version and install the new one instead of having to do that yourself), or to ignore the update for now and be reminded on the next start-up, or to ignore it completely and only be reminded once the next recommended release is out.

    There might be an argument against monthly releases that the program might not see enough updates in that time period. As I have started contributing only recently, I might have jumped in at a time that happened to have a lot of activity, but other than that I cannot imagine that in an entire month, nothing of importance has been done to the program. There is always some kind of improvement that would be nice to have for the user, regardless of how small it is. And once in a month is long enough that it wouldn't start feeling intrusive to a user, something that could happen with weekly releases. You don't want to bombard them with updates as that can become annoying over time. Twice a year sounds like way too little. A lot can happen during that time and might introduce too many changes and updates at once.

    Another argument would be that there wouldn't be enough new downloads that would prevent the TripleA installer from being flagged by Windows Defender when running. I can concur with that, but I think the majority of the downloads would come from users updating, not so much from new users downloading the program. So increasing the time period might not help as much as it might seem. But we would have to do some experimentation on that.

    Given everything, I would suggest simply starting with quarterly releases, that sounds like a good start, and then observe what the general feedback is from the users, and also keep an eye on the number of downloads.

    read more

  • Would pre-release versions be available with any change? I am always using the pre-release.

    read more

  • On the other hand, to minimize the risk of burn-out in doing such a thing (which I guess is easily done but very unengaging especially in case of problems emerging right after the community at large gets to "test"), the best choice would be doing it only once per year and exactly in the time of the year (whatever it is) where developers tend to have more free time and more willingness of using their free time to manage TripleA. Add to that that, if one thing happens once a year, it is much easier for a person immediately to remember "it's TripleA release time", so it can become more easily part of the tribal knowledge of the community (meaning that people will be more likely to accept problems as part of an expected process rather than feeling like the developers are randomly thowing lemons at them) if the process becomes consolidated.

    read more

  • @LaFayette said:

    So, if we do twice a year, that would be be a Nov 1st recommended release and then a May 1st recommended release. That is probably a good place as any to start.

    As a non-developer, I would go with whenever tends to be the period when developers have more free time (asking the other main developers).

    (I think more people being online during releases can be argued either way about being a good or bad thing.)

    I would actually go with quarterly "releases", so, when one gets skipped, it becomes a 6 months wait rather than an 1 year wait (and 9 months instead of 1.5 years if two get skipped).

    read more