@Zaroph Possibly. I think also most folks use the in-game chat and the forums and are used to those.

@Cernel said in AA revised - possible upgrades: @Panther said in AA revised - possible upgrades: Transports can offload into the same territory in both combat and noncombat movement if the second unit was loaded in a previous turn. On this regard, I'm actually not sure if a move like this would be allowed: starting the turn with an empty transport, loading 2 infantries into it, sending the transport into a naval battle and offloading 1 infantry into a sea borne assault, during Combat Move, winning the naval battle and the land battle where the unit was offloaded (this last thing may be granted, in case the territory is empty or having capturable units only), then offloading the other 1 infantry, into the same territory, during Non Combat Move. ? I checked this is wrong. However it would be correct if reworded this way: starting the turn with an transport with 1 infantry in it, loading 1 infantry into it, sending the transport into a naval battle and offloading 1 infantry into a sea borne assault, during Combat Move, winning the naval battle and the land battle where the unit was offloaded (this last thing may be granted, in case the territory is empty or having capturable units only), then offloading the other 1 infantry, into the same territory, during Non Combat Move. Basically, in Revised you have an additional incentive, however small in importance, for keeping your cargo on board across the rounds (really bad for playability, actually, as tracking loaded stuff is a serious pain). This is actually a bit bigger if you add also the (Revised OOB only) case of offloading 1 infantry to take 1 territory, then protecting this infantry by offloading an AA Gun, on the next Non Combat Move phase (this is actually something that has a good chance to be a good move, especially if you plan contesting with naval bombardment rather than with air units).

@Hepps said in Rework Purchase Units...: @simon33 I would probably find it really annoying to have all kinds of units on the map I can't move. Now I'd have to remember all my purchases and where I had placed them. A situation that would be even more complex if you already had a bunch of units in the same territory as where you have a factory and are placing 0 movement units. The other issue is whether you could have placed units with zero movement while all the existing units (very same units) would retain their movement? I'm not even sure that is possible. I understand what you're saying. Ideally, these new units would be invisible until the end of the turn which increases the complexity. Also, they need to not be granted movement at the start of combat movement, if you are playing a map with purchase before combat movement. Regarding the 2 stacks for different movement values, it is possible this has merit although it doesn't work this way now and would increase the clutter on the screen. Not sure if this is a goer.

@RoiEX looks like you do it using xcode somewhow: "Make sure to submit all versions of your software. While Xcode 10 or later is still required to submit, you don’t need to rebuild or re-sign your software before submission." i think i might already have a developer id and i definitely have xcode but i never really use it.

@LaFayette said in New method for board scrolling: @Cernel you're suggesting that the main map scrolls to the location of the right click? Or are you suggesting that when holding right click the mouse stays stationary and the map moves under it? Maybe these minimap analogies are confusing more than clarifying. Anyways, I was actually suggesting that the cursor "stays stationary and the map moves under it". Thinking again about it, you could also have the initial behaviour (for the initial right click only) of centring the map on the board pixel where the cursor is, while relocating the cursor itself at the centre too, in this case. However, this would raise the issue of what to do if you would have not enough board remaining to actually centre it (say, what should happen if I right click on the 0,0 coordinate of a not wrapping map like 270BC), which would be relevant for any maps not having both X and Y wrapping (I think only "Hexglobe", "Feudal Japan Warlords" and "Conquest of the World" do). On this regard, the centre should be the centre of the view, not the centre of the screen (usually the centre of the view is more to the left, if you have no history bar or the history bar is narrower than the main bar).

@Cernel I think you would be in the minority as most of the examples that both myself and @Frostion posted don't have a completely straight bar and mostly the ones that do are older games. The idea is to make the UI more dynamic and only take up the space it needs based on the information currently presenting so its more almost dashboard/widget like than pure bars/panels. As well as try to concentrate it more into the corners which act as sort of anchors so you have more visible screen area from a circular standpoint.

@Hepps *high five good post https://www.brainpickings.org/2017/01/24/dylan-thomas-do-not-go-gentle-into-that-good-night/

@Panther not easy questions to answer it turns out: How do we keep track of the ideas developed during a discussion? There is not set process. Keeping track of 'feature requests' is done via larger list in forums, for a specific feature, there is nothing set. The answer to this I don't think changes whether we are pre-merge or post-merge of the first version of a feature. We should not expect for updates to have every feature on the first version. Merges are not indicating that a feature is done and complete and will not be touched, but it means we have a minimum, useful start. For example, detecting a scramble is a feature, displaying the warning is a feature that builds on top, and giving an option to hide/ignore or always show the warning is yet another feature. It's not just one feature, but a set of features, we should not try to build it all at once. The feature for now has been included "as is" with the normative power of the fact. I respectively disagree with the concept of 'normative power of the fact'. I see many shortcomings from legacy technology that have morphed from "we don't do this because the technology does not allow us to", to "it is a rule that we don't do this". We lose sight of when we don't do something because we couldn't, rather than shouldn't. Having access to the code history, a number of things are clearly accidental and limitations rather than intentional rules. To illustrate this difference in perception, a good example is spaces in names. Many years ago, lots of code was rushed out. Shortly later, it was realized that tracking users by name is not a great thing and there are problems with it. There was more code added to handle this situation, hence why duplicate logins get the " (1)" appended to them and a rule was added to disallow spaces in names so that player tracking strategy (by name) would work. Later the context was forgotton, lost, polished over, and the original: "we hacked up some code and made a bad decision and then hacked in even more code to make it work", morphed into: "It was wisely decided and mandated that users should have no spaces in their names." So maybe to another extent I agree actually to this "normative power", but I'd point out that a number of the norms are accident, not the results of reasoned decisions. We have the power to release frequently now, to make updates to the codebase without huge overhead, so we can change things. Before it was all a process of sending email patches to Veqryn to be included on the next release, that is a six month turn-around, something that we do now in hours. This topic will get buried in forum history soon. The merged feature is behind the 'beta-feature' flag. It won't come out from that for a bit. That helps ensure we keep working on it. This thread won't drop in history quite that fast. A bigger issue is we need to decide requirements for the next iteration sooner, rather than later. If we can't come up with those requirements, the coder will do their best and will be forced to decide them where needed. If we delay on defining requirements, it's going to be a headache and lost effort. I expect @Alexei-Svitkine will jump in at some point, summarize the suggestions and discuss pros/cons and which ones he thinks are feasible and best to continue exploring.

@JPW062 Thanks for investigating. With luck we'll gradually continue to attract more people to TripleA code development.

@Cernel @redrum I will definitely take a look at all of this but will not be able to do that before next week, as I am currently travelling.

@Cernel I would tend to agree but the big problem is existing maps. If there weren't any maps using this then I would consider changing it but dealing with updating all of them is more work than I think changing this is worth.

@redrum I suggest the feature as default applying only to the units in main folder, not to any of the ones in the player's folder. For example, if a player would have some called units in its own folder and some in main folder and you set units.transform.flip or units.transform.color, only the units in main folder would be flipped or colourized, while no changes would be made on the ones in the player's folder. I think it would make the most sense, this way.

@ubernaut I think he is basically reffering to, "cards," in general. An example would be "Risk," Cards. Unfortunately no has coded a card system yet for TripleA.

More is not always better and I really see no good reasons to split between different kind of information, being them relationships, statistics, or whatever. Just an option for not giving any information that it is not given for the Neutral (null) player (thus comprising not being in the politics panel and in the players tab) should be good enough. This doesn't even need to be an option, by the way; it may be related to the player having no phases assigned (which would be consistent with the player being, thus, alike to the Neutral one). Also multiple options, side by side, would give pointless possibilities. For example, I don't think you'd ever want to hide any information about a player while offering it as selectable, do you? At most, the levels are going to be 3: 1- Players you want to select and have info. 2- Players you don't want to select, but still want to have info. 3- Players you don't want to select nor have info (like the Neutral player in NWO etc.). I still wonder if number 2 is even much of an item. What's the problem about assigning those players to the AI (maybe even to Nothing) and leaving them selectable, even if you are not supposed to ever select them. Telling a player it is supposed to be not selectable is already done by having it defaulting to an AI, isn't it? Then, we could add no options at all, but I still believe the "isHidden" option should be renamed into something more consistent and definite.

@Captain-Crunch i know it is still remember how inept it was before @redrum came around.

@redrum I tried the latest pre-release and it seems to work now Great Work!