fix Shields, Detector, Stealth, Engines for AI

Creation, discussion, and balancing of game content such as techs, buildings, ship parts.

Moderators: Oberlus, Committer

Post Reply
Message
Author
Morlic
AI Contributor
Posts: 296
Joined: Tue Feb 17, 2015 11:54 am

fix Shields, Detector, Stealth, Engines for AI

#1 Post by Morlic »

I know updates in future will be done in git and stuff and I can try to repost it there if desired once the migration process is completed and fully sorted out. Anyway, this should do for discussion at least (as I guess the change is somewhat worth debating about).

This is a fix primarily aimed towards the AI. Currently, the "capacity" attribute of shields, detectors, stealth and engines is set to zero and the effects are done by "effectsgroups". This makes it impossible for the AI to read out.
The patch makes sure that the effects of the parts are correctly displayed by the capacity attribute.

1) Is there any reason why engines weren't previously labeled as

Code: Select all

 class=starlaneSpeed
or is this just some legacy stuff nobody cared to update?

2) The fix for the other parts looks kind of ugly and is not really ideal but at least does the trick. If anyone has a (hopefully simple) suggestion for a cleaner solution to make the AI aware of the effects of these parts, please share your ideas.
Hardcoding this stuff into the AI scripts is generally possible but should be avoided because it totally screws the AI up in case of content updates (not like people would automatically adjust the AI scripts as well every single time). Adding extra values for the AI would be possible but requires some more work, I suppose.

/Edit: Patch removed, cf. the thread linked by Dilvish below for updated version and discussion...
Last edited by Morlic on Fri Mar 27, 2015 1:21 am, edited 1 time in total.
If I provided any code, scripts or other content here, it's released under GPL 2.0 and CC-BY-SA 3.0

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

Re: fix Shields, Detector, Stealth, Engines for AI

#2 Post by Dilvish »

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

Code: Select all

 class=starlaneSpeed
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

Post Reply