V2 Progress

[the bigg]

More logspam by Logspammer Technologies © . Logspammer © : All the news unfit to PRINT

(PATCH_)LOG tp2 command?

 

Um, you could add to your to-do though: log READ_LN choices to an external file since they aren't recorded in WeiDU.log. Might help with debuggging (or reproducing bugs at any rate, without asking a tonne of questions). I'd go ahead and do it since it'd be fairly easy but I won't bother if you've already overhauled the code.

mymod/backup/*/READLN.*; it's a binary format though (but still slightly human-readable). I should change READLN.* (and ARGS and UNSETSTR) to use a textual format to avoid file corruption if/when French dudes decide to change some internal format, so perhaps I should take the occasion.

 

If you picked fighter, then: Dual this character [y/n]?

If you picked yes, then: Dual to Mage, Cleric, Thief, or Druid?

If you picked Mage, then: At which level [2 to ( maximum of {mage/fighter} level under exp cap) - 2 ]

Then pick your additional proficiencies and second class proficiencies and spells and what have you.

Wouldn't work properly. If an NPC with an unfinished dual-class joins the party, the first class' CLAB abilities will be gained twice (once when joining the party, then again when regaining the old class abilities). You need kit shadowing (a la Refinements) to handle this properly.

 

 

For a Kensai(2)->Thief Yoshimo, you need to:

<<<<<<<< clabempt.2da
2DA V1.0
****
		1		   2		   3		   4 ...
ABILITY1	****		****		****		**** ...
>>>>>>>>

COPY_KIT ~KENSAI~ ~KENSAItF~ (
 CLAB ~clabempt.2da~
)

COPY_KIT ~KENSAI~ ~KENSAItw~ ()

COPY_EXISTING ~yoshimo.cre~ ~override~
WRITE_SHORT   0x244 0
WRITE_SHORT   0x246 0x4000 + KENSAItF
// TobEx now allows more than 0xff kits, so the traditional kit-setting code is wrong

<<<<<<<< fixup.baf
IF  
 KIT(Myself,KENSAItF)
 Class(Myself,FIGHTER_THIEF)
THEN
 RESPONSE #100
ActionOverride(Myself,AddKit(KENSAItW))
END
>>>>>>>>

EXTEND_TOP ~yoshimo.bcs~ ~fixup.baf~
EXTEND_TOP ~yoshimo25.bcs~ ~fixup.baf~

 

If this is installed after Refs, the only issues will be that this Yoshimo will be able to use mage scrolls as soon as he joins the party, and that he will be able to pick Use Scrolls even if he already has the ability (meaning that players can and need to police themselves regarding them).

 

EIDT: majorly revised example.

[Wisp]

More logspam by Logspammer Technologies © . Logspammer © : All the news unfit to PRINT

(PATCH_)LOG tp2 command?

If you mean something that prints the string to the debug file without showing up in the command window, I've been meaning to request that.

[Nythrun]

Right. Well, I guess I'd better code this before y'all figure out what a potzer I am.

 

 

(PATCH_)LOG tp2 command?

I'm pretty sure the usual suspects could find a use for that - at least after everyone's done squabbling over the implementation. For now I'm just infodumping into a MKDIRed mod_resources folder in the BG2 directory.

 

 

Wouldn't work properly. If an NPC with an unfinished dual-class joins the party, the first class' CLAB abilities will be gained twice (once when joining the party, then again when regaining the old class abilities). You need kit shadowing (a la Refinements) to handle this properly.

My initial thought was to not change the .cre's kit number from 0x40000000 to ~%kit%~ at all until after they've joined up. A short delay in the XP script will keep that from kicking in too early. After that they'll be in the same predicament as stock Yoshimo if you dual him to fighter and then rescue him from a short date with a medusa. Though there does remain potential trouble with Jaheira and her party-ditching ways if I don't add a whole stupid lot of transition actions to her rejoin dialogue. I'll think about it more, but I may end up outsmarting myself rather than the engine if I pursue this route

 

 

So ?

That's really clever, and something I hadn't encountered, thanks. It's also really on the bleeding edge of unacceptably hacky, even by my standards. While specific-NPC-only kits do allow you to finesse a few of the difficulties, I don't know that it's potentially bugfree enough that I'd want to release something like that. So definitely maybe, and definitely not right now.

 

I should be able to support applying the multiclass kits which that mod generates to NPCs, though.

[cmorgan]

Way, way way way (just keep chanting this until you get tired of doing so, or in musician speak, "vamp until entrance" - and vamp just means repeat in this usage ) awesomely cool.

 

[joke] Just be careful - next up will be a combo of your stuff and Mike1072's stuff, where you forget the whole "strip back to the header and rebuild" thing, and just plain create a custom .cre file with every single possible combination of ideas through user input... with the magical "read the user's mind and make every kit they will ever possibly install available by reading their mind on startup". [/joke] (Come to think of it, Zyraen's Hidden kits does something like that through scripting - I am having fun thinking about this, but it is a joke idea. I like the "choice on install, then script cleans up in-game" simplicity. I don't want my NPC's to dialog with themselves, and ask things like

 

"Level 0, Question 1 of 250 in this subsection: Do you want me to be a Fighter, Mage, Thief, Ranger, Paladin, Wild Mage, Barbarian, Sorcerer, Cleric, or %custom_class_hacked_in_within_GemRB%"

etc. etc.

 

 

(p.s. - that light at the end of the tunnel is actually a bipolar outflow... so we might all get crispified, but at least it is due to birth rather than death!!)

[Ardanis]

If you picked fighter, then: Dual this character [y/n]?

If you picked yes, then: Dual to Mage, Cleric, Thief, or Druid?

If you picked Mage, then: At which level [2 to ( maximum of {mage/fighter} level under exp cap) - 2 ]

Then pick your additional proficiencies and second class proficiencies and spells and what have you.

Check against Level(Object,value) to ensure NPC gets only enough XP to advance one level

- Or -

READLN at which level you want to dual, in script first supply XP up to the required level, then go with the rest

 

Obviously, script will need to be hot-generated using math from xplevel.2da, in both cases.

 

[joke] Just be careful - next up will be a combo of your stuff and Mike1072's stuff, where you forget the whole "strip back to the header and rebuild" thing, and just plain create a custom .cre file with every single possible combination of ideas through user input... with the magical "read the user's mind and make every kit they will ever possibly install available by reading their mind on startup". [/joke]

Not a joke. It's how things ideally should be proceeded.

[the bigg]

New WeiDU beta up.

- LOG, PATCH_LOG commands.

- ACTION/PATCH_READLN will log to setup-mymod.debug the user's answers.

- Changes under the hood to how STRING_SET is uninstalled and how --args and READLN is preserved on reinstalls (it now also logs to a textual file, in case French people decide to break the older binary format). It works in ad-hoc tests, but I could use a link to L1NPC beta to run tests on a more complex piece of READLN madness.

[Miloch]

I could use a link to L1NPC beta to run tests on a more complex piece of READLN madness.

A v1.4 has been in the workroom for some time (follow cmorgan's link in the 2nd post).

 

I understand that G3 is making it available only to "premium" members, and then for a special "donation." (Kidding... actually, was just waiting for a "stable" WeiDU, though Nythrun may ninja-release something that makes the v1.4 obsolete.)

[Nythrun]

Obviously, script will need to be hot-generated using math from xplevel.2da, in both cases.

It'll require having an experience modifying script at all, is the thing; I really dislike that technique and don't want to multiply its use without necessity. We'll see what others have to say, though.

 

Nythrun may ninja-release something that makes the v1.4 obsolete.

Unlikely, at least not for the next two weeks or so. Might as well lob 1.4 at the world and not squander all the effort lavished on it.

 

Most of the mega-mod NPCs won't be able to use their signature items in 1.4, but it looks generally solid.

[Miloch]

Most of the mega-mod NPCs won't be able to use their signature items in 1.4, but it looks generally solid.

Huh, why not? I thought fj_replace_item_usability automatically executes for any non-stock items in the NPC's possession. On top of that, I specifically accounted for custom items not in the NPC's possession, if I knew what those were.

 

And umm...

So with that in mind, I'm thinking about something like:

 

If you picked fighter, then: Dual this character [y/n]?

If you picked yes, then: Dual to Mage, Cleric, Thief, or Druid?

If you picked Mage, then: At which level [2 to ( maximum of {mage/fighter} level under exp cap) - 2 ]

Then pick your additional proficiencies and second class proficiencies and spells and what have you.

Makes sense I guess, though sounds insane to code (though I'm not sure if that's "more insane" or "less insane" than existing code).

 

(Not sure if it'd be more insane than a hypothetical "only give/allow NPCs weapons for which they satisfy the strength requirements, if you haven't removed those on your game" component either...)

[erik]

(Not sure if it'd be more insane than a hypothetical "only give/allow NPCs weapons for which they satisfy the strength requirements, if you haven't removed those on your game" component either...)

Already exists in the item-assignment code today, doesn't it?

[Ardanis]

It'll require having an experience modifying script at all, is the thing; I really dislike that technique and don't want to multiply its use without necessity. We'll see what others have to say, though.

Why such a dislike? Besides, you don't have an existing script in the first place anyway, so there's nothing to modify, only to build.

[Miloch]

Already exists in the item-assignment code today, doesn't it?

If it does, I totally missed it, and I've pored over (and heavily revised) that code more than is good for any sane human (or even mostly insane half-orc). Anyway, it's on Nythrun's to-do list in the existing readme, so if it's done it can be crossed off.

 

I tested the "signature item" thing by installing Indira on Tutu and making her a druid. Well her custom chain vest (previously not usable by druids) is now usable by druids. However, it still says "Not Usable By: Druid" - I thought the description patching stuff was coded to account for that. Maybe not for signature items, only the weapons tweaks or something. Minor thing though, I guess.

 

A pretty major thing though is the enforce_cre_order macro doesn't account for mod NPCs. So the Indira component bombed actually until I ran her CREs through that. I think it would be better to call this for each NPC as they're modded rather than put all them in the main component/"subjunctive" includes, which I think Nythrun already alluded to somewhere above. (Indeed there was even some talk of adding at least the validity check to WeiDU, if not the order enforcement, but I don't think it's quite there yet.)

[the bigg]

(Indeed there was even some talk of adding at least the validity check to WeiDU, if not the order enforcement, but I don't think it's quite there yet.)

FJ_CRE_VALIDITY: Checks whether a CRE file is well-formed or not, fixes some common bugs, and reports whether the CRE file is still broken or not. This is a PATCH function.

 

* INT_VAR do_message to 1 if you want explicit an explicit message regarding the cre invalidity. Defaults to 0.

* RET valid returns 1 if the CRE is well-formed, 0 otherwise.

 

Checks minimum length, correctness of signature, and whether all structures point at 0x2d4 or higher, but doesn't reorder the file. If a structure points at < 0x2d4 and has zero members, its offset is changed to 0x2d4; if its offset is < 0x2d4 and it has one or more members, it reports as invalid.

[cmorgan]

So a doublecheck - if a modder wants to just check whether or not a .cre is a valid one, they can use

 

FJ_CRE_VALIDITY

 

as a sanity check without resorting to additional .tpp or .tph usage, or adding anything to the .tp2.

 

If they want to actually check that the .cre is valid, reorder the .cre, patch in Miloch's fix for those pesky tutu conversion .cre soundsets dinging in DLTCEP, and move anything that is then there are currently at least two Nythrun-based options, one that is in bg1npc ( this one here ), and the other one AvengerRR uses in his work where you

 

1. run

2. run

(which in the course of events internally looks for and calls the additional .tpp )

 

so that by the time this sequence has finished everything has been made to work as best as it can, given the constraints?

[Miloch]

1. run

2. run

(which in the course of events internally looks for and calls the additional .tpp )

Yeah, or in other words:

1. fj_cre_validity

-> 2. IF valid THEN fj_cre_reindex (aka enforce_cre_order)

...-> 3. IF v1 EFFs THEN fj_cre_eff_v2 (aka use_v2_eff)

 

L1NPCs actually skips the first step AFAICT. Presumably we want it to fail if patching an NPC that's bogus or hopelessly hosed, rather than skip it silently or with a warning. The 2nd step was the important one I mentioned, which I just coded quick and dirty for the current version by shuffling ordering for mod NPCs into the main component (there was a specific routine to address NEJ misindexed CREs but that didn't help much for Indira etc.).

 

I suppose WeiDU might as well include the other 2 macros as long as it has the first one. They've been in use in at least half a dozen mods for a while (p5tweaks, aTweaks, RR, Aurora, Infinity Animations, etc.) and since they don't need to set or return any external variables I know of, there shouldn't be much required in the way of documentation. It is a testament to WeiDU and/or OCaml and/or Nythrun's code that all that can execute in milliseconds, not much more than COPYing the .cre without them, so it's not like they'll slow you down much.

 

I ran a scan to see if I'm missing any megamod NPC custom items. There's maybe a few lurking out there unpatched but I think the vast majority are already accounted for. There's some creepy crud even in the vanilla game though. For example, Eldoth has an innate spell that creates arow14 (lacking the underscore even in Tutu, oddly). He doesn't come equipped with any, but they're his "personal poisoned arrows." Well, if someone makes him an assassin or whatever, he can't use them. But I may as well add this kind of junk as long as I'm in there again.

 

Edit: added and reuploaded to workroom