Refit discount

Time to address some leftovers. Proper refit cost calculation got implemented and scene building code got simplified.

Previously, refit cost was equal to full construction cost. On one hand it was not a big issue since refit and construction points are generated in parallel so there was never a situation where rebuilding ships was more profitable then refitting. But the idea behind whole feature was to have small refit changes result in lower refit cost while major role changes require more investment. In order to achieve that ship designs are now decomposed and compared component by component with following rules in order that would minimize cost:

• Refitting to same equipment type and level is free.
• Refitting to same equipment type but higher level has discount on full new item cost. Discount is 80% for 1 level difference and falls exponentially.
• Refitting to 5 levels higher item of same type or to entirely different type receives no discount.

Items which don't have explicit cost (armor, sensors, reactor and thrusters) are priced at certain portion of hull cost. Unless hull is being upgraded too, then they are free. I may change that in the future with something like if hull receives 80% discount then armor and other items would have 20% discount. Reasoning behind that would be that upgrading hull partially includes retrofitting those parts too.

Scene building improvement is one of the under the hood changes which aren't visible in the game but very visible in project development. With previous approach I had to specify and manage almost every of drawable objects in the scene code. Term "scene" here means major game "screens", ugh, defining one word with another ambiguous one. Galaxy map is one "scene", zoomed in star system is another scene, space combat is third scene and so on. With new approach scenes only have to define what is there to display and let the engine sort out "how" and "when". Yes, they still have to cope with raw numbers like transformation matrices and vertex data values but they don't have to manage them all the time. The underlying engine tracks when low level buffers should be updated and in which order they should be drawn. It also tracks "physical" data for detecting which objects' region has been clicked/tapped by the user, greatly simplifies bookkeeping in galaxy scene. There I previously had a mess of multiple parallel lists (quad trees) for keeping track of fleet visual positions vs their real positions.

And lastly, a friend tested a game and ran into an issue. The issue appears with recent NVidia drivers and is a manifestation of an old OpenTK bug. The bug is fixed in new version but at the moment I can't use it because Stareater works with other component which depends on old OpenTK version. One option is to pray and wait for maintainers to update the component, which given their track record is not going to be soon. After some discussion with OpenTK maintainers I learned that I can make OpenGL in Stareater work without that extra component on top of OpenTK. To achieve that I'd have restructure user interface code but at the moment I'm not keen on large refactoring endeavors. If the component gets updated any time soon that would be great in short term solution. In the long term I will make GUI less and less dependent on it and ultimately get rid of it.