Is it possible to remove a lock or change difficulty

[igi]

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~

 

I believe that would work fine, except for when the filename is 8 characters.

 

 

I've knocked up a macro that can be used to figure out the correct Tutu name (though I've never paid much attention to the tutu naming scheme - I presume it's "add a _ to the start of the filename. if that makes the filename longer than 8 characters, remove the last character". No idea what happens if that caused duplicate filenames though).

The macro can only be used when copying single files across, adds only 2 extra lines per copy, and is used like this (bg2 example I'm afraid, though it's the syntax we're looking at):

OUTER_SPRINT iiFileName abazigal.bcs

LAUNCH_ACTION_MACRO iiGetTutuFileName

COPY_EXISTING ~abazigal.bcs~ ~override/%iiFinalFileName%~

 

If anyone is interested, grab the macro here: http://www.teambg.eu/memberpages/igi/misc/...ileName(01).zip

Let me know what you think - it may be useless (though it was fun to code)!

[Nythrun]

You should be able to pare that down to just

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

and EXTEND_BOTTOM the relevant area scripts (unless I'm totally misremembering, area scripts aren't stored in the save files).

 

Most of the filename conversion should be automatable, with the possible exceptions igi already noted - though I was thinking of something a bit simpler

ALWAYS
DEFINE_ACTION_MACRO ~use_tutu_filenames~ BEGIN
 ACTION_IF (FILE_EXISTS ~some_tutu_specific_thing~ THEN BEGIN
OUTER_INNER_PATCH ~asdfasdfasdfasdf~ BEGIN
  SNPRINT 8 ~resref~ ~_%resref%~
END
 END
END
END

BEGIN ~mess with a sword~

OUTER_SET ~resref~ ~sw1h01~
LAUNCH_ACTION_MACRO ~use_tutu_filenames~
COPY_EXISTING ~%resref%~ ~override~
 DO_ALL_AND_SUNDRY
ETC_ETC

 

It's still two extra lines per action and wouldn't work with regular expressions.

[Ascension64]

Very difficult to get to work fully, because the naming conventions aren't so simple. Eight-character filenames are definitely one issue. Then you have to work out when BGT-WeiDU adds BG prefix. Finally, some Tutu scripts and CREs have the wierdest of names, like _28_GBASI.BCS and _10_MTOW.CRE. Therefore you'd have to make a macro that contains a dictionary for every single conversion to make full sense.

 

Or, you can say, start Tutu, remove _, then fix up all the errors.

[Miloch]

Very difficult to get to work fully, because the naming conventions aren't so simple.

But it'd work in the majority of cases. Why couldn't you extract all the ResRefs from the mod you're working on, see if they fit the pattern and deal with any exceptions that arise?

Eight-character filenames are definitely one issue.

But fairly easy to resolve - possibly with the...

SNPRINT 8 ~resref~ ~_%resref%~

...code above. This is pretty sneaky if it does what I think it does - adds an underscore to the existing resref and truncates it at 8 characters.

Then you have to work out when BGT-WeiDU adds BG prefix. Finally, some Tutu scripts and CREs have the wierdest of names, like _28_GBASI.BCS and _10_MTOW.CRE. Therefore you'd have to make a macro that contains a dictionary for every single conversion to make full sense.

Again... exceptions that you could handle on a case-by-case basis. And you'd only have to deal with the resources in your mod - not all of them (unless some kind soul wanted to work up a library of exceptions). As for areas, you'd just assign variable values based on which platform you're on and the area list (again, just for those areas in your mod). Seems this'd work for the mods I'm working on you converted - and why have a 6000+ line TP2 I have to change in 3 separate sections when 2000 lines would suffice?

Or, you can say, start Tutu, remove _, then fix up all the errors.

Not sure I follow that one.

 

[sorry for hijacking your thread berelinde, but hopefully your initial question has been answered and an admin can sort out the platform discussion into another thread ]

[berelinde]

No, I'm good on the question.

 

Oddly enough, I'd already done as Nythrun suggested. I put this in the file I plan to use to extend FW1000's script:

 

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

 

After all, the door on the FW1007 side, DOOR1000, isn't locked.

[Miloch]

After all, the door on the FW1007 side, DOOR1000, isn't locked.

No... why would it be, since you have to unlock the door on the outside to get *in* the building. Then again, it's not a door either (a door being something you can potentially open, close, lock and unlock) - it's merely an entrance (something you use to get in and out of the area) in FW1007, with the door existing only in FW1000.

[cmorgan]

Very difficult to get to work fully, because the naming conventions aren't so simple. Eight-character filenames are definitely one issue. Then you have to work out when BGT-WeiDU adds BG prefix. Finally, some Tutu scripts and CREs have the wierdest of names, like _28_GBASI.BCS and _10_MTOW.CRE. Therefore you'd have to make a macro that contains a dictionary for every single conversion to make full sense.

 

Or, you can say, start Tutu, remove _, then fix up all the errors.

 

Or you can build your mod for your platform of choice, then give Ascension64 a call and have him run it through his PCU, and we are back where Miloch started!

 

(sorry for continuing the hijack ... I second the request for a moderator to split, and will create the top post right now...)

[Miloch]

Or you can build your mod for your platform of choice, then give Ascension64 a call and have him run it through his PCU, and we are back where Miloch started!

Sure. Which is fine if you start with a mod in final form for a single platform. But when you have to edit something (or several somethings) after the fact, it multiplies the work quite a bit when you have multiple sections and platforms. Of course, Ascension could revise PCU to do the resource extraction and variable assignment up front (I estimate it would take him roughly 0.5 hours to do this - he's really quick ). Though that won't help me much with work in progress, unless it could do a reverse optimisation and recompile the TP2 (maybe an hour for that... ).

(sorry for continuing the hijack ... I second the request for a moderator to split, and will create the top post right now...)

I thought you had the 'POWAH'? I swear I've seen you move topics and individual entries, but maybe I'm tripping.

[berelinde]

Not for this board, he doesn't.

[berelinde]

I tried putting this in the area script, but it didn't work.

 

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

 

It didn't work. I know I'm extending the right area, because my spawns happened. But I had an area check in the spawns, but not this. I'm going to see if this works. If not, the party thief will just have to pick the lock.

 

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

[devSin]

Then you're doing something wrong. Make sure it really is the right area; make sure it's the right door; make sure the variable isn't already set; etc.

 

Unless you're doing it in BG1, in which case, who knows? Certainly not me...

[berelinde]

It's the right area, and the global variable did get set.

 

It sure looks like the right door, and FW1007, the area that's supposed to be behind it is given as behind it in NI. I'll see if NI thinks it's locked.

 

NI thinks it's locked.

 

Nah, I'm in Tutu, but I ran into some chain problems in the area behind it, where both actors were present and showing the right dialog files, and the dialog files showed up all right in NI, but the chain always breaks at the same point.

 

I'm going to be doing a reinstallation after the weekend updates anyway. Maybe consoling into the area didn't work quite right. NPC was also supposed to give a little speech entering the area, and that didn't happen either.

[devSin]

In this case, your bug must lay somewhere else. The block you've posted should always do what you want (as long as the variable is 0 when you enter the area), without exception.

[berelinde]

I'll check it after next install and see if there was a problem with the installation, then. Flukes happen, and the rest of the scripts are working.

[berelinde]

Checked the debug file, and everything looked all right.

 

Been thinking about something. Do I need to copy the door to the override during installation, i.e. COPY_EXISTING ~DOOR1007.SomeExtensionDontKnowWhat~ ~override~ in the tp2, if I'm going to change it?

 

Methinks I will fall back on a standard tactic: mine other mods for information. Lots of them add things to containers. I'll see how that is handled.

 

If anybody else has any thoughts on the subject, I'm all ears.

 

I get the feeling that either a) consoling into the area prevented all the things that were supposed to happen in that area from happening in that area or b) random bug, but it never hurts to double or triple check everything.