You've essentially answered the question you posed.
You want one of the BDSM family of languages, like C++, C#, or Java. ;-)

I wasn't aware I posed any question..

Sorry I thought I was responding to Deimos. I think the @ thing threw me off. ;-)

You quoted flumpy's comment to David Haley, but you were responding to me? You need another coffee. :wink:

It doesn't really help that deimos is using the avatar that flumpy used for a while, though. :wink:

Lawl, I knew something was mixing me up. That's what it was.

I can't make much sense of your actual numbers, there, but I think I see what you're saying: keep track of the unmodified strength score, and then, if something (say) doubles strength, then instead of actually doubling the current value, it adds on an amount equal to 100% of the unmodified score, and subtracts that amount again when the effect wears off.

That would ensure that you end up with the correct value again when everything has worn off; but what happens if the unmodified strength score changes? Suppose you are wearing a magical ring which doubles your strength. Your unmodifed strength is currently 5, so the ring doubles it to 10. You then gain some XP and levels and do some training (while still wearing the ring) and your unmodified strength score rises to 8. You've been wearing the ring all this time, so your doubled strength score should now be 16 - but because the spell effect hasn't been modified, instead your "doubled" strength is only 13 (8 + 100% of what it was when you put the ring on). To get your strength to the right value you would need to take the ring off and put it back on again.

Obviously you could re-evaluate the magnitude of the magical effect every time the character's unmodified strength changes; but that is precisely the sort of bad encapsulation that we're trying to avoid! If you do that then the code which changes unmodified strength has to be aware of the possibility that there may be strength-modifying magical effects active; and the same applies to anything else that could be affected by anything.

To be honest, though, your question suggests that you haven't altogether grasped the point I was making. The point is that we need a way to dynamically modify the behaviour of objects in an arbitrary way, without the object in question having to be aware that this possibility exists. Modifying the apparent value of a single number is one, particularly trivial example of this; it's the general "modifiability principle" which matters.

I disagree that completely arbitrary modification is necessarily a desirable goal, however I don't think it matters anyhow. The point remains that you need to be careful when doing any form of dynamic modification, even predictable ones. We've already seen that even if your end result is correct, the intermediate stages can be all messed up. And you only reinforced that problem with the example of the underlying value changing while it is being affected.

One of the benefits of the system I'm suggesting is precisely that it is completely unaffected by the underlying value changing. And I'm not aware that there is any messing up of intermediate stages, either. It's designed to avoid those issues.

Well, you don't need the full system you're proposing (with completely arbitrary modification of anything) in order to correctly handle the transitional case and the underlying values changing. So yeah, your system addresses that, but IMHO it's not necessarily something you'd want. It depends on a bunch of stuff.

The intermediate state problems are caused by simply tracking current and original. So indeed your system doesn't suffer from them (nor was I trying to say that it did).

To be clear, my point was that the statement "you need a way to dynamically modify the behaviour of objects in an arbitrary way, without the object in question having to be aware that this possibility exists" is making a stronger statement than is needed to address this particular problem. In other words, the question doesn't show that your system is misunderstood: the question showed that the problem was misunderstood.

Well, that is obviously the case; but the business of modifying a character's strength was intended merely as the simplest example I could come up with of a scenario where such a system is useful (and which illustrates some of the problems you run into without it). Clearly, the potential applications of such a system are almost literally infinite.

Indeed! And that's exactly why it's unclear to me that it's actually a desirable goal. :tongue:

Yeah, 'cos making a system flexible and easily extensible with a minimum of coding effort is clearly something to be avoided.
:rolleyes:

I know that you're being sarcastic, but I also would hope that you know you're making a nice little straw man. :smile:

As an aside, I can't imagine an effect that doubles strength would scale well at all. Throw in a couple of these effects and suddenly you've got some mad craziness.

That said, wouldn't the safest way to solve this dilemma be to save the unmodified stat score and effect math? So instead of the mud calculating "aha, pc has 5 str, so now that pc has quaffed a potion of str*2, we save an aff of str+5," you say "pc has str 5 and a str*2 effect." You then save a current_str score and run update_str() that recalculates this value every time something happens that affects str. Just remember to calculate the multiplication ones before the addition ones unless you deliberately want to make me facepalm.
:biggrin:

That's basically what shasarak has been suggesting – although in a far more complex form – and is what I suggested (more or less) in post #56.

What I got from what shasarak was saying is that it would break encapsulation for update_str() to have to know about any magical effects, whether you're actually saving the math or the values. I could be completely wrong, though, since I think these concepts have become sufficiently hard enough to describe without a whiteboard or something :tongue:

Shasarak doesn't like the fact that you need to know which attributes are modifiable in order to list the modifications. So he doesn't like the idea of a map from "strength" to "strength effects". He likes worlds in which absolutely everything is arbitrarily modifiable without any prior knowledge of anything other than intercepting method calls. Whether or not you like such worlds as well is a determination I'll leave to you. :smile:

If you say so. I guess I need a DH phrasebook. :tongue:

vs.


There's your phrasebook where the same idea is expressed. :tongue: