Local Solar System Management with hard made mock-up!

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
wobbly
Cosmic Dragon
Posts: 1880
Joined: Thu Oct 10, 2013 6:48 pm

Re: Local Solar System Management with hard made mock-up!

#16 Post by wobbly »

rafafelp wrote: Sat Aug 07, 2021 9:58 pm Adding my two cents: I would also prefer to have production on a dedicated full screen, like research or ship design. Apart from the "rally to" option, seeing the map isn't essential.
Being able to see and navigate the map is important when building stuff like scanning facilities and interstellar lighthouses.

rafafelp
Space Krill
Posts: 9
Joined: Wed Jan 29, 2020 3:06 pm

Re: Local Solar System Management with hard made mock-up!

#17 Post by rafafelp »

That's true, I hadn't thought of that. And also to decide where to produce ships. And seeing the supply lines or lane jumps can be important for some things. But on the other hand, the current interface isn't easy on a small screen.

User avatar
stpa
Space Kraken
Posts: 157
Joined: Mon Mar 12, 2018 1:08 pm

Re: Local Solar System Management with hard made mock-up!

#18 Post by stpa »

while i am kind of sorry for the way the discussion has digressed into unveiled aggressivitude, i kind of can see the several sides here, and i can detect no unsurmountable obstacles to try and reconsile when i'm about to give the production screen a makeover anyway. but what i also somewhat fear are the endless discussions that will ensue in the according pullrequest(s) no doubt ;)~

yeah, programming is hard work indeed. but some may enjoy that type of work and do it as volunteers without pay in their free time, so that others again can spend their free time playing an enjoyable game as a result of that leasure work, hopefully. so lets see if i can maybe come up with some solution to the scarcity of screen space on the one hand side, and the wish for more concise contextual information to be displayed on the other hand side. while also coming up with stuff relevant to my own gaming experience and enjoying myself while doing that on the third hand side.

User avatar
Oberlus
Cosmic Dragon
Posts: 5715
Joined: Mon Apr 10, 2017 4:25 pm

Re: Local Solar System Management with hard made mock-up!

#19 Post by Oberlus »

stpa wrote: Sun Jan 30, 2022 3:45 pm on the third hand
I knew you were Hhhoh.

User avatar
stpa
Space Kraken
Posts: 157
Joined: Mon Mar 12, 2018 1:08 pm

Re: Local Solar System Management with hard made mock-up!

#20 Post by stpa »

ho-ho-home-office? hhhohhoo who calls me a hhhoe? ;P nah that was referring to the Pierson's Puppetteers .. or was it the Moties from the Mote in God's Eye .. anyway to master Lary Niven

psychlops
Space Krill
Posts: 7
Joined: Mon Jan 31, 2022 3:59 am

Re: Local Solar System Management with hard made mock-up!

#21 Post by psychlops »

very late to the party on this discussion but there are a few points that occurred to me right away.

First, the OP's suggestion is already basically implemented because of the color coding that shows what is being produced at the currently selected planet. If you really need "system production" (why?) as opposed to planet production then maybe something simple like changing the background color of all production on planets from the currently selected system in the global window. It's a much much smaller coding hurdle and gives the same info. If there was a more "minimalist" view of global production (i.e. more line with less detail) the entire problem would be solved.

Second, you definitely do not want a dedicated screen for production because unlike research production is tied to the map. By comparison research is almost an abstract whereas production is specific to the location and viewing the map while deciding what to produce is fairly critical to the process. If you really want something "larger" for production it's pretty easy to resize the windows and hit the locks. I can post a screen shot of an example if needed.

Third, there is no default screen resolution for PC's and there never has been. I started a web development company back in 1995 and we built thousands of websites between then and 2005. I still make web based applications and I've been following the trends in screen resolutions for 25+ years. There's never been a single resolution with even 50% market share in that entire time. Making claims based upon what you think is reality (default screen resolution) as if that's an actual fact is a really bad way to support your position. Currently 1920 x 1080 is the most common resolution by a small amount but it's less than 25% of users, so obviously anyone who designs anything to be used by the general public has to take into account a wide variety of screen sizes. Even if you're not a coder you can see the game allows for a WIDE variety of resolution sin the options panel.

Fourth, the idea that this suggestion would be a bigger improvement than anything that adds "More gameplay" is pretty hard to understand. It's a non trivial amount of coding for a very minute gain in UI that likely isn't even on the radar for the majority of players. I personally don't see any significant benefit and certainly not enough benefit to make the juice worth the squeeze. The coders have done a really good job if giving lots of information in subtle ways. Things like underling systems with ship building capability, italics for advanced shipbuilding/repair capability, the double circles on systems with colonies/outposts, various icons for different types of ships and quantity of ships on the map. More information without having to make any clicks is a HUGE upside in minimizing the time spent managing your empire.

Fifth, it definitely would take up more real-estate for a window that would quite often be empty or nearly empty. If it's not a separate window the windows are resizable and I keep the production available window as small as possible so as to not interfere with the planets, the production or the sitrep windows and still obscure as little map as possible.

I understand the production window gets long and scrolling is no fun, I think the far more beneficial solution is to make a minimalist view of global production. Make the icon 1/3 the existing size, make the bar half as long as it currently is and put the icon, progress bar and at location all on one line. Maybe put the text for what the item is on top of the bar. You get most of the information in 1/3 current vertical real estate (3 times as many items on the screen at once) and you could toggle the icon's background color to a user selected color for "current system" to go with the blue highlight for current planet. It's not a huge hurdle to code, would give more info in the same amount of space and won't add any new panes to cover the map. Kills a lot of birds with one stone.

What language is being used for the display elements like the production window? Is it Python? I'm definitely a novice at Python but I've written more than hundred thousand lines of php as well as about 10-12 other languages so maybe I can figure it out if someone would be willing to take a look at what I did after I did it.

User avatar
Oberlus
Cosmic Dragon
Posts: 5715
Joined: Mon Apr 10, 2017 4:25 pm

Re: Local Solar System Management with hard made mock-up!

#22 Post by Oberlus »

I endorse each one of your points, very well explained.
psychlops wrote: Wed Feb 02, 2022 6:27 am What language is being used for the display elements like the production window?
I think all UI stuff is coded in C++.
psychlops wrote: Wed Feb 02, 2022 6:27 am maybe I can figure it out if someone would be willing to take a look at what I did after I did it.
Please, do. If you get into this and make a PR, I'm sure Geoff will review it and help out with C++ doubts. Also I think The Silent One has done many UI coding and could also help out.

Ophiuchus
Programmer
Posts: 3433
Joined: Tue Sep 30, 2014 10:01 am
Location: Wall IV

Re: Local Solar System Management with hard made mock-up!

#23 Post by Ophiuchus »

Oberlus wrote: Wed Feb 02, 2022 6:42 am
psychlops wrote: Wed Feb 02, 2022 6:27 am maybe I can figure it out if someone would be willing to take a look at what I did after I did it.
Please, do. If you get into this and make a PR, I'm sure Geoff will review it and help out with C++ doubts. Also I think The Silent One has done many UI coding and could also help out.
doing a short analysis for kick-starting:

UI/ProductionWnd.cpp class ProdQueueListBox takes care of the queue items, e.g. ItemRightClickedImpl in that class creates the popup-menu per item.

It extends the UI/QueueListBox, which does part of the layout (QueueListBox::Render draws the white "drop point line" when you move items in the queue).

And that QueueListBox extends the ListBox of our generic widget framework GiGi defined in GG/src/ListBox.cpp. So the documentation of the functions can be found in the header file in GG/GG/ListBox.h

ProductionWnd contains the QueueProductionItemPanel which does the relevant Layout (the panel is created and wrapped in a QueueRow which has access to the queue element). Probably the best place to start.
Any code or patches in anything posted here is released under the CC and GPL licences in use for the FO project.

Look, ma... four combat bouts!

User avatar
stpa
Space Kraken
Posts: 157
Joined: Mon Mar 12, 2018 1:08 pm

Re: Local Solar System Management with hard made mock-up!

#24 Post by stpa »

drag & drop type of producible items has to match that of the list of produced items, in BuildDesignatorWnd.cpp:544

Code: Select all

SetDragDropDataType(BuildDesignatorWnd::PRODUCTION_ITEM_DROP_TYPE
and then needs to react somewhere by replacing the dragged out line with a new one or just hit refresh on list of producible items, and generate a productionrun quantity one current planet at the dragged at position in the production list.

edit; probably some sort of

Code: Select all

void ChildrenDraggedAway(const std::vector<GG::Wnd*>& wnds, const GG::Wnd* destination) override { ... }
this is where i was starting on the oldest of the referenced tickets, but i do have a normal working live as well so this here is kind of not my full time focus here

Ophiuchus
Programmer
Posts: 3433
Joined: Tue Sep 30, 2014 10:01 am
Location: Wall IV

Re: Local Solar System Management with hard made mock-up!

#25 Post by Ophiuchus »

stpa wrote: Thu Feb 03, 2022 1:39 pm drag & drop type of producible items has to match that of the list of produced items, in BuildDesignatorWnd.cpp:544
isnt the BuildDesignatorWnd the one where the list of available build items is shown? and i guess it holds the reference to the build item which currently dragged from there.

Also drag and drop of production items from that list does nothing useful at the moment for me (can drag it, but cant drop it on the queue), i think that worked in the past.
Any code or patches in anything posted here is released under the CC and GPL licences in use for the FO project.

Look, ma... four combat bouts!

User avatar
stpa
Space Kraken
Posts: 157
Joined: Mon Mar 12, 2018 1:08 pm

Re: Local Solar System Management with hard made mock-up!

#26 Post by stpa »


Post Reply