Is it possible to remove a lock or change difficulty

[berelinde]

Area FW1007 has a door, listed as DOOR1000 in NI. I would like it not to be locked.

 

How do I do this?

[Nythrun]

Something like this, if you want to patch it with WeiDU

COPY_EXISTING ~fw1007.are~  ~override~
 PATCH_IF (%SOURCE_SIZE% > 0x11b) THEN BEGIN
READ_LONG 0x00a4 "number_of_doors"
READ_LONG 0x00a8 "offset_to_doors"
FOR ("i1" = 0x00; "i1" < ("number_of_doors" * 0xc8); "i1" += 0xc8) BEGIN
  READ_ASCII   ("offset_to_doors" + "i1" + 0x00) "name_of_door"
  PATCH_IF ("name_of_door" STRING_EQUAL_CASE "door1000") THEN BEGIN
	READ_BYTE  ("offset_to_doors" + "i1" + 0x28) "flags_part_one"
	WRITE_BYTE ("offset_to_doors" + "i1" + 0x28) ("flags_part_one" | 0x2)
	SET "i1" = ("number_of_doors" * 0xc8)
  END
END
 END
BUT_ONLY_IF_IT_CHANGES

[CamDawg]

To be honest, do it via script--via area file means your players will be less likely to install your mod on a game in progress, as the changes to the area file won't take effect on saves where the area has already been visited.

[berelinde]

Thank you both for your speedy replies!

 

Nythrun, I especially appreciate the time you took to write that out, but I am still frankly terrified by the language of patching. I realize that I'm going to have to get over it sooner or later, but I'm taking one thing at a time.

 

CamDawg's suggestion to do it via script seems like it might be a better bet, since it will work if the area is visited prior to mod installation. By the time a party gets to Ulgoth's Beard, they probably won't have any difficulty with the lock anyway, but it makes more sense story-wise if the door is unlocked.

 

Hang on. The door is DOOR1000 on the FW1007 side. It will have a different number on the FW1000 side, won't it?

 

In any case, I think this might work

 

IF
 AreaCheck("FW1007")
 Global("B!UnlockDoor","GLOBAL",0)
THEN
 RESPONSE #100
 Unlock("DOOR1000")
 SetGlobal("B!UnlockDoor","GLOBAL",1)
END

 

I'd just change the door and areas if it's a different number on the FW1000 side.

[Miloch]

Hang on. The door is DOOR1000 on the FW1007 side. It will have a different number on the FW1000 side, won't it?

There is no door, per se, on the FW1007 side (there is an entrance 'Exit1000' which is different from a door and can't be locked unless I'm wrong). So you want to mod Door1007 on the FW1000 side, which is locked with a difficulty of 30% by default. DLTCEP makes it a little easier to visualise these things than NI in my opinion.

 

I've been preceding all TotSC changes in the mod I'm working on with something like

ACTION_IF FILE_EXISTS_IN_GAME ~_SW1H24.ITM~ THEN BEGIN //Tutu-TotSC

Otherwise WeiDU will cause an error if TotSC isn't present, but I'm sure you've accounted for this already, probably with a smarter way than mine.

[berelinde]

Pretty much the same way, actually. I plan on keeping ToSC things separate, and will install them if it's detected. Since this is for an NPC mod, I really only have to worry about a handful of interjections, 2 items whose BAMs I have to check, an Gavin's family. He says he's from Ulgoth's Beard. It would be very strange if the party went there and Gavin didn't ask to go see them. I got very very lucky, tho. There are only 3 houses in town. I was very fortunate that one of them was empty.

 

Thanks for that resource name. I was planning on doing an BG1 sans ToSC/SoA install this weekend and printing out a list of the contents of the override folder so I could better identify ToSC/ToB resources.

[cmorgan]

I've been preceding all TotSC changes in the mod I'm working on with something like

ACTION_IF FILE_EXISTS_IN_GAME ~_SW1H24.ITM~ THEN BEGIN //Tutu-TotSC

Otherwise WeiDU will cause an error if TotSC isn't present, but I'm sure you've accounted for this already, probably with a smarter way than mine.

Miloch, this isn't a correction or anything, just a suggestion. I know the item is a standard check, but for consistency/safety I have been using area references instead, just like BG2 Tweaks - it also makes it easy to match on the BGT side if you want a single distribution dual-install

 

/* the following areas are TotSC only*
ACTION_IF FILE_EXISTS_IN_GAME ~FW1500.are~ THEN BEGIN // if TotSC is installed
 >>>>changes go here<<<<
END

 

please note - this appears to be personal choice; the Fixpack uses items and area references apparently randomly. Makes sense, as all you are doing is looking for evidence that something from the expansion exists; I just am standardizing on area references.

[Miloch]

...it also makes it easy to match on the BGT side if you want a single distribution dual-install

Actually, what I'm working on is a triple-install (Tutu/BGT/BG1) made compatible initially by Ascension64's PCU. Apparently that uses _SW1H01.ITM to check for Tutu and data/BG1ARE.BIF to check for BGT and the absence of either to check for BG1 (though now that I think about it, the absence doesn't necessarily indicate BG1 - someone could erroneously be trying to install on BG2 or something). There isn't a separate check for TotSC (in the case of Tutu or BG1) so I had to add that. So there's no real consistency but as you say that shouldn't matter. Then again, maybe it makes sense to pick one convention, especially in the case of an automated code checking utility that can scan for relevant sections of code based on platform.

[berelinde]

Hey, I'm definitely in favor of using common conventions for as much as possible.

 

For one thing, it makes things easier to find in cases where the modder has not commented abundantly.

[Miloch]

Is it just me or does it seem exceedingly primitive to maintain 2-3 separate sections of code just based on minor platform differences? For example, a lot of the differences in my file between Tutu and BGT just have to do with the underscore being present on some files in Tutu, but it ends up being a 6000+ line TP2 instead of a 2000-line file or less. I'd be great if WeiDU could simply choose the correct filename based on platform, possibly from an external file where those names are listed, and perhaps just refer to variables in the TP2. Or just concatenate the filename by inserting a '_' at the beginning in the case of Tutu. Or something just a little more efficient - every time I tweak one parameter I have to grep for it in three different sections of the code.

Hey, I'm definitely in favor of using common conventions for as much as possible.

Well in the meantime, if we're reduced to this kind of language, I looked up some area files that are more or less unique to the installations (as far as I can tell):

ACTION_IF FILE_EXISTS_IN_GAME
~FW0125.ARE~ THEN BEGIN //Tutu
 ~FW2003.ARE~ THEN BEGIN //Tutu+TotSC
~AR7200.ARE~ THEN BEGIN //BGT
~AR0125.ARE~ THEN BEGIN //BG1
 ~AR2003.ARE~ THEN BEGIN //BG1+TotSC
~AR0083.ARE~ THEN BEGIN //BG2-SoA
 ~AR6200.ARE~ THEN BEGIN //BG2-ToB
ELSE BEGIN //Error (BG not present)

The only exception is the BG2 areas are probably also present in BGT and Tutu, but by the time you've gotten that far, you've already ruled out those options (assuming your mod is compatible with that many platforms). The problem with cmorgan's example (FW1500.ARE) is that, although it is unique to Tutu-TotSC, its equivalent in BG1 is not (there is a separate AR1500.ARE in BG2/BGT). And I haven't yet coded an 'anti-idiot message' (ELSE BEGIN //Error) if someone tries to install on the wrong platform, but I guess it'd be a good idea.

 

Edit: See here for future updates on platform-detection conventions.

[cmorgan]

BG2 areas are definitely present in both Tutu and BGT installs as well; I guess you could check for any Tutu area ("FW" wins!), a unique AR BGT name (or the .bif), and a unique BG1 nmae, and have the "if not a, not b, and not c, then do this" be the BG2 one.

 

I think that is a good argument for the item ref, if there is an item ref unique to each install; we are all looking for a unique identifier to add one more catch for the user-error quotient! It seems usual behavior is to state your mod is for X and Y, and then code accordingly; then a straight "check for Tutu - if it is Tutu then do this, otherwise do that" (with the internal variation of "within Tutu, check for TotSC, and if found do this extra stuff"). Since BGT has to have TotSC, it isn't necessary to check for it, but I do anyways in BG1 NPC code because I wanted to do a double check (and i really didn't understand that BGT would not install without TotSC ). What I never have needed to do is add that third check, the one you are talking about, Miloch - the part that looks for a BG1 area and says "yo, you are in the wrong place to install this!". We just put a check for either Tutu or BGT by unique area, then failed install if neither were present.

As for the first part, I think the best we can do is wait for a true unification project to even out BGT and Tutu.

[Miloch]

BG2 areas are definitely present in both Tutu and BGT installs as well; I guess you could check for any Tutu area ("FW" wins!), a unique AR BGT name (or the .bif), and a unique BG1 nmae, and have the "if not a, not b, and not c, then do this" be the BG2 one.

That's basically what the code above does, except the areas are all unique to their installations until you get to BG2. Which at that point, as I said, should mainly be a matter of deciding whether ToB is present - assuming your mod can even support all those platforms.

I think that is a good argument for the item ref, if there is an item ref unique to each install

I don't get it... I started off with items - I thought you were the one arguing for areas? In theory it shouldn't matter, except I guess it'd be more rare to conflict with entire standard areas than with mere items.

What I never have needed to do is add that third check, the one you are talking about, Miloch - the part that looks for a BG1 area and says "yo, you are in the wrong place to install this!"

Well the mods I'm working on also support plain BG1 - they did originally, so it's not difficult to continue that support (except in terms of code volume and redundancy - see below).

As for the first part, I think the best we can do is wait for a true unification project to even out BGT and Tutu.

There's that, but my point was the way we're coding this seems inefficient. For example, I have a "harder enemies" mod that goes and changes a bunch of standard CREs in Tutu - for example, beefing up their hitpoints a bit and other stats. Let's say, this goes on via patching for about 1000 lines give or take. Then that *same* code repeats for BGT another thousand lines - the only real difference is the omission of the underscore for Tutu CRE names. Is this really necessary? Can't I just use a platform-dependent variable to indicate the CRE names or something so that that part of my code is "only" 1000 lines instead of 2000? Not to mention, as I said, if I want to tweak some small parameter, I only have to do it once rather than 2-3 times.

[Ascension64]

One way to make handling cross-platform code easier is to use the INCLUDE function in WeiDU. For example,

 

 

main.tp2

BEGIN ~Main~

ACTION_IF FILE_EXISTS_IN_GAME ~_SW1H01.ITM~ THEN BEGIN //Tutu
INCLUDE ~Main/Tutu.tph~
END

ACTION_IF FILE_EXISTS ~data/BG1ARE.bif~ THEN BEGIN //BGT-WeiDU
INCLUDE ~Main/BGT.tph~
END

 

This doesn't really let you reduce the number of lines of code, but discretely separates the Tutu code from the BGT-WeiDU code. Then, you can simply use something like UltraEdit to make simultaneous bugfixing between the tph files. Unfortunately, INCLUDE is an action, so you have to repeat this step for every single component, which gets tedious and becomes a nuisance having to make two sets of tph files for the Tutu and BGT-WeiDU versions of each component. The other option is to simply separate the installations altogether, which I think, given the complexity of cross-platform modding, is probably the best way to go. It does, though, have its disadvantages of double-double-checking bugs and so on.

[Miloch]

I see drawbacks to both methods (INCLUDEs and separate installs for each platform) - basically the same as you described - having to synchronise multiple files when you want to change something. This is kind of the problem in the first place.

 

Can't we have a platform-dependent variable declaration section in the beginning of the TP2? Or can't you get that clever with variables in WeiDU? In every other scripting or programming language I've working with, this is considered a Good Coding Practice (which therefore, I usually ignore, but it'd be really helpful here). The WeiDU docs state the following about COPY:

If there are any WeiDU variables inside explicit %s in toFile or fromFile, they are replaced by their values.

If so, then bingo - we've struck gravy. But if it is that easy, why aren't people already coding this way? Maybe the noteworthy phrase here is "WeiDU variables" - i.e., it doesn't work with user-assigned variables? But if it does, I could do this in theory:

ACTION_IF FILE_EXISTS_IN_GAME ~FW0100.ARE~ THEN BEGIN //Tutu file conventions
 SPRINT "tsc" "_" //assigns Tutu underscore
ELSE BEGIN
 SPRINT "tsc" "" //no underscore otherwise
END
COPY_EXISTING ~%tsc%DAVAEO.CRE~ ~override/%tsc%DAVAEO.CRE~

Et cetera... but then I can proceed with just one block of code instead of two (or three in my case). I'm sure you coding gurus can point out any number of reasons why this wouldn't work. It'd save me thousands of lines of code if it (or something similar) did work though.

[berelinde]

I'm not trying to discourage the conversation taking place on this thread. It's good stuff, and worth discussing.

 

I'm just wondering if it wouldn't make sense to retitle it or move the parts where we stopped talking about a single door. (No one ever told me if the script would work, so I'm going to assume that means yes.) We're talking about cross-platform matters, and that's a lot more consequential than whether berelinde can figure out how to work a script.