Functions and variables/strings that are set by other stuff

[devSin]

It looks like 214 is set to break mods

Whoa, this is getting a bit out of hand now.

The purpose of WeiDU is to facilitate the distribution and installation of mods for players, not to save GeN1e a few extra milliseconds of typing just. one. more. character.

I can appreciate wanting to make things easier (hey, I ask for it all the time), but we shouldn't be sitting here making arbitrary compatibility decisions that influence everyone who may want to make, or even just install, a mod, because we all have different ideas about how stuff should really work (and look).

This is very close to just taking Wes' name and wiping your ass with it.

And I for one won't stand for it. If you're going to wipe your ass with something, it should be pamela123.

[GeN1e]

It looks like 214 is set to break mods

Whoa, this is getting a bit out of hand now.

The purpose of WeiDU is to facilitate the distribution and installation of mods for players, not to save GeN1e a few extra milliseconds of typing just. one. more. character.

I can appreciate wanting to make things easier (hey, I ask for it all the time), but we shouldn't be sitting here making arbitrary compatibility decisions that influence everyone who may want to make, or even just install, a mod, because we all have different ideas about how stuff should really work (and look).

This is very close to just taking Wes' name and wiping your ass with it.

And I for one won't stand for it. If you're going to wipe your ass with something, it should be pamela123.

Alright, you've made a point. Will your majesty at least allow for {}, STR_EQC and A_D_A / D_A ?

[devSin]

Note that you can compile your own version of WeiDU with whatever aliases you like.

If you have to have { }, whatever. I'd prefer STR_EQ_CASE (and STR_CMP_CASE, and STR_EQ if it's not there already).

A & D may be too ambiguous, but I guess if you get yours in first, it doesn't really matter what commands they can match in the future.

Thus is His Majesty's decree. Thus let It be done. :P

Now if you'll excuse me, I have to pinch this one off so pamela123 will have something to eat.

[GeN1e]

Note that you can compile your own version of WeiDU with whatever aliases you like.

Wouldn't it then autoupdate other executables, so bad things will begin?

[devSin]

All the more reason not to break shit with all-and-sundry (although, honestly, auto-update should have been disabled rather than extended). It's a huge, fundamental problem to the whole design of WeiDU that the version you ship may not be the one executing you.

You so far haven't appeared to show any concern for changes where the "bad things" that happen aren't affecting your particular mods in a player's install, though, so I don't see why it should stop you now. And in any case, I'm sure it could be coded around if you're truly intent on ever-more-insane aliases for actions.

[the bigg]

RET: one of the goals I have with WeiDU is to warn/fail explicitly when you make a programming mistake, and forgetting to set a variable *is* a programming mistake, so no.

devSin:You can be assured that I cmorgan will run extensive tests prior to release, to be sure that actually harmful changes will not go in (or, in extreme cases, will only go in after giving time to affected modders to update their code - and certainly not for something as trivial as new aliases).

[aVENGER]

I don't know how feasible this would be from the coding perspective, but instead of forcing GeN1e's shorthands upon everyone and possibly breaking some stuff, why not simply introduce ALIAS as a tp2 flag? It could allow users to define their own set of command aliases which would be specific to the current tp2 and not affect other people's mods at all. For example:

Code:

ALIAS
  "WRITE_BYTE" = "W1"
  "WRITE_SHORT" = "W2"
  "WRITE_LONG" = "W4"
  "DEFINE_ARRAY" = "D_A"
END

Could OCaml allow for something like that at all?

[the bigg]

As I've said,  they will be tested before actually releasing, and the smart people can simply elicit to avoid using that kind of counterproductive shorthand.

Could OCaml allow for something like that at all?

Not possible, because of a ton of blah blah blah about precompiled grammars, hashtables and greedy algorithms.

I've thought a bit more about this, and I believe that I can reduce chances of conflicts by leaving the underscores and having only abbreviations more than a character long. Each word will be broken into underscore-separated tokens, and each of those can be either its full version (ACTION) or a shorthand version (AC). I have the following in mind (more can be easily added):
ACTION: AC
PATCH: PA
OUTER: OUT
INNER: INN
LAUNCH: LA
FUNCTION: FUN
MACRO: MA
ARRAY: ARR
ASSOCIATIVE: ASS (so your 12-something relative can giggle at your code)
DEFINE: DEF
OFFSET: OFF
INCLUDE: INC
STRING: STR
COMPARE: CMP
EQUAL: EQ
EVALUATE(D): EVAL
LATER: L8 (LAUNCH is more important)
FORMER: FO
INSERT: INS

No ASCII because ASC is unreadable (you'll end up reading ASCENDING). No SHORT/etc. because I can't think an acceptable way to shorten them to 2 characters (the closest I could think was U2 because it's unsigned), and no READ/WRITE because RE_LONG is stupid. ENTRY/ENTRIES can be skipped entirely.

Examples of new shorthand include AC_IF (the shortest shorthand possible), PA_PRINT, INN_PA_SAVE, AC_DEF_ASS_ARR, READ_2DA_NOW, WRITE_2DA_L8. You will be able to mix/match normal or short words as you want (AC_DEFINE_ASSOCIATIVE_ARR is valid if you like that sort of stuff).

[GeN1e]

You so far haven't appeared to show any concern for changes where the "bad things" that happen aren't affecting your particular mods in a player's install

I most certainly have shown concern regarding breaking others' mods, for example when asking whether aliases can be considered safe.
And if you're referring to sanity, that has nothing to do with me, except running around community looking for people to be warned, even if that's not immediately my job to do.

In other words what you've said is one big false accusation and Disgusting Lie (C)
You should stop harrassing pamela, she obviously is influencing you in a bad way)

[devSin]

I most certainly have shown concern regarding breaking others' mods, for example when asking whether aliases can be considered safe.

I think that was me generalizing everybody who's been involved who didn't say "wait." Remember you're not just asking for a feature and going around to make sure something is "safe," you're also dictating what can and cannot be used in the future (want a variable W4? well you can't have it!), even if they never intend to use the alias.

And I don't see any benefit to bigg's proposal other than that all the actions suddenly look retarded and incomprehensible. It's called auto-complete. C_U_L8R

INN_PA_SAVE? What the hell? Is this a coupon code for saving money at the Day's Inn in Pennsylvania?

You should stop harrassing pamela, she obviously is influencing you in a bad way)

Nah, I get my shit checked at the clinic.

You need to be careful with that slut.

[the bigg]

I think that was me generalizing everybody who's been involved who didn't say "wait." Remember you're not just asking for a feature and going around to make sure something is "safe," you're also dictating what can and cannot be used in the future (want a variable W4? well you can't have it!), even if they never intend to use the alias.

The same can be said for any command that was ever added to WeiDU.

[Wisp]

If sane function behaviour goes in, I've a little problem to report.

Test case:

Code:

OUTER_PATCH ~12~ BEGIN                                                                                         
  WRITE_BYTE 1 0x09
  READ_ASCII 1 tab (1)  // 0x09, tab
END
OUTER_SPRINT null ""

DEFINE_PATCH_FUNCTION change_damage INT_VAR change_ab = 1 RET dmg_output BEGIN
  READ_LONG  0x64 ab_off
  READ_SHORT 0x68 num_ab
  FOR (i=0;i<num_ab;i+=1) BEGIN
    READ_SHORT ab_off + 0x38*i ab_type ELSE 999
    PATCH_IF ab_type = change_ab BEGIN
      WRITE_SHORT ab_off + 0x38*i + 0x16 size
      WRITE_SHORT ab_off + 0x38*i + 0x18 dice
    END
  END
  SPRINT thac0 thac0 //@0
  SPRINT thaco thaco //@1
  SPRINT damage Damage //@3
  INNER_PATCH_SAVE dmg_output "%dmg_input%" BEGIN
    REPLACE_TEXTUALLY CASE_INSENSITIVE EXACT_MATCH "%thaco%" "%thac0%"
    REPLACE_TEXTUALLY CASE_INSENSITIVE EVALUATE_REGEXP "^%damage%:?[ %tab%%null%]+[0-9]+d[0-9]+" "%damage%: %dice%d%size%"
  END
END

COPY_EXISTING sw1h43.itm override
  READ_STRREF 0x50 desc1
  //SPRINT dmg_input "%desc1%"
  LPF change_damage INT_VAR size = 4 dice = 2 STR_VAR dmg_input = "%desc1%" RET desc2 = dmg_output END
  SAY_EVALUATED 0x54 "%desc2%"
BUT_ONLY

Using STR_VAR to pass the string variable to the function sets desc2 to the unaltered description. Setting dmg_input with SPRINT makes the function correctly return the altered description as desc2.

Am I doing something wrong or is this functionality missing for whatever reason?

[wut]

STR_VAR dmg_input = EVAL "%desc1%"

[Wisp]

Okay, thanks.

[devSin]

'--' doesn't actually work (without a space after var) since it takes as a string first (but ++ works as expected, useless as that one is). Lame.

[the bigg]

All I can do about this is laugh at the state of things as I inherited them. 

[devSin]

Yeah, similar happened when Wes originally tried to use ~ for BNOT.

But I think you'll still need to console me with THIS and WRITE_ASCIIL so I don't go completely apeshit.

You should remove -- since it's so flaky. Or maybe we can switch to 8-bit characters (pick an encoding) and use en-dashes instead of dashes... ;-)

[the bigg]

But I think you'll still need to console me with THIS and WRITE_ASCIIL so I don't go completely apeshit.

they're coming up, I'm just a bit on hiatus.

You should remove -- since it's so flaky.

...or make ++ and -- be prefix 

Or maybe we can switch to 8-bit characters (pick an encoding) and use en-dashes instead of dashes... ;-)

Not if I want all dirty ignorant subhuman masses people not playing in English to get angry at me.

[devSin]

What TP2s that you know aren't in English? They can suck it. :-)
But yeah, I would fight against it. The language is already enough of a cosmic joke as-is.

Would the prefix work (wouldn't still just eat --i as "--i" or does it have to be \w first then can be - or # or whatever without quote)? Prefix is kind of fugly, but what can you do, I guess.

[the bigg]

Looks like it'll work:

| ['0'-'9''A'-'Z''a'-'z''_']['0'-'9''A'-'Z''a'-'z''#''_''-''.''\'']*

[devSin]

Sigh. I hate life.

++misery

[the bigg]

THIS/STHIS and WRITE_ASCII_LIST coded (the latter is EVALUATED).

Fun snippet of the day:

Code:

Array.to_list (Array.mapi (fun i x ->
  Tp.TP_PatchASCII(Tp.PE_Add(Tp.PE_Mul(Tp.get_pe_int (string_of_int i), Tp.get_pe_int "8"), e1), x, true, Some (Tp.get_pe_int "8"))
  ) (Array.of_list e2))

I don't know what should I comment first: having to write e1 + i * 8 in 50 characters because of dumb absence of casting, or having to use array_to_list array.mapi array_of_list since list.mapi wasn't available.

[devSin]

I'm half/half on EVALUATED (the string has to be "%%" for evaluation, right?) since everything I do is non-eval; how is it handled in normal WRITE_ASCII (it should be the same for L, just sticking a bunch in one command).

What is e1 in that context? It is kind of sad-looking in any case, yeah.

EDIT: ah, it's where, now that I looked at the diffs, duh.

Did you decide to switch the inc/dec postfix to prefix (I guess it'll still be sort of useful, just horrendously painful to use)?

[devSin]

THIS/STHIS

It looks like this only works the first time eval fails (e.g., afterward, THIS & STHIS are always set to something and never updated again)?

[the bigg]

Doh.