Morlic wrote:Anyway, this should do for discussion at least (as I guess the change is somewhat worth debating about).
Hmm, I guess I didn't anticipate how anxious you would be for this or I would have pointed you more specifically to the previous related discussions (see below). At quick glance it seems this particular solution would leave negative values if you had multiples in a design; plus it seems like it would leave the tooltip looking confusing. We wanted to avoid those things.
Here is the main recent discussion on this issue:
Subject: another way to prevent stacking of shields & detectors We had a fair bit of disagreement at first, and BigJoe is looking at implementing a more complete stacking specification system in the C++ engine that would render this unnecessary. BigJoe has another thread in Programming on that; it may get held up a bit due to some potentially complicated interactions with an EffectsGroup Prioritization scheme that we also envision. Luckily, in that thread I think we did settle on at least a satisfactory interim solution, which is what I had alluded to before but never really pointed you exactly to it. So now I have. In particular, I think the consensus was captured by
Dilvish wrote:If there were also a ValueRef that gave the reference value for a named ship part, then the shield and detector Effects we've been discussing could probably be scripted up referring to that and avoiding any code duplication at all (at least in the cases we've discussed so far).
Geoff proceeded to code up parsing support for a (Part) Capacity ValuRef, which seems to be working fine now. My expectation was to start with one of the patches I had posted in that thread, and then use the new ValueRef in order to eliminate redundant appearances of the fixed capacity value in those previous scripts. I hadn't yet sat down and fully thought through the best way to use the new ValueRef; the simplest way is little more than replacing most references to the fixed capacity, but I think it can be made much cleaner by determining which part present (in the given class) has the max capacity. That probably wont work for the Robotic shields, though, but we can try to deal with them separately. Additionally there was some other discussion in that thread on some changes to make in order to reduce maintenance headache.
As you can see (from the patches in that thread), the approach is in its most basic form quite similar to yours, just with some extra characteristics to deal with redundant parts and to try to give reasonable tooltips. If you want to take that on, that would be great.
1) Is there any reason why engines weren't previously labeled as
or is this just some legacy stuff nobody cared to update?
I don't think there is any particular reason; I don't recall noticing the possibility. Perhaps start a different thread to review/discuss any potential issues related to that.
If I provided any code, scripts or other content here, it's released under GPL 2.0 and CC-BY-SA 3.0