Many feature requests and a few bugs for 0.4.5 RC1 (mostly)

Describe your experience with the latest version of FreeOrion to help us improve it.
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
o11c
Space Krill
Posts: 8
Joined: Fri Sep 11, 2015 11:02 am

Many feature requests and a few bugs for 0.4.5 RC1 (mostly)

#1 Post by o11c » Fri Sep 11, 2015 11:22 am

I wrote down a lot of little irritations and made a nice XML document, though for some reason it doesn't render right in Chromium, so use Firefox.

There's a few bugs in there too. I have tried to categorize the importance and complexity of each one, too.

Since that's a github repo, you can comment on the diffs or even submit PRs, but I'm also hanging out on IRC.

Since these are mostly feature requests, version isn't quite as important, but I have played from the Debian packages:
  • 0.4.4-2+deb8u1
  • 0.4.4+git20150327-2
  • 0.4.5~RC1-1
  • 0.4.5-1
but (with the exception of the top of the table which needs to be updated/merged) must of it was with RC1.

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

Re: Many feature requests and a few bugs for 0.4.5 RC1 (most

#2 Post by Geoff the Medio » Fri Sep 11, 2015 11:52 am

By scrapping an incomplete building, do you mean something other than removing it from the production queue (which can already be done)? Presumably you mean add a "Scrap"-like right click popup menu command to do this?

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

Re: Many feature requests and a few bugs for 0.4.5 RC1 (most

#3 Post by MatGB » Fri Sep 11, 2015 12:39 pm

Geoff the Medio wrote:By scrapping an incomplete building, do you mean something other than removing it from the production queue (which can already be done)? Presumably you mean add a "Scrap"-like right click popup menu command to do this?
That's actually I'd quite like, if you conquer a planet and it's building stuff you don't want going into the production queue can be annoying and definitely causes lag.

Reading through the whole list, some I agree with, others not so much or could be solved in different ways, I'll figure out how to comment on it later.
Mat Bowles

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

o11c
Space Krill
Posts: 8
Joined: Fri Sep 11, 2015 11:02 am

Re: Many feature requests and a few bugs for 0.4.5 RC1 (most

#4 Post by o11c » Fri Sep 11, 2015 8:14 pm

Link to comment: https://github.com/o11c/o11c.github.io/ ... b1beb5fL57

The most pressing issue is probably the "CPU usage even when not visible", since right now I have to work around it with a bunch of `killall -STOP freeorion` and `killall -CONT freeorion`.

At a quick glance CPU usage does seem better in 0.4.5 release than in RC1 (~40% instead of ~80%), but that might just be because I'm testing a fresh game, and there's still not the expected decrease when the window is *not* visible.

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

Re: Many feature requests and a few bugs for 0.4.5 RC1 (most

#5 Post by Geoff the Medio » Sat Sep 12, 2015 1:04 am

Stopping rendering in a "nice" way, so that it resumes rendering promptly, isn't simple to set up. But the latest master revision lets you specify separate max FPS for when the game window has or doesn't have focus. Dropping the non-focus limit to 5 or fewer FPS substantially reduces the CPU use for me.

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

Re: Many feature requests and a few bugs for 0.4.5 RC1 (most

#6 Post by Dilvish » Sat Sep 12, 2015 2:30 am

Geoff the Medio wrote:Dropping the non-focus limit to 5 or fewer FPS substantially reduces the CPU use for me.
Perhaps the default value for the non-focus limit should be in the 1-5 range?
If I provided any code, scripts or other content here, it's released under GPL 2.0 and CC-BY-SA 3.0

o11c
Space Krill
Posts: 8
Joined: Fri Sep 11, 2015 11:02 am

Re: Many feature requests and a few bugs for 0.4.5 RC1 (most

#7 Post by o11c » Sat Sep 12, 2015 3:54 am

I don't care about the not *focused* case, I care about the not *visible* case. Specifically, whenever it is minimized or on a non-visible desktop (which generates the same events as being minimized).

In X11 terms, when you receive an UnmapNotify event, you should not be rendering at *all* until the next MapNotify event. Since you're not doing damage-based rendering, even if your code is insane, this part could be as simple as keeping a bool flag and early-return'ing at the beginning of the render function - though you really should stop the redraw call from happening at all (stop generating ticks somehow? Why are there ticks at all when there are no active animations?).

(If you do switch to damage-based rendering, which would be a huge win for the kind of rendering that FreeOrion does, it's as simple as treating the whole window as damaged when MapNotify happens). In that case, you take action *only* when a network, input, or timed damage events from animations.

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

Re: Many feature requests and a few bugs for 0.4.5 RC1 (most

#8 Post by Geoff the Medio » Sat Sep 12, 2015 6:06 am

o11c wrote:I don't care about the not *focused* case, I care about the not *visible* case.
I realize that, but as I wrote above, stopping rendering in a "nice" way, so that it resumes rendering promptly, isn't so simple to set up. Minimizing the FPS while not focused gets you most of the way there; 0.5% or 1% CPU use is a lot less than the ~15% I get at nominal 60 FPS.
Dilvish wrote:Perhaps the default value for the non-focus limit should be in the 1-5 range?
Play around with it if you'd like; limiting the FPS so much does have minor annoying consequences, particularly to mouse cursor movement / rendering.

o11c
Space Krill
Posts: 8
Joined: Fri Sep 11, 2015 11:02 am

Re: Many feature requests and a few bugs for 0.4.5 RC1 (most

#9 Post by o11c » Sat Sep 12, 2015 8:26 pm

Okay, looking at the code, it shouldn't be too hard:
  • In GG/src/EventPump.cpp:
    • in EventPumpBase::LoopBody, remove the call to gui->Wait, instead return the value at the end (note that this means switching the order of the logic, but that won't have any visible effect).
    • in {,Modal}EventPump::operator(), pass the returned value as an argument to gui->HandleSystemEvents
  • In GG/src/SDL/SDLGUI.cpp:
    • In SDLGUI::HandleSystemEvents, replace the call to SDL_PollEvent(&event) with SDL_WaitEventTimeout(&event, timeout) but only the first iteration of the loop.
    • In SDLGUI::HandleSystemEvents, add case labels for SDL_WINDOWEVENT_SHOWN and SDL_WINDOWEVENT_HIDDEN (or possibly SDL_WINDOWEVENT_RESTORED and SDL_WINDOWEVENT_MINIMIZED - under X11 they occur at the same time, but I'm not sure about Windows or mobile, reading the SDL source was not enlightening).
    • If you manage to switch entirely to damage-based rendering (which you really should!), also add a case for SDL_WINDOWEVENT_EXPOSED.
The worst thing that could happen is that you draw a frame more frequently than expected whenever events happen. This would actually *fix* the problem where limiting FPS makes the mouse jerk.

In a damage-based system you would call it "animation quantum" though.

o11c
Space Krill
Posts: 8
Joined: Fri Sep 11, 2015 11:02 am

Re: Many feature requests and a few bugs for 0.4.5 RC1 (most

#10 Post by o11c » Sat Sep 12, 2015 11:22 pm

Expanding on my "research priority levels" item:

Instead of having all researched items in one queue, put them in four:
  • On high: always respect the user's order. When adding an item, place it in the last position such that the most items will be completed as soon as possible.
  • On medium: every turn or when adding items, jiggle the order to try to get all items done at the same time. For example, it is not useful of I get my new shields if my lasers are still researching.
  • On low: respect the user, but jiggle when adding items (same logic as high, but below medium, for stuff you don't care about when exactly it is done), e.g. "I need Active Radar sometime before all the auto stuff".
  • On auto: attempt to research *all* technologies. This probably uses the same algorithm as Medium. Starting at the end, add the most expensive per-turn leaf technologies in order, mark a tick off, then treat prerequisites as leaves once they're fully ticked off. The major advantage of this order is so that people don't forget how many prerequisites there are for the endgame ships (the longer the chain of dependent technologies, the earlier auto will put it).
  • On disabled: put technologies here if you don't want to ever research them, e.g. to block the Singularity of Transcendence because combat victory is more fun.
Most likely the strategy for each of the 3 user categories should be customizable to prevent confusion; the strategies I marked are what *I* would use.

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

Re: Many feature requests and a few bugs for 0.4.5 RC1 (most

#11 Post by MatGB » Sat Sep 12, 2015 11:48 pm

For everyone else's benefit, I've gone through the stuff I understand and/or have opinions on and commented there, but some of it is way over my ability to code and some is worth separate threads.
Mat Bowles

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

o11c
Space Krill
Posts: 8
Joined: Fri Sep 11, 2015 11:02 am

Re: Many feature requests and a few bugs for 0.4.5 RC1 (most

#12 Post by o11c » Sun Sep 13, 2015 12:21 am

Expanding on my "new production window" idea:

The current method of "select a planet, then do production of an item there" is almost never what you want. More likely, you want to say "select an item to produce, and *then* choose where to produce it", which requires an entirely different sort of window.

Example use cases:
  • Combat: I need more ships for the South Fleet, build them at the southernmost Mu'Ursh shipyard.
  • Outposts: I want to create an outpost here, where is the nearest shipyard?
  • Terraforming / Gaia Transformation: I want to build one, show me the best place (sort objects by biggest).

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

Re: Many feature requests and a few bugs for 0.4.5 RC1 (most

#13 Post by Dilvish » Sun Sep 13, 2015 4:08 am

o11c wrote:Instead of having all researched items in one queue, put them in four:
I don't think there is any real chance of a system like this being adopted-- it may be personally appealing to you (and you might be able to implement it for yourself if you really want), but I don't see any significant benefit from it; certainly nothing that comes near to justifying the extra complexity of adding three additional queues. I'll note that you didn't even attempt to address how you might divvy up research points between the queues-- there are of course various ways it could be done, but the fact that such a critical point was too much nuisance for you to even try describing should be a clue that the overall proposed system is too complex.
If I provided any code, scripts or other content here, it's released under GPL 2.0 and CC-BY-SA 3.0

Nexus
Space Floater
Posts: 47
Joined: Fri Aug 14, 2015 8:29 pm

Re: Many feature requests and a few bugs for 0.4.5 RC1 (most

#14 Post by Nexus » Sun Sep 13, 2015 3:53 pm

o11c wrote:
  • Combat: I need more ships for the South Fleet, build them at the southernmost Mu'Ursh shipyard.
  • Outposts: I want to create an outpost here, where is the nearest shipyard?
  • Terraforming / Gaia Transformation: I want to build one, show me the best place (sort objects by biggest).
I second this.

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

Re: Many feature requests and a few bugs for 0.4.5 RC1 (most

#15 Post by Dilvish » Mon Sep 14, 2015 1:12 am

Nexus wrote:
o11c wrote:
  • Combat: I need more ships for the South Fleet, build them at the southernmost Mu'Ursh shipyard.
  • Outposts: I want to create an outpost here, where is the nearest shipyard?
  • Terraforming / Gaia Transformation: I want to build one, show me the best place (sort objects by biggest).
I second this.
The last of these is quite easy to manage using the Objects window; I'm rather doubtful you could come up with a more efficient way to accomplish this than by using that.

The second one is a pretty simple visual inspection task on the MapWnd-- human visual pattern matching is pretty darn good.

The first one is a more complex version of the second, which, if your memory fails you would currently require a bit of checking to see which of the shipyards was Mu-Ursh.

Did either of you have any thoughts on what UI interaction could actually provide a better path than is currently possible? Keep in mind that it should not require baking-in content details regarding specific ship hulls/parts (or building types) into the C++ UI (but allowing some level of configuration via information read from config.xml or from common_user_customizations.txt is OK).
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