Functions and variables/strings that are set by other stuff

[aVENGER]

Maybe I'm misunderstanding functions, but I was under the impression that they will always use the default values for all variables and strings if you don't specifically set them when defining the function. However, I just noticed that when I use this block:

Code:

COPY_EXISTING ~spwi307.spl~ ~override~
  READ_LONG  0x64 "abil_off"
  READ_SHORT 0x68 "abil_num"
  READ_LONG  0x6a "fx_off"
  FOR (index = 0 ; index < abil_num ; index = index + 1 ) BEGIN // cycle through abilities
    READ_SHORT  ("%abil_off%" + 0x1e + (0x28 * "%index%")) "abil_fx_num"
    READ_SHORT  ("%abil_off%" + 0x20 + (0x28 * "%index%")) "abil_fx_idx"
    FOR (index2 = 0 ; index2 < abil_fx_num ; index2 = index2 + 1) BEGIN
      READ_SHORT ("%fx_off%" +        (0x30 * ("%index2%" + "%abil_fx_idx%"))) "opcode"
      READ_LONG  ("%fx_off%" + 0x0e + (0x30 * ("%index2%" + "%abil_fx_idx%"))) "duration"
      PATCH_IF ("%duration%" = 300) BEGIN
        WRITE_LONG ("%fx_off%" + 0x0e + (0x30 * ("%index2%" + "%abil_fx_idx%"))) 7200
      END
      PATCH_IF ("%opcode%" = 174) BEGIN
        WRITE_BYTE ("%fx_off%" + 0x02 + (0x30 * ("%index2%" + "%abil_fx_idx%"))) 2 // target: preset target
      END
    END
  END
BUT_ONLY_IF_IT_CHANGES

before this function:

Code:

COPY_EXISTING ~DEMBAL01.CRE~ ~override~                                            // Balor
LAUNCH_PATCH_FUNCTION ~ADD_CRE_EFFECT~                                             // Starts FUNCTION call (add new creature effect built-in function)
INT_VAR
opcode = "300"                                                                     // effect: #300 (NPC Bump)
target = "1"                                                                       // target: 1 (self)
timing = "9"                                                                       // timing mode: 9 (permanent after death)
parameter2 = "1"                                                                   // param2: 1 (constant value)
probability1 = "100"                                                               // probability1: 100%
STR_VAR
"effsource" = ""                                                                   // effsource: none
END
BUT_ONLY

The embedded effect will now have a duration which was read while copying that spell above rather than a value of 0. The same happens for any strings which match the functions strings by name. Is this intended? Note: this happened with WeiDU 211 as well, so it's not specific to the new version.

[the bigg]

I believe somebody asked for this retarded behavior multiple times and I yielded (meaning I can't fix this without breaking people's mods). The "ideal" workaround is to use prefixed variable names in shared macro/function code and unprefixed variable names in personal code.

[aVENGER]

The "ideal" workaround is to use prefixed variable names in shared macro/function code and unprefixed variable names in personal code.

Yup, that's pretty much what I ended up doing. Thanks for the clarification.

[aVENGER]

BTW, how about a LOCAL_PATCH_FUNCTION and LOCAL_ACTION_FUNCTION  (or some such) which don't use variables and strings pre-set by other stuff?

[the bigg]

You can't fight stupid with stupid and expect to have something smart 

[aVENGER]

But my request is less err... stupider.

[devSin]

I can't even think of any workaround to have non-stupid functions included in WeiDU now that you've let them past the gates...

[Mike1072]

I've despaired of this functionality ever being implemented, but do we know that any mods rely on the initial behaviour introduced in v209?  I didn't think more than 4 or 5 people were actually doing anything with functions.

If "fixing" it isn't a reasonable solution, couldn't LAF/LPF be deprecated so that they still existed, but with LAF2 and LPF2 added to take over their place in general usage, like aVENGER suggests?

[the bigg]

I prefer quirky behavior (which would be by no means something new to WeiDU) to having 20 different variants of the same command (otherwise you quickly reach PHP-stupid level).

[devSin]

Better, I think, just to deprecate the stupid built-in functions that have variables like this, now that we're stuck with them.

But I guess all this shit would have to be refactored and recoded someday, so who really gives a shit how much it sucks now, right.

And really, any other non-ass method would be ADD_EFFECT and the stupid thing would figure out what the hell to do its own damn self. You'd think there wasn't any way to figure out what the hell kind of resource you're working with, not have five million fuckillion actions to do the same damn thing but to different resource types.

And who the hell is this pamela123 moron? Log in or die already, ass-hat. Bitch fell asleep at the keyboard or something.

Oops, this is the public forum. ;-)

[GeN1e]

I wouldn't care. If I do a whacky klocked tie of vars you'd expect me to have enough brain to remember about the abovementioned quirk before I start wasting the disc space away. And if not then it's equally easy to remember to change a name that happens to be called the same name as one in the function. Irritating, perhaps. Vital, not really.

Bitch fell asleep at the keyboard or something.

Can you sleep over the keyboard for three days in a row? I wager not.

[devSin]

Three days?

I kid you not, she has been in a state of "Logging into the forum" for MONTHS. Probably some stank ass corpse in front of a computer somewhere in the world with the PPG login screen still up. :P

[temujin.]

what is wrong with you, dev?
You seem unusually angry...   

lemme guess... it was *you* who made this feature request, wasn't it? 

[devSin]

I'm always this bitter, but I do it with a smile on my face. Misery and comedy, bitches, that's how I roll.

Personally, I hope it was aVENGER. That would be some sweet irony.

[aVENGER]

Personally, I hope it was aVENGER. That would be some sweet irony.

Hehe, nope, I'm afraid I just started using functions a week ago or so.

Anyway, I'd like a function which behaves in a rational way mainly due to the fact that there are already tons of macros and regular code which use the standard designations for variables and which could therefore interfere with functions. Now, while recoding a smallish mod like aTweaks to use prefixes for that stuff is reasonable, doing something like that for, say, the Fixpack would be a nightmare I bet.

[GeN1e]

Actually, screw what I've said before. Have just recalled a thing, and functions being 100% local is far better then otherwise.

[Nythrun]

I can't imagine that the "Hey everybody! Recode every mod that's ever used variables to use absurd variable names! We need it to preserve absurd function behavior!" campaign is going to win the hearts and minds of the common folk.

Probably easier than a recode would be to staple a DEFINE_ACTION_MACRO rr#_init_vars BEGIN OUTER_SET opcode = default ...END LAUNCH_ACTION_MACRO rr#_init_vars call before you start using the shipped functions. Probably better, too, since functions can't clear external arrays.

[Miloch]

I believe somebody asked for this retarded behavior multiple times and I yielded (meaning I can't fix this without breaking people's mods).

Seriously though, who? And more to the point, is the retarded variety actually used to any effect in any released mods?

[the bigg]

Seriously though, who? And more to the point, is the retarded variety actually used to any effect in any released mods?

I can't tell with grep-fu, so I'll assume some do.

[aVENGER]

To summarize, the consensus of all active modders who are actually using functions in like released mods and stuff is that we want them to be localized. OTOH, there's that one obscure guy with an unknown mod who wanted functions to be global for some odd reason. Right... 

Still, in the spirit of maintaining maximum compatibility, have the chances of having a LOCAL_PATCH_FUNCTION and LOCAL_ACTION_FUNCTION gotten any better?

[devSin]

To summarize, the consensus of all active modders who are actually using functions in like released mods and stuff is that we want them to be localized. OTOH, there's that one obscure guy with an unknown mod who wanted functions to be global for some odd reason.

Maybe I'm missing something, but I can't find anybody who ever wanted this?

Bigg may be recalling people complaining about this multiple times, but I didn't see the "obscure" nut (here at PPG at least) asking for the dumb behavior.

[devSin]

How about adding ++ (I think probably without the pre/post logic) and -- operators? (I have this sinking "no the parser won't like it" feeling...)

I frowned the last time somebody asked Wes, but it's hard to argue why the hell not anymore. As generic assignment, of course, or maybe it could be special part of the FOR action (really, where else do you need it here).

Is there any way to return THIS as the where of a write action for use in a pe? (Go ahead and say no; I couldn't see an easy way to get this.) DATATYPE_AT is promising, but it's retarded to WRITE here THE_VALUE_THATS_ALREADY here OPERATIONS. WRITE here THIS + 1 would blast a hole through my underwear it's so hot.

[temujin]

I believe somebody asked for this retarded behavior multiple times and I yielded (meaning I can't fix this without breaking people's mods).

Seriously though, who?

OTOH, there's that one obscure guy with an unknown mod who wanted functions to be global for some odd reason. Right... 

Maybe I'm missing something, but I can't find anybody who ever wanted this?

well, Gents, judging by the overwhelming (i.e. zero) evidence we've gathered so far, it's a safe bet to conclude this 'somebody' is none other than our resident Italian Stallion, Biggie himself.

Looks like he just pulled a Baronius and made an unsuccessful attempt in redirecting the blame somewhere else.   

Mystery solved.

[the bigg]

Alright, I have decided I have spent enough time arguing with you all. Sane behavior going in.

OK for ++ and --. They'll (obviously) be patches rather than c-style values. Do you want prefix or postfix notation? I expect doing both would be redundant and generate a grammar ambiguity.

THIS: OK.

[devSin]

Just postfix (it's probably going to end up being OK separated by whitespace, though, isn't it? make sure to document it only as value++ and value-- to try to prevent people doing that ;-).
Cookie to the first person to use it outside a loop head. :-)

Aw, don't cave. Wes wouldn't have given in: look at how long we had to suffer with IF_EVAL. If we could survive, so can they with dumb global FUNCTION. My initial response was a bit more acerbic, and I didn't want it to go over the wrong way (aVENGER doesn't usually post here) so I just edited it all out, but it was basically "Deal (with it), bitch." No fair that they can break compatibility when I was never allowed to. :-)

Just to clarify, I'm having THIS = 'where' of the calling action to use in the value (maybe if you pass it in as part of the patch action? it can't be a generic PE value, can it?), so that I can WRITE_BYTE 0x8 THIS | 0x1 instead of WRITE_LONG 0x1e LONG_AT 0x1 SHORT_UNDER 0xe BYTE_OVER 0x1e ^^ 1234456.