Right, fair enough. They can go in afterwards. I might end up doing something about them before release, but if it doesn't actually get added till afterwards that's fine too.Vezzra wrote: ↑Mon Oct 10, 2022 4:51 pmWell, there are probably a lot of things/issues, which would be nice to have/address in 0.5. But we need to draw the line somewhere, or we will never get the release out. At our last voice chat meeting (on Oct 4th) we actually removed a lot of stuff from the 0.5 milestone. The decision is that only things that are really necessary for the release should be considered release blocking, and therefore assigned to the 0.5 milestone.
Everything else should be postponed to the next release cycle.
So, the question is, is it really necessary to include these items/issues (traffic control and lighthouses in alliances, with neutrals and enemies) into 0.5? How serious/game impeding are these issues?
0.5 release
Re: 0.5 release
Re: 0.5 release
Major status update:
Creation of the release branch is scheduled for coming Sunday, Nov 13th 2022, 3pm UTC. If there is anything anyone wants to get in before, please see to it that it can/will be merged in time. If there are any reasons why the creation of the release branch should be postponed, please post here in this thread in time.
There is one issue which has been opened yesterday (#4319), which looks quite serious and gamebreaking and might delay the creation of the release branch if not addressed in time. I'm waiting for feedback on that from Geoff and Oberlus (who reported the issue).
I've also opened the issue tracking the progress of the release process: https://github.com/freeorion/freeorion/issues/4320
Creation of the release branch is scheduled for coming Sunday, Nov 13th 2022, 3pm UTC. If there is anything anyone wants to get in before, please see to it that it can/will be merged in time. If there are any reasons why the creation of the release branch should be postponed, please post here in this thread in time.
There is one issue which has been opened yesterday (#4319), which looks quite serious and gamebreaking and might delay the creation of the release branch if not addressed in time. I'm waiting for feedback on that from Geoff and Oberlus (who reported the issue).
I've also opened the issue tracking the progress of the release process: https://github.com/freeorion/freeorion/issues/4320
Re: 0.5 release
The release branch "release-v0.5" has been created.
All changes committed to master from now on that should go into the release need to be cherry-picked. That means:
All changes committed to master from now on that should go into the release need to be cherry-picked. That means:
- If someone commits something directly to master (that means, not via PR), please cherry pick these commits to the release branch, if they should go into the release.
- PRs against master that should also go into the release need to be tagged with the label "status:cherry-pick for release" and assigned to the release milestone. After such a PR has been merged into master, please immediately do the cherry picking of the commits of that PR to the release branch if you can. If not, I'll try to take care of that as soon as I can, but in case of merge conflicts I'll need assistance. After the cherry picking has been done, the label "status:cherry-pick for release" should be removed.
Re: 0.5 release
Hi Vezzra,If someone commits something directly to master (that means, not via PR), please cherry pick these commits to the release branch, if they should go into the release.
For the previous release, I committed the latest french translation directly to the release branch.
As I didn't know if I could do the same thing for the 0.5 release, I pushed as usual in the master branch, and added "can be safely cherry-picked to release-v0.5 branch" in the commit description.
The french translation commit needing to be cherry-picked is 107a575 .
Sorry for the extra work!
I release every updated file under the CC-BY-SA 3.0 license.
- Geoff the Medio
- Programming, Design, Admin
- Posts: 13603
- Joined: Wed Oct 08, 2003 1:33 am
- Location: Munich
Re: 0.5 release
As with previous release(s), suggestions for key changes since / after v0.4.10 would be useful.
Re: 0.5 release
I've cherry picked that commit to the release branch.Ouaz wrote: ↑Sun Nov 13, 2022 6:33 pmFor the previous release, I committed the latest french translation directly to the release branch.
As I didn't know if I could do the same thing for the 0.5 release, I pushed as usual in the master branch, and added "can be safely cherry-picked to release-v0.5 branch" in the commit description.
Feel free to commit further changes to the French translation to the release branch, like you did with the last release.
No problemSorry for the extra work!
Re: 0.5 release
For this weeks test builds, I've still used current master, but starting with next week, as it has been in the past, the test builds will be based on the release branch, until the 0.5 release is out.
Re: 0.5 release
Obviously too much time has passed since the last major release (0.4.10), and I've forgotten something important:
As each issue that gets closed as resolved (whether that be by the reported bug being fixed, the requested feature being implemented), and each PR that gets merged needs to be assigned to a release milestone, stuff that will not be part of the 0.5 release (and won't be cherry picked to the release branch) needs a milestone to be assigned to, as it can't be assigned to the 0.5 milestone.
I'ce created the "next release" milestone for this purpose. So:
Please take care of that when you merge PRs and close issues.
As each issue that gets closed as resolved (whether that be by the reported bug being fixed, the requested feature being implemented), and each PR that gets merged needs to be assigned to a release milestone, stuff that will not be part of the 0.5 release (and won't be cherry picked to the release branch) needs a milestone to be assigned to, as it can't be assigned to the 0.5 milestone.
I'ce created the "next release" milestone for this purpose. So:
- When an issue gets closed as resolved, but the fix/implementation of that issue isn't going to be part of the 0.5 release, it needs to be assigned to the "next release" milestone.
- When a PR gets merged, that is not going into the 0.5 release, meaning it is not going to be cherry picked to the release branch, it needs to be assigned to the "next release" milestone.
Please take care of that when you merge PRs and close issues.
Re: 0.5 release
The first test builds of the 0.5 release have been uploaded. To all our playtesters, please focus on testing these (and future test builds of the release branch). To all our devs and contributors, please focus on the stuff required for the release, see the list of open issues and PRs assigned to the 0.5 release milestone:
https://github.com/freeorion/freeorion/milestone/26
Geoff is already working on the changelog - thanks for doing that again! So that too is already being taken care of.
https://github.com/freeorion/freeorion/milestone/26
Geoff is already working on the changelog - thanks for doing that again! So that too is already being taken care of.
Re: 0.5 release
The game isn't ready to be released until the Influence costs are a bit more predictable.
In a big test game, I was able to have an Influence production superior to 100 per turn.
Then after starting a conquest rampage, I began to get negative numbers while still having Target output superior to 100.
I'm not saying that I managed perfectly, but I spend around 40 turns frantically trying to rise the Influence production, and finally succeeded but I had lost more than 6000 Influence points in the meantime, because I continued conquering, though at a more modest pace.
That Influence output is slow to grow is probably a good thing as it slows rampages (as intended) and force careful planning.
That the numbers are completely unpredictable makes the game unplayable for any ordinary person.
One can easily check how much a Colony costs in direct Influence upkeep, and make decisions about building or not new colonies depending on the expected influence income of present and future colonies; but it's impossible, without recurring to an external tool (and knowing precisely the equation, which may change with updates) to know whether a Colony on a Succulent Barnacles will produce a positive or a negative global output (yes, I had negative outcome with Tae Ghirus on Shimmer Silk).
The minimum fix is to have somewhere (maybe in the pedia ? In the mouse-over on the Influence icon ?) a text like "Next colony will raise your global Influence upkeep by X; next Outpost by Y; ten more Colonies will raise your global upkeep by Z; getting rid of one/ten colonies will lower your global upkeep by P/Q".
Also probably something like "it will take N turns to reach your expected output/to get back to positive output".
In a big test game, I was able to have an Influence production superior to 100 per turn.
Then after starting a conquest rampage, I began to get negative numbers while still having Target output superior to 100.
I'm not saying that I managed perfectly, but I spend around 40 turns frantically trying to rise the Influence production, and finally succeeded but I had lost more than 6000 Influence points in the meantime, because I continued conquering, though at a more modest pace.
That Influence output is slow to grow is probably a good thing as it slows rampages (as intended) and force careful planning.
That the numbers are completely unpredictable makes the game unplayable for any ordinary person.
One can easily check how much a Colony costs in direct Influence upkeep, and make decisions about building or not new colonies depending on the expected influence income of present and future colonies; but it's impossible, without recurring to an external tool (and knowing precisely the equation, which may change with updates) to know whether a Colony on a Succulent Barnacles will produce a positive or a negative global output (yes, I had negative outcome with Tae Ghirus on Shimmer Silk).
The minimum fix is to have somewhere (maybe in the pedia ? In the mouse-over on the Influence icon ?) a text like "Next colony will raise your global Influence upkeep by X; next Outpost by Y; ten more Colonies will raise your global upkeep by Z; getting rid of one/ten colonies will lower your global upkeep by P/Q".
Also probably something like "it will take N turns to reach your expected output/to get back to positive output".
Re: 0.5 release
Another fix is using the policies that benefit from having independent planets around. Conquer a bunch of planets, give independence to the less interesting, rinse and repeat.
Re: 0.5 release
Yeah, that's what I did, but since the numbers are unpredictable that's also how I lost 6 K IP.
I'm not ranting against the mechanisms (they're probably not perfect, but there's consensus to launch the release with how they are now), I'm saying that it's impossible to play strategically when the player doesn't have the information about what effects his actions will generate.
I mean, I knew how much IP upkeep I had to compensate for, i knew how much planets I needed to conquer, I knew how much an Influence-oriented planet was going to produce depending on the circumstances, so I could guesstimate how many planets ripe for high Influence production I needed to settle.
But even when I added a margin of safety because I knew that the global upkeep would grow with the numbers of planets settled, I was way off (well, at least 4 K off - I knew that since it takes time to settle planets, I would lose at least 2000 Influence points, but certainly didn't imagine that I would lose 6000) and had no way to make more precise calculations since the game doesn't provide the needed information.
I don't pretend to be an expert player, but I do have some knowledge of the game now; any new player being put in a similar situation will just consider the game to have no logic at all.
The delay that the "rinse and repeat" process imposes on the player isn't necessarily a bad thing, but being unable to predict this delay and the desired scope of the process is a game-breaking flaw.
I'm not ranting against the mechanisms (they're probably not perfect, but there's consensus to launch the release with how they are now), I'm saying that it's impossible to play strategically when the player doesn't have the information about what effects his actions will generate.
I mean, I knew how much IP upkeep I had to compensate for, i knew how much planets I needed to conquer, I knew how much an Influence-oriented planet was going to produce depending on the circumstances, so I could guesstimate how many planets ripe for high Influence production I needed to settle.
But even when I added a margin of safety because I knew that the global upkeep would grow with the numbers of planets settled, I was way off (well, at least 4 K off - I knew that since it takes time to settle planets, I would lose at least 2000 Influence points, but certainly didn't imagine that I would lose 6000) and had no way to make more precise calculations since the game doesn't provide the needed information.
I don't pretend to be an expert player, but I do have some knowledge of the game now; any new player being put in a similar situation will just consider the game to have no logic at all.
The delay that the "rinse and repeat" process imposes on the player isn't necessarily a bad thing, but being unable to predict this delay and the desired scope of the process is a game-breaking flaw.
Re: 0.5 release
I think what you ask about predicting influence upkeep after conquering/settling a new colony/outpost should be doable.
The current equation for upkeep is
0.4 * (N+E) * sqrt( N + 0.25*(O+E) )
N: owned colonies populated by non-exobot.
O: owned outposts
E: owned exobot colonies.
Increase when N grows by 1 (new colony):
0.4 * (N+E+1) * sqrt( N+1 + 0.25*(O+E) ) - 0.4 * (N+E) * sqrt( N + 0.25*(O+E) ).
Increase when E grows by 1 (new exobot):
0.4 * (N+E+1) * sqrt( N + 0.25*(O+E+1) ) - 0.4 * (N+E) * sqrt( N + 0.25*(O+E) ).
Increase when O grows by 1 (new outpost):
0.4 * (N+E) * sqrt( N + 0.25*(O+E+1) ) - 0.4 * (N+E) * sqrt( N + 0.25*(O+E) ).
The current equation for upkeep is
0.4 * (N+E) * sqrt( N + 0.25*(O+E) )
N: owned colonies populated by non-exobot.
O: owned outposts
E: owned exobot colonies.
Increase when N grows by 1 (new colony):
0.4 * (N+E+1) * sqrt( N+1 + 0.25*(O+E) ) - 0.4 * (N+E) * sqrt( N + 0.25*(O+E) ).
Increase when E grows by 1 (new exobot):
0.4 * (N+E+1) * sqrt( N + 0.25*(O+E+1) ) - 0.4 * (N+E) * sqrt( N + 0.25*(O+E) ).
Increase when O grows by 1 (new outpost):
0.4 * (N+E) * sqrt( N + 0.25*(O+E+1) ) - 0.4 * (N+E) * sqrt( N + 0.25*(O+E) ).
- Geoff the Medio
- Programming, Design, Admin
- Posts: 13603
- Joined: Wed Oct 08, 2003 1:33 am
- Location: Munich
Re: 0.5 release
The situation LR is talking about requires seeing more then 1 colony ahead. I'd argue you want a graph for this.