Page 2 of 2

Re: Auto better troop pods

Posted: Sat Feb 03, 2018 6:11 pm
by Ophiuchus
Dilvish wrote:I like this last suggestion, improving the UI, much better as an avenue for alleviating the difficulty of playing with limited hardware support than I do the idea of content being constrained by not-so-common hardware constraints. (Can I suggest you buy a mouse? :D )
I also could fetch my trackball from the developer station in my working room. Mouse is freaking uncomfy to use when lying on a couch.

This is definitly not a hardware issue. I tried to find a expression for "I think that any UI which has bad keyboard support sucks".
And most people use a laptop in order not to have to fiddle around with extra hardware or cables.

Re: Auto better troop pods

Posted: Sat Feb 03, 2018 6:18 pm
by Ophiuchus
Dilvish wrote:I have also long mulled a design obsoleting system....I'd like to have a ranked, transitive obsoleting process (I suppose the ranking could just be taken from the order that obsolete designations are made, that idea has just come to me and I think would really do a lot to ease implementation) and so that the BuildWnd would always should the non-obsolete designs able to be built at that location. So that if you build an asteroid reformation processor somewhere and obsolete zortrium, but then have an isolated system where you can't build the rock armor, it would still show you designs with zortrium.
Would be great to unfilter obsolete designs if the current designs cant be build locally.
The automatic way you suggest sounds interesting but definitly not so easy. Taking obsoletion order does make a lot of sense, but where in obsoletion history do you stop?

I also think your system would be compatible with the part obsoletion (which effectivly means to obsolete all current designs with the part type now). So it could be implemented on top of it.

Re: Auto better troop pods

Posted: Sun Feb 04, 2018 12:39 pm
by LGM-Doyle
I have posted a PR addressing some the UI concerns raised by Ophiuchus.