another way to prevent stacking of shields & detectors

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

Moderators: Oberlus, Committer

Message
Author
User avatar
Bigjoe5
Designer and Programmer
Posts: 2058
Joined: Tue Aug 14, 2007 6:33 pm
Location: Orion

Re: another way to prevent stacking of shields & detectors

#16 Post by Bigjoe5 »

Dilvish wrote:The former certainly sounds like a reasonable design restructuring; the latter sounds like a pretty significant/ambitious change whose payoff seems potentially great but also currently rather nebulous (to me anyways). I'll leave further discussion of such plans to you and Geoff.
"Potentially great, but currently rather nebulous" is a great way to describe the payoffs of making part classes scriptable. For that reason, I'd prefer to just hardcode part-classes as either stackable or non-stackable.
Dilvish wrote:Unless you're planning to implement the first idea (part description specifying a stackability characteristic) in the near future (and perhaps even in that case) I think that the currently proposed patch (except possibly using Geoff's new ValueRef above) is the right interim step to take.
I don't currently have time to implement anything (though I may have time to work on FO starting in January). I'm ambivalent about commiting the current patch, since I no longer have a clear enough idea of how significantly it will affect gameplay to weigh it against the potential maintenance burden.
Warning: Antarans in dimensional portal are closer than they appear.

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

Re: another way to prevent stacking of shields & detectors

#17 Post by Dilvish »

BTW, BigJoe, it's been a while, nice to see you back on the boards.
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
Bigjoe5
Designer and Programmer
Posts: 2058
Joined: Tue Aug 14, 2007 6:33 pm
Location: Orion

Re: another way to prevent stacking of shields & detectors

#18 Post by Bigjoe5 »

Dilvish wrote:BTW, BigJoe, it's been a while, nice to see you back on the boards.
It has, hasn't it? Thanks. :)
Warning: Antarans in dimensional portal are closer than they appear.

User avatar
Geoff the Medio
Programming, Design, Admin
Posts: 13587
Joined: Wed Oct 08, 2003 1:33 am
Location: Munich

Re: another way to prevent stacking of shields & detectors

#19 Post by Geoff the Medio »

Dilvish wrote:I don't see decoupling display of capacity from the thing itself to be a solution, it looks to me like a crude hack that only accomplishes only a small portion of the functionality and adds a different error-prone maintenance issue whose relative plusses and minuses balance out to a very similar error risk.
The idea is that it's probably easier to script the functionality you want if you don't also have to worry about working around an autogenerated effectsgroup that complicates the scripting. Decoupling would mean you could tell the UI to use a particular fixed value for sorting, and then use probably-simpler scripts to determine the actual in-game effect of a part. The probably-simpler script could be a lot easier to maintain... For example, you could use a stacking group to prevent stacking with the same type of part, instead of having to use a more complicated calculation to undo all but one of the autogenerated effects from multiple copies of a part. Or, the effects could be set up so that the actual strength of a (eg. shield) part is the nominal strength divided by the total number of shield parts present, while leaving the nominal / UI indicated strength the same as if there was just one of the part present.

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

Re: another way to prevent stacking of shields & detectors

#20 Post by Dilvish »

Or, the effects could be set up so that the actual strength of a (eg. shield) part is the nominal strength divided by the total number of shield parts present, while leaving the nominal / UI indicated strength the same as if there was just one of the part present.
With the American Thanksgiving holiday nigh, I will share a bit of somewhat-related folk wisdom that's part of this cultural background (one that in fact is generally recognized as having continued validity although of course a game-theory risk analysis can make the calculus quite a bit more complex), which is, "A bird in hand is worth two in the bush."

Although of course there can be good reasons to simply discard a gangrenous or otherwise sickly bird, it seems to me that in the workings of our development there is a penchant for prematurely discarding the reasonable-but-not-ideal bird-in-hand in favor of pursuing the plumper/flashier bird glimpsed across the field, which unfortunately often never makes it into our bag, at least not that season. It's easy to think, "Putting this bird in the bag will get the bag messier than it needs to be," and, "we can just leave this caught bird-in-hand lying on a stump here, and if we give up on the nicer one we can come back for this," and, "if we let the hunters put the just-reasonable bird in their bag, they might put less effort into pursuing the really nice one." Those thoughts probably do have a grain of truth to them, but I would submit that it is such a small grain that it doesn't well support the full assertions, nor recognize their cost. Cleaning the bag after two birds is not much more difficult than cleaning after one. Also, after the discarded bird has been left weathering on a stump for a while it's much less appealing to head back to collect it, and people start to forget just where that stump was and even about the discarded bird at all. And then we have no bird at all for supper tonight.

Of course, folksy wisdom is rarely if ever dispositive, and perhaps in this case the bird-in-hand was sickly; it was a scrawny enough bird I won't argue the point. But I really do wish I would see these broader considerations at least acknowledged more often.
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
em3
Vacuum Dragon
Posts: 630
Joined: Sun Sep 25, 2011 2:51 pm

Re: another way to prevent stacking of shields & detectors

#21 Post by em3 »

Hm... wouldn't the more to-the-point implementation be to add support to FOCS for effects like "set the max shield strength of the ship to the maximum of its max shield strength and the strength of this part"?

This way, only one (and best) shield part would work, yes.

I'm not saying it's simplier coding-wise, I'm saying it might be more obvious to the content scripter...

Although, I guess, this would not be helpful with stealth, as there is some base stealth value from the hull, right?
https://github.com/mmoderau
[...] for Man has earned his right to hold this planet against all comers, by virtue of occasionally producing someone totally batshit insane. - Randall Munroe, title text to xkcd #556

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

Re: another way to prevent stacking of shields & detectors

#22 Post by Dilvish »

em3 wrote:Hm... wouldn't the more to-the-point implementation be to add support to FOCS for effects like "set the max shield strength of the ship to the maximum of its max shield strength and the strength of this part"? This way, only one (and best) shield part would work, yes. I'm not saying it's simplier coding-wise, I'm saying it might be more obvious to the content scripter... Although, I guess, this would not be helpful with stealth, as there is some base stealth value from the hull, right?
It's already quite possible to do this (and has been done for quite some time) entirely in FOCS if one leaves the part capacity at zero. But that has obvious downsides. The C++ engine treatment of such parts is currently to stack the capacties of parts in these classes, so with nonzero capacities the FOCS gets a bit bulky to undo that stacking. BigJoe's proposal above is to add a new 'stackability' specifier at least for shield, detector, and stealth parts which seems to me would have the same meaning as what you describe, and which would let the scripts be leaner.
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
em3
Vacuum Dragon
Posts: 630
Joined: Sun Sep 25, 2011 2:51 pm

Re: another way to prevent stacking of shields & detectors

#23 Post by em3 »

Dilvish wrote:It's already quite possible to do this (and has been done for quite some time) entirely in FOCS if one leaves the part capacity at zero. But that has obvious downsides. The C++ engine treatment of such parts is currently to stack the capacties of parts in these classes, so with nonzero capacities the FOCS gets a bit bulky to undo that stacking. BigJoe's proposal above is to add a new 'stackability' specifier at least for shield, detector, and stealth parts which seems to me would have the same meaning as what you describe, and which would let the scripts be leaner.
Ah... I get it. The part capacity is applied to the design by default, not because of effects. It's done that way so that the preview would show the correct value, right?

Well, as I see it, it seems silly that the game engine is responsible for applying the part bonus but the effects engine is responsible for bonus filtering/stacking. I think that either the bonus should be applied by an effect or the stacking implemented in engine itself. It seems like a common enough feature...
https://github.com/mmoderau
[...] for Man has earned his right to hold this planet against all comers, by virtue of occasionally producing someone totally batshit insane. - Randall Munroe, title text to xkcd #556

User avatar
Geoff the Medio
Programming, Design, Admin
Posts: 13587
Joined: Wed Oct 08, 2003 1:33 am
Location: Munich

Re: another way to prevent stacking of shields & detectors

#24 Post by Geoff the Medio »

em3 wrote:The part capacity is applied to the design by default, not because of effects.
Not really. Scripting "capacity = 5" or similar in a part definition just adds an extra effectsgroup that adds 5 (stacking) to the appropriate meter, just the same as if it had been written out in the part's effectsgroups.
It's done that way so that the preview would show the correct value, right?
More so it's done so that the UI has a part strength number it can use in various places, which is equivalent to what the effects of the part actually do, without needing to simulate the parts effects or interpret the effectsgroups that are scripted out explicitly.
I think that either the bonus should be applied by an effect or the stacking implemented in engine itself. It seems like a common enough feature...
It's not a matter of being common... but there are many possible forms of stacking. Hence, I have above suggested decoupling any effectsgroups from the scripted / displayed capacity, and actually implementing it all using explicitly scripted effectsgroups that can be made to do exactly whatever any given part needs.

Scripting using max/min operations is potentially problematic in a some ways that stacking groups can avoid. In particularly, any additive or multiplicative effects could give different results depending on their order of application relative to the max/min test. Stacking groups can work better with additive effects applied in any order (but do still have issues with multiplicative effects).

User avatar
Bigjoe5
Designer and Programmer
Posts: 2058
Joined: Tue Aug 14, 2007 6:33 pm
Location: Orion

Re: another way to prevent stacking of shields & detectors

#25 Post by Bigjoe5 »

Geoff the Medio wrote:[T]here are many possible forms of stacking.
Those hypothetical forms of stacking aren't in use at the moment, as far as I know. We only have "strongest part wins", and "fully stacking". The mere fact that there are "many possible forms of stacking" is not an argument against abstracting out "stackability" as a reusable concept. In fact, it's an indicator that we should do so, since doing so leaves us open to implementing other forms of stackability in the same way, as the need arises.
Warning: Antarans in dimensional portal are closer than they appear.

User avatar
Geoff the Medio
Programming, Design, Admin
Posts: 13587
Joined: Wed Oct 08, 2003 1:33 am
Location: Munich

Re: another way to prevent stacking of shields & detectors

#26 Post by Geoff the Medio »

Geoff the Medio wrote:Patch attached. Seemed to run without errors, but not really tested.
Here's an additional patch, which makes it possible to use an abitrary ValueRef as the value for each object when writing a Statistic ValueRef. This lets the ComplexValueRef used to count the number of a particular part on a ship design be used as the value in a Sum statistic, with a reference to LocalCandidate.DesignID to specify what ship design to count the parts of. This is used in a modification of the COUNT_OF_LOCAL_ROBOTIC_INTERFACE_SHIELDS macro to actually count the number of such parts, rather than the number of ships that have designs with such parts. Comments / testing would be good...
Attachments

[The extension patch has been deactivated and can no longer be displayed.]


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

Re: another way to prevent stacking of shields & detectors

#27 Post by Dilvish »

Geoff the Medio wrote:Here's an additional patch... Comments / testing would be good...
Here's some comments/questions. As a general comment, it does seem like a useful new ValueRef. My only specific comments are of the ship_parts.txt changes.

I'm not understanding the change to the defense grid-- it looks to me like with one grid part on a ship you'd get a shield value of 3, with 2 grid parts you'd get a shield value of 2, etc. I haven't actually tested it though, am I misunderstanding?

As for the change to the COUNT_OF_LOCAL_ROBOTIC_INTERFACE_SHIELDS macro, I guess your new version conforms better to the plainest meaning to be parsed from the tag "COUNT_OF_LOCAL_ROBOTIC_INTERFACE_SHIELDS", but I don't think that's the intent-- it probably just looked too cumbersome to have the tag be more fully descriptive. I think that it was intended that multiple shields within a ship did NOT stack with each other, that the stacking was only ship-to-ship and thus based on a ship count. I also think that the hull requirement was intended. If anything, given that HasTag "ROBOTIC" is in the location requirement, it can probably come out of the EffectsGroup scope (based on some quick musing but not a truly thorough consideration), but it seems to me that the hull restriction should stay.
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
Geoff the Medio
Programming, Design, Admin
Posts: 13587
Joined: Wed Oct 08, 2003 1:33 am
Location: Munich

Re: another way to prevent stacking of shields & detectors

#28 Post by Geoff the Medio »

The ship_parts.txt changes aren't meant to be final... They're mainly to illustrate new ValueRefs. For the defense grid, there had been discussion of making the actual bonus decrease depending on the number of parts present, so as to work around the autogenerated bonus increase from the scripted capacity / strength of parts. (Which as above, I think should be removed... but that's beside the point here...)

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

Re: another way to prevent stacking of shields & detectors

#29 Post by Dilvish »

Geoff the Medio wrote:They're mainly to illustrate new ValueRefs. For the defense grid, there had been discussion of making the actual bonus decrease depending on the number of parts present, so as to work around the autogenerated bonus increase from the scripted capacity / strength of parts.
Ok, but I didn't understand how this particular decrease actually matched what any of us wanted, which left me confused. If I think of it as "an example usage purely for testing purposes," then I'm not quite so confused, but it would help to know what you expect the result to be, or else I can't be very confident about any testing I might do. Did my characterizations above, of what it looked like the results would be, match your expected results?
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
Geoff the Medio
Programming, Design, Admin
Posts: 13587
Joined: Wed Oct 08, 2003 1:33 am
Location: Munich

Re: another way to prevent stacking of shields & detectors

#30 Post by Geoff the Medio »

Dilvish wrote:...it would help to know what you expect the result to be, or else I can't be very confident about any testing I might do.

Code: Select all

Part
    name = "SH_DEFENSE_GRID"
    ...
    capacity = 0
    ...
    effectsgroups =
        EffectsGroup
            scope = Source
            activation = Source
            stackinggroup = "SHIELD_PART_STACK"
            effects = SetMaxShield Value + 4 -
                PartsInShipDesign name = "SH_DEFENSE_GRID" design = Source.DesignID
    ...
This should change the strength of shields from a defense grid to be 4 minus the number of defense grid parts in the design. There was some discussion about reducing the effectiveness of parts in a manner similar to (but not exactly like) this. The point was to work around the automatically-generated fixed-value shield strength increase from the scripted part capacity value.

Post Reply