Feedback for [6870] and [6281]

Describe your experience with the latest version of FreeOrion to help us improve it.

Moderator: Oberlus

Forum rules
Always mention the exact version of FreeOrion you are testing.

When reporting an issue regarding the AI, if possible provide the relevant AI log file and a save game file that demonstrates the issue.
Message
Author
Dragget
Space Floater
Posts: 33
Joined: Mon Feb 10, 2014 9:39 am

Feedback for [6870] and [6281]

#1 Post by Dragget »

I've been playing this over the past couple of months and thought I'd give some feedback. Mostly I'm really impressed with it, especially given that it's a work-in-progress :)

[6870]
I just checked this out last night. After starting one game I removed it and went back to 6281. In the build queue, the planet where the item is being constructed is not displayed. This is vital information and (for me) the game is unplayable without it. I did like how in the status updates it announces when you can build new items like outpost bases, shipyard addons, etc.

[6281]
I really like the build queue. Having the total production of your empire applied to all projects makes a lot more sense than how it is in other games where each world has a separate build queue. It's nice to see all my projects in one place. It would be even better though to have separate queues for ships and planetary improvements, along with a slider that would control what percentage of industrial output goes to each... or even possibly use the "infrastructure" stat for the planetary improvements. As my empire grows, the combined build queue tends to get really long, as I add items to improve the new worlds I have settled or conquered, and I find myself spending a lot of time rearranging items in the queue to get high-priority projects completed faster. Having separate queues would make this process less of a hassle IMO

I've seen mention of how certain races have bonuses or penalties to their starship piloting skill here on the forums, but in the game, these stats don't appear in the race descriptions. Every other stat is apparently there, but this one seems to have been overlooked. Where can I find this information? (FWIW, in 6870, some of this info had been added, but most of the races still had nothing in their 'pedia entries.)

Xenophobia is a concept that needs some refinement or adjustment. Currently, exobots cause xenophobic frenzy in races with that trait and suffer from xenophobic harassment also. Given that nay race can build them, shouldn't they be immune from this effect? Additionally, I have noticed that the range extends well beyond the current star system. I did experiment with xenophobic races briefly but given the extreme range of the effect, found them too much trouble to be worth it. I also neutralized a xenophobic AI race once just by settling around him: my nearby colonies crippled his production and he never expanded beyond his inital colony as a result, in spite of the fact that there were available star systems nearby that he could have taken. If this effect were toned down a bit so it only caused problems when you mixed different races in the same star system I think it would be more reasonable.

System defense mines cause damage regardless of whether you are at peace or not. IDK if this is intended, but it's especially annoying when I share control of a star system with another empire and their mines start damaging my ships. IMO the way these work currently needs to be reexamined.

AIs seem to use good strategy when I am fighting them, but the fact that they remain at war with each other makes them a lot easier to defeat as a human player. I generally make peace with everyone at the start of each game, but I have noticed on a number of occasions that a neighboring AI will get wiped out by one further off because he is so focused on posting large fleets in my territory that he neglects defending his own star systems and the other AI is able to easily conquer them because they are not adequately defended. The only thing that seems to deter them from this behavior is system defense mines, and even then the foreign fleets sometimes linger and take a lot of damage when they could be better used back home defending their own territory.

One thing that I really enjoyed about Galactic Civilizations was how ships eared XP from combat and became more effective as they won more battles. Along with this, you could refit a ship with more advanced weapons and defenses as you researched them. As a result, an older ship that you had upgraded would be much more effective than a brand-new one of the same type that just came out of the yard. Adding a feature like this would add an interesting dimension to gameplay.

User avatar
MatGB
Creative Contributor
Posts: 3310
Joined: Fri Jun 28, 2013 11:45 pm

Re: Feedback for [6870] and [6281]

#2 Post by MatGB »

Dragget wrote:I've been playing this over the past couple of months and thought I'd give some feedback. Mostly I'm really impressed with it, especially given that it's a work-in-progress :)

[6870]
I just checked this out last night. After starting one game I removed it and went back to 6281. In the build queue, the planet where the item is being constructed is not displayed. This is vital information and (for me) the game is unplayable without it. I did like how in the status updates it announces when you can build new items like outpost bases, shipyard addons, etc.
This is a display isssue on new install and has applied for as long as I've been playing, reinstall and try again, but resize your display window and then restart the game.

The planet info for some reason doesn't display if the game thinks the window is too small, I dislike this and would like it fixed but it's way beyond me and is a frequent cause of complaint.
[6281]
I really like the build queue. Having the total production of your empire applied to all projects makes a lot more sense than how it is in other games where each world has a separate build queue. It's nice to see all my projects in one place. It would be even better though to have separate queues for ships and planetary improvements, along with a slider that would control what percentage of industrial output goes to each... or even possibly use the "infrastructure" stat for the planetary improvements. As my empire grows, the combined build queue tends to get really long, as I add items to improve the new worlds I have settled or conquered, and I find myself spending a lot of time rearranging items in the queue to get high-priority projects completed faster. Having separate queues would make this process less of a hassle IMO
How about instead the ability to right click on an item (instead of double clicking) and add things to the top or bottom? I've been meaning to suggest this recently as it'd help with late game lag on larger galaxies anyway. I'm, personally, not keep on splitting the queue up, but others have suggested it elsewhere, I don't see it adding anything except confusion but if people want it and a dev thinks it's an idea I wouldn't object.
I've seen mention of how certain races have bonuses or penalties to their starship piloting skill here on the forums, but in the game, these stats don't appear in the race descriptions. Every other stat is apparently there, but this one seems to have been overlooked. Where can I find this information? (FWIW, in 6870, some of this info had been added, but most of the races still had nothing in their 'pedia entries.)
All races that have either good or bad piloting skills had that info added at the same time as the traits themselves were coded, if it doesn't say anything they have standard stats, this might be something that needs rethinking a bit but currently if it says nothing then they're normal. I don't recall when this was introduced and don't remember when 6821 was, but it's definitely all correct in 6870 as I checked it all myself recently.
Xenophobia is a concept that needs some refinement or adjustment. Currently, exobots cause xenophobic frenzy in races with that trait and suffer from xenophobic harassment also. Given that nay race can build them, shouldn't they be immune from this effect? Additionally, I have noticed that the range extends well beyond the current star system. I did experiment with xenophobic races briefly but given the extreme range of the effect, found them too much trouble to be worth it. I also neutralized a xenophobic AI race once just by settling around him: my nearby colonies crippled his production and he never expanded beyond his inital colony as a result, in spite of the fact that there were available star systems nearby that he could have taken. If this effect were toned down a bit so it only caused problems when you mixed different races in the same star system I think it would be more reasonable.
But then it would be slightly too powerful for Eaxaw as they currently stand. Exobots don't cause frenzy, this was fixed a month or so back after several of us pushed for it. I'm not keen on the exact current implementation but it's something you can live with, I've thought of various affects that could be sorted out to reduce the problems. FWIW, it's limited to a 5 jump distance, if you're playing on Low starlanes, or Medium starlanes/low planets it doesn't actually impede much at all, my favourite current setup (as I find it actually challenging) is low planets, medium starlanes, vast galaxy with a small number of AIs (400 systems and 8 AIs works well for me on my older system)

Xenophobia needs some work, but it's something you get used to and without it Trith are ridiculously powerful as a playable race and Eaxaw, with their Great Pilots trait, are too good as either played or conquered.
System defense mines cause damage regardless of whether you are at peace or not. IDK if this is intended, but it's especially annoying when I share control of a star system with another empire and their mines start damaging my ships. IMO the way these work currently needs to be reexamined.
Definitely agree it shouldn't happen to allied/friendly ships, I'm hoping to redo some of the mines scripting once I've finished redoing the Damage Control techs, but that project keeps getting knocked down the list of things to work on in favour of bughunting and other features.


Seriously, reinstall the test version, but when you do, resize the window to where you want it, rest your graphics and audio options, then kill the game and restart. You'll notice that not only are the planet names back in teh build queue, but they're highlighted to be a lot more obvious when you have a system selected, in addition many of your other concerns are fixed and/or mitigated.

However, it doesn't work with savegames from earlier installs (at least not on Windows) so if you're in the middle of a game finish that first ;-)

Guys, why is it set to not display planet names on 1024 wide? And is that really an optimal choice? We've had multiple players complaining about it recently, those of us that reinstall regularly are used to having to resize and reboot, but it's not ideal.
Mat Bowles

Any code or patches in anything posted here is released under the CC and GPL licences in use for the FO project.

User avatar
Geoff the Medio
Programming, Design, Admin
Posts: 12698
Joined: Wed Oct 08, 2003 1:33 am
Location: Munich

Re: Feedback for [6870] and [6281]

#3 Post by Geoff the Medio »

MatGB wrote:The planet info for some reason doesn't display if the game thinks the window is too small...
The reason is exactly what you state... there's not enough space to fit the text without potentially overlapping other text.

There are now also tooltips that indicate this info for items on the queue.
Edit: The space issue:
layout problems
layout problems
location_queue_overlap.png (26.99 KiB) Viewed 1415 times

Dragget
Space Floater
Posts: 33
Joined: Mon Feb 10, 2014 9:39 am

Re: Feedback for [6870] and [6281]

#4 Post by Dragget »

FWIW, [6870] is the most recent build and [6281] is the "stable" build (Windows)
MatGB wrote:This is a display isssue on new install and has applied for as long as I've been playing, reinstall and try again, but resize your display window and then restart the game.
Thanks! That fixed it.
MatGB wrote:How about instead the ability to right click on an item (instead of double clicking) and add things to the top or bottom? I've been meaning to suggest this recently as it'd help with late game lag on larger galaxies anyway. I'm, personally, not keep on splitting the queue up, but others have suggested it elsewhere, I don't see it adding anything except confusion but if people want it and a dev thinks it's an idea I wouldn't object.
Like I mentioned, single queue with everything in it makes for a huge list in late game/large empire situations and I find myself spending a lot of time reordering it to move ships up or down depending on whether I am at war or not. When I am not fighting I want to prioritize planet improvements over shipbuilding and it would just be much simpler to adjust a slider and be done with it rather than moving a bunch of ships in the queue. with two queues and a slider to control how much production (% of total) is allocated for each one, it just seems like that would be more flexible and need less micromanagement.

MatGB wrote:All races that have either good or bad piloting skills had that info added at the same time as the traits themselves were coded, if it doesn't say anything they have standard stats, this might be something that needs rethinking a bit but currently if it says nothing then they're normal. I don't recall when this was introduced and don't remember when 6821 was, but it's definitely all correct in 6870 as I checked it all myself recently.
All other traits are listed even if they are 100% (normal). Pilot skill is the only one that doesn't follow this convention. in [6281] it isn't listed at all. In the most recent build, some races have it listed and others don't. If, as you say the ones with a modified pilot skill have it indicated in their 'pedia entry, that's an improvement, but IMO that stat should be listed regardless just like all the other stats to avoid confusion.
MatGB wrote:But then it would be slightly too powerful for Eaxaw as they currently stand. [...] I'm not keen on the exact current implementation but it's something you can live with, I've thought of various affects that could be sorted out to reduce the problems. FWIW, it's limited to a 5 jump distance, if you're playing on Low starlanes, or Medium starlanes/low planets it doesn't actually impede much at all
Well as it stands, in even moderately dense layouts, it's a crippling handicap. There has to be a middle ground that would make it less extreme while still providing a reasonable handicap. 5 jumps is a LONG distance for this effect.
MatGB wrote:Exobots don't cause frenzy, this was fixed a month or so back after several of us pushed for it.
Glad to hear that. I had not played any games with the current release, as the display issue I mentioned made it impossible for me.

User avatar
MatGB
Creative Contributor
Posts: 3310
Joined: Fri Jun 28, 2013 11:45 pm

Re: Feedback for [6870] and [6281]

#5 Post by MatGB »

Dragget wrote:FWIW, [6870] is the most recent build and [6281] is the "stable" build (Windows)
Ah, thanks, my memory isn't as good as it used to be ;-)
All other traits are listed even if they are 100% (normal). Pilot skill is the only one that doesn't follow this convention. in [6281] it isn't listed at all.
It didn't exist as a trait in 6821, it was introduced relatively soon afterwards but we've gone longer between stable releases this time as there's a LOT going on in the backend that needs finishing off (last weeks test release, for example, was horribly unstable and broke several features). As the massive improvement in performance of the game engine is noticeable, especially on my older system, that's a Good Thing, even if it does mean other features that're "old" to me aren't there for a lot of players.

However, there are other stats not listed as standard, good stealth and good vision being two I found by just looking at the Nymnmn entry, I don't know if there are others and I'm also not sure that not listing them is a good idea, it's definitely worth thinking about and the feedback is useful (there's no one specifically workign on the Pedia but it is something I'm looking at as well as other things (my main proejct at the moment is rebalancing the ship hull/costs but the pedia does also need some rewording for several entries.
Well as it stands, in even moderately dense layouts, it's a crippling handicap. There has to be a middle ground that would make it less extreme while still providing a reasonable handicap. 5 jumps is a LONG distance for this effect.
that's a perspective, for my preferred layout 5 jumps is nothing, for other settings it can appear to be crippling but only, normally, in the really early game and only for a few planets-it doesn't really affect research output, for example, so I tend to just put planets affected onto research and leave them to it until I've got solar generators and tier 2 industrial centres. Just looking at my current game, my Scylior homeworld, two jumps from some Trith, has a total industrial output of 96, which includes a -9 xenophobe malus, I suspect my game will be over before the planet reaches peak, and by then I simply won't notice.

I do think it's too much in the very early game, and have played around with other affects but haven't found one that I'm happier with. But, you can easily go in and change the settings, it's all in species.txt in the default folder, reduce the distance down or simply change the malus to a flat rate -1 or -2 and it won't break the AI or hurt the game at all.
MatGB wrote: Glad to hear that. I had not played any games with the current release, as the display issue I mentioned made it impossible for me.
The thing I love about the game is that it's a work in prgoress that's, in general, getting better. The thing that annoy me most when playing the game is that it's, still, a work in progress.

But given if you're playing on the most recent test you've almost certainly read text I've recently written or rewritten in the game, that's kinda cool given how poor my coding skills are.

Seriously, xenophobia is a problem, but we haven't come up with a better solution than the one we've got without breaking the species invloved, and I love that we've got stuff like that that adds character.
Mat Bowles

Any code or patches in anything posted here is released under the CC and GPL licences in use for the FO project.

User avatar
Dilvish
AI Lead and Programmer Emeritus
Posts: 4768
Joined: Sat Sep 22, 2012 6:25 pm

Re: Feedback for [6870] and [6281]

#6 Post by Dilvish »

MatGB wrote:
System defense mines cause damage regardless of whether you are at peace or not. IDK if this is intended, but it's especially annoying when I share control of a star system with another empire and their mines start damaging my ships. IMO the way these work currently needs to be reexamined.
Definitely agree it shouldn't happen to allied/friendly ships, I'm hoping to redo some of the mines scripting once I've finished redoing the Damage Control techs, but that project keeps getting knocked down the list of things to work on in favour of bughunting and other features.
I just checked both the scripting and the Condition code, and it all looks correct -- all the mine techs only apply damage to ships that are

Code: Select all

OwnedBy EnemyOf Source.Owner
If you guys are really convinced it's not working right thought I can try double checking things sometime, starting with the parsing.

[edit] though my best guess would be a parsing problem of "Source.Owner", but then it looks like mine damage would happen to everyone, even the owner. So I'd be looking for some significant evidence this isn't working right before I put much more time into it.[/edit]
If I provided any code, scripts or other content here, it's released under GPL 2.0 and CC-BY-SA 3.0

Dragget
Space Floater
Posts: 33
Joined: Mon Feb 10, 2014 9:39 am

Re: Feedback for [6870] and [6281]

#7 Post by Dragget »

MatGB wrote:I do think it's too much in the very early game, and have played around with other affects but haven't found one that I'm happier with. But, you can easily go in and change the settings, it's all in species.txt in the default folder, reduce the distance down or simply change the malus to a flat rate -1 or -2 and it won't break the AI or hurt the game at all.
Xenophobia doesn't just affect production. in the stable release, when I colonized in close to the xeno species, their planets were actually experiencing population crash... I was wiping them out just by proximity, and that's in addition to the production penalty they were taking. As far as that goes, the penalty was higher than the one I got from the harassment effect from being close to them, and it was even worse as I had 2 different species in my nearby colonies. If you were to eliminate the effect on population and just make it a flat penalty (as opposed to increasing with the number of species) that might moderate it enough to where it wouldn't be crippling in smaller/closer maps.

User avatar
MatGB
Creative Contributor
Posts: 3310
Joined: Fri Jun 28, 2013 11:45 pm

Re: Feedback for [6870] and [6281]

#8 Post by MatGB »

It shouldn't cause them to die out, that's must be a bug I've not seen if so.

What does happen is, for Trith only, they're Self-Sustaining, which gives them a massive inbuilt population boost. If affected by Xenophobia, they lost that bonus (it displays slightly differently, but the self sustaining bonus and the xenophobia malus should be within 0.1 of each other, if not there's a bug we need to look at).

Basically, if affected by the malus, Trith planets return to the standard population that normal species would get without other bonuses like photorophic or caretaker's fruit. Without that malus, Trith are, seriously, ludicrously overpowered, just as Kobuntura are one of the best species to get hold of within the Native options.

It almost certainly needs better explanation if it looks like they're dying off completely, they shouldn't be but it's worth looking at.

FWIW, there are report threads back from when it was introduced when I played through games as xenophobe species and conquered entire galaxies and wiped out everyone else, it's a fun, and different, approach and Trith can be very effective if done that way. They're a bit more annoying if you conquer them, but they're still useful, I use them to build all my scout ships and warships if I haven't got good pilots, their scouting bonus is incredibly useful, and their production overall is still better than many other species.
Mat Bowles

Any code or patches in anything posted here is released under the CC and GPL licences in use for the FO project.

Dragget
Space Floater
Posts: 33
Joined: Mon Feb 10, 2014 9:39 am

Re: Feedback for [6870] and [6281]

#9 Post by Dragget »

Dilvish wrote:If you guys are really convinced it's not working right thought I can try double checking things sometime, starting with the parsing.

[edit] though my best guess would be a parsing problem of "Source.Owner", but then it looks like mine damage would happen to everyone, even the owner. So I'd be looking for some significant evidence this isn't working right before I put much more time into it.[/edit]
Well I have not played far enough into games on the current release to know if it's an issue there. If you look at my OP I stated this was an issue in the "stable" release.

User avatar
MatGB
Creative Contributor
Posts: 3310
Joined: Fri Jun 28, 2013 11:45 pm

Re: Feedback for [6870] and [6281]

#10 Post by MatGB »

FWIW, the stable release isn't guarnateed bug free, and we've fixed quite a lot of bugs since then, it's basically supplanted by the most recent Test. So while bugs from there are still worth knowing about, several are either dealt with or no longer relevent/existing/whatever. Still worth knowing about them.

For example, I've just gone through my Trith worlds and found out that the self sustaining/xenophobia malus/bonus isn't working as intended, I'm going to play around a bit and then start a different thread from what I can see from the code it shouldn't wipe planets out but it definitely isn't right, then, neither is Self Sustaining.
Mat Bowles

Any code or patches in anything posted here is released under the CC and GPL licences in use for the FO project.

Dragget
Space Floater
Posts: 33
Joined: Mon Feb 10, 2014 9:39 am

Re: Feedback for [6870] and [6281]

#11 Post by Dragget »

Played a bit more on the latest release. SD mines are definitely not doing damage to non-hostiles in this release.

As far as the display issue in the production queue, one solution might be to move the planet name to a separate line. That way you could still display planet names at lower resolutions... you'd just have to make each box in the queue 1 line taller. Even at high resolutions, I've noticed the planet names overlapping the item name when one or the other are long (Asteroid belts are a good example of this... they frequently overlap). I adjusted my normal text font size down to 11pt and that helps, but that setting affects ALL normal text... might be nice to have different settings available for text on the various screens: 11pt seems fine on the production screen, but it's a bit small for the tech tree.

ASGeek2012
Space Floater
Posts: 20
Joined: Sat Feb 01, 2014 4:42 am

Re: Feedback for [6870] and [6281]

#12 Post by ASGeek2012 »

MatGB wrote:It didn't exist as a trait in 6821, it was introduced relatively soon afterwards but we've gone longer between stable releases this time as there's a LOT going on in the backend that needs finishing off (last weeks test release, for example, was horribly unstable and broke several features). As the massive improvement in performance of the game engine is noticeable, especially on my older system, that's a Good Thing, even if it does mean other features that're "old" to me aren't there for a lot of players.
Okay, so some of the lag I was seeing on the 0.4.3 was not me. I thought perhaps I was having trouble because my Linux system is using the open source Nvidia drivers instead of the proprietary ones. So this is good news and something to look forward to.

Concerning feedback for the build queue, and apologies if this was mentioned before and I missed it, but one thing that annoys me about it is that when I tell it to build an item that is supposed to be unique to a planet, it does not remove it or gray it out from the available list. I've lost track of how many times I've queued up something a second time, only to have the game work on BOTH of them in parallel. One invariably finishes first and the other sits in the queue with "Never" listed as the time to finish, usually with a bunch of now wasted production allocated to it.

User avatar
Dilvish
AI Lead and Programmer Emeritus
Posts: 4768
Joined: Sat Sep 22, 2012 6:25 pm

Re: Feedback for [6870] and [6281]

#13 Post by Dilvish »

ASGeek2012 wrote:...one thing that annoys me about it is that when I tell it to build an item that is supposed to be unique to a planet, it does not remove it or gray it out from the available list. I've lost track of how many times I've queued up something a second time, only to have the game work on BOTH of them in parallel. One invariably finishes first and the other sits in the queue with "Never" listed as the time to finish, usually with a bunch of now wasted production allocated to it.
Yes, that annoys everyone; I know it certainly happens to me once in a while. Within the current scripting constraints, our options are limited, but I do think we have a reasonable solution: The Location conditions could be made so that if you add a second one such building, then both items go to producing "Never" and stop accumulating PP. That way at least you wouldn't waste anything. With a small bit of additional coding change, the "Never" could be in bold Red so that it grabs attention. That's my proposal, but I never saw a consensus to adopt it.

Alternatively, a bit more coding could enable a new attribute for building specifications, a "Queue Limit" Condition, much akin to the Location condition, but it would merely cause the item to be 'unavailable' for being added to the queue rather than actually halting production of an item already in the queue.
If I provided any code, scripts or other content here, it's released under GPL 2.0 and CC-BY-SA 3.0

User avatar
Geoff the Medio
Programming, Design, Admin
Posts: 12698
Joined: Wed Oct 08, 2003 1:33 am
Location: Munich

Re: Feedback for [6870] and [6281]

#14 Post by Geoff the Medio »

Dilvish wrote:Alternatively, a bit more coding could enable a new attribute for building specifications, a "Queue Limit" Condition, much akin to the Location condition, but it would merely cause the item to be 'unavailable' for being added to the queue rather than actually halting production of an item already in the queue.
I was pondering something similar, except the other way around... If the condition was present, it would need to be met for the item to be enqueued. After being enqueued, the condition would have no effect.

User avatar
Dilvish
AI Lead and Programmer Emeritus
Posts: 4768
Joined: Sat Sep 22, 2012 6:25 pm

Re: Feedback for [6870] and [6281]

#15 Post by Dilvish »

Geoff the Medio wrote:I was pondering something similar, except the other way around... If the condition was present, it would need to be met for the item to be enqueued. After being enqueued, the condition would have no effect.
Yeah, that's what I really met -- imagine the phrase "akin to the Location condition, but it" being followed by the words "not being met"
If I provided any code, scripts or other content here, it's released under GPL 2.0 and CC-BY-SA 3.0

Post Reply