• 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
    770 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
    6k 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.
  • This topic is deleted!

    2
    0 Votes
    2 Posts
    18 Views
  • The Point of Play by Forum

    12
    0 Votes
    12 Posts
    2k Views
    PantherP
    @LaFayette I agree to your last posting in general. What triggered me was your sentence that PBF was "too damn complex to be useful". It has been proven on A&A .org that PBF is useful, that PPF does not have further usability issues, that PBF is popular and is used by a relevant number of players in a relevant number of games. And this is not an ephemeral impression but has been like this for more than 10 years - and still is of course. I am sure you have taken a look in the meantime. No one questions the benefits of streamlining processes or improving the code.
  • Unable to Host Network Game on Linux Raspbian (Raspberry Pi 4)

    3
    1 Votes
    3 Posts
    761 Views
    RoiEXR
    Interesting. Would you be able to provide a Stacktrace (the whole error message) so we can dig into this?
  • Internal Dice Sender Cleanup

    Moved
    10
    0 Votes
    10 Posts
    3k Views
    PantherP
    @LaFayette The dice logic that is (still) used by the engine in other play modes (for example "Local Game"). In PBF/PBEM you have always been able to avoid (external) MARTI in the past by using those internal dice. That was achieved by selecting "Internal Dice Roller" instead of an external Dice Server.
  • Feedback Game Engine 2.1

    1
    1 Votes
    1 Posts
    641 Views
    No one has replied
  • About the Battle Lost sound

    2
    1 Votes
    2 Posts
    775 Views
    C
    Also, if I'm being attacked and my opponent loses the battle or retreats, why do I even hear the "Battle Lost" sound? I didn't lose the battle: I won it! Shouldn't this sound be given only to the player assigned to the turn power or, at most, also to the other players of its side only? Maybe the win/lose sounds should be switched over for the opposite side? Opinions?
  • 0 Votes
    38 Posts
    9k Views
    PantherP
    @Cernel Correct. In newer editions a destroyer - among other things - cancels the submarine's ability to perform its surprise strike. In v2 however, the destroyer enables the sub's casualties to fire back at the normal time in the combat sequence.
  • JavaFX Update of Staging Screens

    18
    2
    0 Votes
    18 Posts
    2k Views
    RoiEXR
    @aardvarkpepper What is a "magic hover spot", exactly? @LaFayette is referring to this special location, where you can put your mouse where it flickers between 2 animation states, which doesn't look nice, nor is it intentional. was grey with text buttons, not all nice with the folders and buttons It still is that way, this thread is discussing future UI improvements.
  • 2.0 Rollout - Reducing 1.9 Bot Server Capacity

    6
    0 Votes
    6 Posts
    864 Views
    LaFayetteL
    Decommissioned the 7xx London server, we are down to 1 bot server with 7 game instances on 1.9 Upgrading the 1.9 messaging was surprisingly effective, most users are in the 2.0 lobby
  • Publishing Zip distributable AKA 'All Versions'

    1
    0 Votes
    1 Posts
    516 Views
    No one has replied
  • Refactoring MustFightBattle

    Moved
    21
    0 Votes
    21 Posts
    3k Views
    T
    I've been working on the offensive subs submerge/withdraw step and discovered that my idea of having a unified valid() check that works for both getNames and execute won't work. In the offensive subs submerge/withdraw step, execute shouldn't run if there is a destroyer present. But getNames is called at the beginning of the round and there might be a destroyer present that will die before execute is called. If getNames doesn't return the submerge/withdraw step, then an error will occur. I was actually able to trigger this error from the master branch when Submersible Subs is false, Sub Retreat Before Battle is false, and a destroyer is present at the beginning of the round but then is destroyed during the round. If Submersible Subs is true and Sub Retreat Before Battle is false, then this error doesn't occur because it doesn't check for destroyers. I'm going to be removing valid() as a public method from the BattleStep interface. Instead, getNames and execute will do their own internal valid check. This check might be the same or different, depending on the step.
  • How to fix staging screen alliances button (missing) feedback?

    5
    1
    0 Votes
    5 Posts
    1k Views
    LaFayetteL
    One other option I thought of is if we can change the behavior so it always has some sort of UI update. In essence the toast would actually be doing that. I think the options are: (1) have the alliance button cycle through choices (IMO not good) (2) have the alliance button show a toast (3) hide the alliance button when it would be a no-op If there's no feedback suggestions then will give (2) a go as a toast likely will not hurt. (3) is an option, initially I think it's not great to have controls appearing and disappearing.
  • Bots all crashed!

    3
    1 Votes
    3 Posts
    1k Views
    prastleP
    @LaFayette cool! I guess we shall see. Either way this was way better than the last crash. Great Stuff!

Recent Posts

  • This is my interpretation of the rules & what I coded:

    At the very start of the round, if any unit has the attachment canDefensiveRetreat = true, the defender gets a prompt if they want to retreat, and to which territory. They may only retreat to friendly/neutral territories, not an enemy territory, and they can't retreat to a territory with enemy units in it, unless only enemy air is present, which is non-blocking.

    If the defender chooses not to retreat, then the battle proceeds as normal. If the defender chooses a territory to retreat to, then that territory is saved and stored for later. The attackers fire at all of the defending units. Any units that are doing a defensive retreat do not fire back. Casualties are removed, and then any retreating units retreat to the destination we stored earlier. Any defender units not capable of retreating remain and must fight to the end/get captured/get removed, whatever happens normally

    EDIT: I was originally going to have a property that applies to all land units, but it turns out that in A&A North Africa not all land units can defensive retreat (the truck and the supply token can't) so it pretty much needs to be a unit attachment. This offers some variation as the mapmaker can select what units they want to be able to do a defender retreat

    read more

  • read more

  • @iratoric which North Africa game? AFAIK some of the variations are mutually exclusive. I think the first task it is to identify which variations should be plausibly supported. Once done, I would like a full spec identified. Following, we can then look at the plan for how that would be encoded into XML. Doing so iteratively and not all-at-once is perfectly fine. Though, I think we should know beforehand which retreat variations we are likely to want (and also in which maps).

    read more

  • @iratoric said:

    Thanks everyone for your opinions. I have thought about this a lot, and it is probably best if we start with implementing one set of rules and branch out from there. Otherwise there are simply too many possible combinations to do all at once. Since the North Africa game is the “official” ruleset and an already existing game that needs this rule, I think that whatever I implement should support that first. I will code it in such a way that it still leaves room for more variations later. Thoughts?

    I instead think that the baseline should be some version of what you/we can devise as the simplest retreat system, have that done and tested, then adding properties and/or options for each element adding complexity.

    For example, in the basic system you retreat to the same zone. Next step, with property, is retreating to an other zone. Next step, with property, is limiting retreat only to zones not under attack by land units. And so on.

    read more