Group Details Private

Global Moderators

Forum wide moderators

  • RE: Donation Drive For 2020

    @pact_of_plastic Thanks for your generous donation!

    posted in Donation Drive 2020
  • RE: Cold War 1965 - Official Thread

    @Panther said in Cold War 1965 - Official Thread:

    A defending ICBM on the other side is not intended to attack a territory but attacking units instead?

    FWIW, a defending ICBM when attacked always suicides and is removed. It's in part meant to represent nuclear first strike. There can be a house rule whether AA fire can prevent this or not. It introduces a dynamic where producing an ICBM can in turn cause the opponent to use any they have in stockpile thereby trading them. If someone can get ahead by more than 1 ICBM then they have an advantage. Being able to place nuclear bombers (which have quite massive range of 10 IIRC) in position to be able to strike at a factory that could build a ICBM is a valuable suppression technique to trade an expensive nuclear bomber for an even more expensive ICBM, typically preventing an opponent from building one in that case (which makes kamikaze even more potent of a setting, which AFAIK is somewhat often toggled to on for this map)

    posted in Maps & Mods
  • RE: Cold War 1965 - Official Thread

    @mattbarnes Yeah, I would recommend setting AI-China and AI-Sinopact to Hard AI. The other neutral players probably just set to Does Nothing AI (but doesn't really matter since they don't have any phases so won't do anything no matter what).

    Trucks are just used for cheap, high movement fodder units and don't have isLandTransport currently.

    posted in Maps & Mods
  • RE: Cold War 1965 - Official Thread

    Would be nice to loop in the OC. AFAIK this map is usually played with Kamikaze turned on, a standard opening move is to nuke the single US ICBM and send a nuclear bomber on a suicide mission to take out the other two ICBMs, leaving US with zero by their turn.

    posted in Maps & Mods
  • RE: Please Help with Github upload

    Are you still having trouble? What is the full path of where you have files that were listed for changes and the full path from the last dialog in the previous screenshot you were sharing? Are those the same?

    I don't think you need to add a local repository given the first screenshot, that seems to be done already. It looks like all you need to do is to 'push' to sync your local changes with the remote repository.

    posted in Map Making
  • RE: Refactoring MustFightBattle

    @Trevan I have a weird weekly schedule right now, but I just wanted to let you know I appreciate the work and effort you put into all of this, even if I don't have the time to review it in the detail it deserves 👍

    posted in Development
  • RE: Refactoring MustFightBattle

    @Trevan Feel free to post a draft PR with work-in-progress and add a comment to the places that could use help with.

    Overall, incremental and early PRs are the ticket. Early feedback and bite-sized pieces are the golden ticket. In part what you are doing is relatively difficult, if not just to do it well and get it cleanly reviewed - so thank you for the effort and hang-in there.

    posted in Development
  • RE: Refactoring MustFightBattle

    Moved to development.

    In short @Trevan , yes, would be welcome. MustFightBattle has some of the worst metrics for technical debt, so it's a great area to fix up.

    Any such updates need to be done with care though as the code is complex and could easily cause an unnoticed regression. Using tests to help with that move and validate the logic would be excellent. We should perhaps discuss a test strategy so that not everything needs to be tested by setting up a game data object but instead decomposed to use mockable strategy objects.

    At the end of the day, still breaking it u and using a package structure to cluster the behavior would be excellent.

    posted in Development