0.4.2 RC4 Schedule
0.4.2 RC4 Schedule
RC4 has been requested, I'm going to produce the RC4 builds today in the evening (after I get home from work). Same procedure as usual.
Deadline for patches/commits: Wednesday, Feb 20th 6PM UTC
Deadline for patches/commits: Wednesday, Feb 20th 6PM UTC
Re: 0.4.2 RC4 Schedule
RC4 has been uploaded.
Re: 0.4.2 RC4 Schedule
Played RC4 to turn 248.
Performance was good (no turn lag "felt").
AI was difficult (very nice) - I lost.
No major issues seen.
Ship it!
Performance was good (no turn lag "felt").
AI was difficult (very nice) - I lost.
No major issues seen.
Ship it!
Code released under GPL 2.0. Content released under GPL 2.0 and Creative Commons Attribution-ShareAlike 3.0.
Re: 0.4.2 RC4 Schedule
Played through one, haven't had any issues. Though in my case didn't have any trouble with the AI, but I did start out with a pretty good position so that helped. Performance was just fine on here. Got to turn 214.
Re: 0.4.2 RC4 Schedule
I'm very glad to hear it!yandonman wrote:Played RC4 to turn 248.
AI was difficult (very nice)
Also keep in mind, in addition to the vagaries of starting layout, the species are only partially balanced, and if you start with a powerful species yourself, and only have a few AIs they could easily wind up all hobbled with a less fortunate starting species and not make as much challenge. Starting with more AI's but with the same total number of systems will get things busier sooner and probably also be more challenging, is how it seems to work out for me.AndrewW wrote:Played through one, haven't had any issues. Though in my case didn't have any trouble with the AI, but I did start out with a pretty good position so that helped.
If I provided any code, scripts or other content here, it's released under GPL 2.0 and CC-BY-SA 3.0
Re: 0.4.2 RC4 Schedule
Just completed one with 200 systems and 10 AI's, was a noticable delay when doing end turn starting around turn 175 or so. Also things like combining fleets was rather slow as well.
- Geoff the Medio
- Programming, Design, Admin
- Posts: 13587
- Joined: Wed Oct 08, 2003 1:33 am
- Location: Munich
Re: 0.4.2 RC4 Schedule
There's no expectation that turn processing or UI responsiveness delays will have changed between the RC builds, so noting that they are still present isn't necessary for this discussion. Their presence isn't going to affect the timing of a release.
The AI doing nothing, or not designing new ships, or similar big functionality issues would be relevant.
When a future test build is put out that does do something that might impact UI or turn delays, notes about them would then be more helpful.
The AI doing nothing, or not designing new ships, or similar big functionality issues would be relevant.
When a future test build is put out that does do something that might impact UI or turn delays, notes about them would then be more helpful.
Re: 0.4.2 RC4 Schedule
Just meant in relationship to the previous posts.Geoff the Medio wrote:There's no expectation that turn processing or UI responsiveness delays will have changed between the RC builds, so noting that they are still present isn't necessary for this discussion. Their presence isn't going to affect the timing of a release.
Re: 0.4.2 RC4 Schedule
My most recent playtest: 80 systems, 3 AIs, aggressive difficulty, played as human.
Result: All AIs defeated around turn 100. Spawned sandwiched between etty and egassem. I colonized close to the etty capital without knowing and the Mark V's quickly chased me away and my colony got invaded (nice one AI ). I reclaimed my lost colony with relative ease. For some reason the AI fighters holding on to the system left. Later did I realize an eaxaw empire was beside the etty, so I can't say for sure the AI didn't defend properly or did something suboptimal. The other two empires had a huge case of bad luck. By the time I had them in my view, they still had just one planet.
I'm going to have another round with them because I lucked out.
Some comments/recommendations for the AI:
Result: All AIs defeated around turn 100. Spawned sandwiched between etty and egassem. I colonized close to the etty capital without knowing and the Mark V's quickly chased me away and my colony got invaded (nice one AI ). I reclaimed my lost colony with relative ease. For some reason the AI fighters holding on to the system left. Later did I realize an eaxaw empire was beside the etty, so I can't say for sure the AI didn't defend properly or did something suboptimal. The other two empires had a huge case of bad luck. By the time I had them in my view, they still had just one planet.
I'm going to have another round with them because I lucked out.
Some comments/recommendations for the AI:
- They still make too many scouts and troop ships, especially scouts. AI needs to make more fighters.
- AI should consider building scanning facilities for vision instead of sending scouts everywhere.
- AI sends too many scouts to the same system. It's common to find groups of ~5 scouts sitting in a system completely undefended apparently just to provide vision.
- When AI starts sacrificing scouts to get occasional updates on a system, it could probably sac them at longer intervals and build more fighters in the meantime.
- It feels like the AI overestimates their armed troop ships, especially against sentries.
- When attacking adjacent systems, they tend to use their entire fleet, which is suicidal if the attack fails (and they've failed a lot). They should leave some ships behind. How many can depend on the aggressiveness of the AI.
- Recommend AI to use lead armor plating (or any other plating) on their ships. I once had 8 armored organics with 2 laser 2 equipped hold off a fleet of 12 griffon 1-7's (the ones with laser 3).
- I know this will take some time to implement, but AI needs flexible research queues depending on the specific needs of the species it is playing as.
Re: 0.4.2 RC4 Schedule
Also should take into account location. For example if there is no blue star or black hole available the quantum flux hull isn't going to do them much good.unjashfan wrote:.[*]I know this will take some time to implement, but AI needs flexible research queues depending on the specific needs of the species it is playing as. [/list]
Re: 0.4.2 RC4 Schedule
- FreeOrionD.exe crashes:
https://dl.dropbox.com/u/46606285/share ... inidump.7z
https://dl.dropbox.com/u/46606285/share ... nQueue2.7z
Not sure of reproducible steps, but it's something like this:
In the production window
Add Endomorphic V.z
Change 18 repeat/5x "Organic V.z" to 1 repeat/5x
Change 1 repeat/1x "Endomorphic V.z" to 20 repeat/5x
Click Turn.
Crash.
"Endomorphic V.z" design: (- Zortium Armor, - Plasma Cannon I x3, - Deflector Shield x2) - Ran into a couple of cases where I couldn't invade... I suspect this was due to visibility ... though I didn't see the appropriate icons on the outpost
- Otherwise, played through turn 310. Won against AI - which seemed to be a pushover this time - but I think that was species and initial placement in my favor vs not in favor of AIs.
Code released under GPL 2.0. Content released under GPL 2.0 and Creative Commons Attribution-ShareAlike 3.0.
Re: 0.4.2 RC4 Schedule
Fixed.unjashfan wrote:I know this will take some time to implement, but AI needs flexible [everything] depending on [everything].
Warning: Antarans in dimensional portal are closer than they appear.
Re: 0.4.2 RC4 Schedule
It sounds like you were intending to attach a saved game file so that we could try to replicate the crash, but it seems both the links are to some kind of crash dump file... do you still have a saved game from just before crash?yandonman wrote:Not sure of reproducible steps, but it's something like this:
In the production window
Add Endomorphic V.z
Change 18 repeat/5x "Organic V.z" to 1 repeat/5x
Change 1 repeat/1x "Endomorphic V.z" to 20 repeat/5x
Click Turn.
Crash.
Also, on the "unable to completely bombard" screenshot -- did it stay like that turn after turn, or alternate between getting fully bombarded, and then no combat (during which it regened defense) and then combat/bombardment again? I've seen it happen like that.
If I provided any code, scripts or other content here, it's released under GPL 2.0 and CC-BY-SA 3.0
- Geoff the Medio
- Programming, Design, Admin
- Posts: 13587
- Joined: Wed Oct 08, 2003 1:33 am
- Location: Munich
Re: 0.4.2 RC4 Schedule
Similar issues have been reported, but without steps to reproduce, it's still difficult to do anything about it.yandonman wrote:Not sure of reproducible steps...
Or the freeorion log files? I can't do anything with whatever dump file windows generates.Dilvish wrote:It sounds like you were intending to attach a saved game file so that we could try to replicate the crash, but it seems both the links are to some kind of crash dump file... do you still have a saved game from just before crash?
Re: 0.4.2 RC4 Schedule
Unfortunately, no I didn't keep the game file. A tad dumb in retrospect. The intention was that the mini-dumps would give a (windows) developer a call stack and local variables if they have symbols for RC4's freeoriond.exe. That doesn't work too well cross platform...but it seems both the links are to some kind of crash dump file... do you still have a saved game from just before crash?
I could leave the attacking ships on a planet (with an invasion fleet there too) turn after turn and the planet would end up with 2.5 planet defense weapons each turn. I attributed that to planet defense regen (the research). In other places I saw similar things happen, and I was able to invade - so defense regen, I concluded, wasn't the culprit - and (presumed) regen-ed planet defense didn't stop invasions there. The concern was that I couldn't invade... not being able to "fully bombard" (as the picture was unfortunately named) didn't end up being a problem.Also, on the "unable to completely bombard" screenshot -- did it stay like that turn after turn, or alternate between getting fully bombarded, and then no combat (during which it regened defense) and then combat/bombardment again? I've seen it happen like that.
Code released under GPL 2.0. Content released under GPL 2.0 and Creative Commons Attribution-ShareAlike 3.0.