Suggestions for next Tutu Tweak Pack

[igi]

I have been unable to disable the TAB hotkey.

 

So, any work-around would rely on the player not pressing the TAB key. Which is pretty unlikely. Which sucks.

[Salk]

I agree that any other kind of work-around would suck. Is it possible that there's no way to do this ?

[NiGHTMARE]

Erm, isn't this TAB thing pretty pointless anyway? If a player really wants to use TAB in every single room he enters, he's not going to install a tweak that prevents him from doing that.

[Salk]

Yes, of course! But if a player instead wants to use the ABILITY of the thief who can spot objects by pressing TAB, why wouldn't one do it ? It's not the same thing at all, dont you think ?

 

The original TAB lets the player sistematically spot every objects with no apparent reason (and people like me can't stand such things).

My solution would give a logical meaning to all this by implementing a dersirable function that extends the Detect Traps ability coherently, adding realism and discouraging the lazy playing. Truth is that the game concept about the TAB function should have been similar (or same) to what I suggest here from the beginning; and then, for "cheaters", there should have been a tweak that lets the TAB function always work (what ToB offers is a sort of "legal cheat", according to me)

[Ghreyfain]

Yes, of course! But if a player instead wants to use the ABILITY of the thief who can spot objects by pressing TAB, why wouldn't one do it ? It's not the same thing at all, dont you think ?

 

The original TAB lets the player sistematically spot every objects with no apparent reason (and people like me can't stand such things).

My solution would give a logical meaning to all this by implementing a dersirable function that extends the Detect Traps ability coherently, adding realism and discouraging the lazy playing. Truth is that the game concept about the TAB function should have been similar (or same) to what I suggest here from the beginning; and then, for "cheaters", there should have been a tweak that lets the TAB function always work (what ToB offers is a sort of "legal cheat", according to me) 

<{POST_SNAPBACK}>

 

You could make every single container in the game have a trap (which does nothing when triggered) that's set to be detectable at whichever percent you want, to indicate difficulty, and then disarmable at 1% or 0%. Trouble is, the PC would get XP for disarming it.

[Salk]

Yes, of course! But if a player instead wants to use the ABILITY of the thief who can spot objects by pressing TAB, why wouldn't one do it ? It's not the same thing at all, dont you think ?

 

The original TAB lets the player sistematically spot every objects with no apparent reason (and people like me can't stand such things).

My solution would give a logical meaning to all this by implementing a dersirable function that extends the Detect Traps ability coherently, adding realism and discouraging the lazy playing. Truth is that the game concept about the TAB function should have been similar (or same) to what I suggest here from the beginning; and then, for "cheaters", there should have been a tweak that lets the TAB function always work (what ToB offers is a sort of "legal cheat", according to me) 

<{POST_SNAPBACK}>

 

You could make every single container in the game have a trap (which does nothing when triggered) that's set to be detectable at whichever percent you want, to indicate difficulty, and then disarmable at 1% or 0%. Trouble is, the PC would get XP for disarming it.

<{POST_SNAPBACK}>

 

Very interesting solution,Ghreyfain!

 

There are some problems though: the biggest is that normal containers will just glow red as normal traps do just because they are set to have one.

 

My goal was to let containers/pickable objects (by the way, can the same apply to objects too ?) glow blue instead to differentiate them from traps.

 

The XP problem would consequencly become false by not having the player disarm the false trap (glowing blue) but just open the containier or pick up the object directly or to reward the successfull disarm trap with 0 XP.

 

Your workaround is certainly interesting though and deserves my compliments!

[Ghreyfain]

There are some problems though: the biggest is that normal containers will just glow red as normal traps do just because they are set to have one.

 

My goal was to let containers/pickable objects (by the way, can the same apply to objects too ?) glow blue instead to differentiate them from traps.

 

I realise what your goal is, but I'm trying to ground it in reality. It's the best idea I could come up with off the top of my head, and it's not very good, all things considered. Adding entirely new features like you suggest just isn't *possible.

 

*Okay, I'm sure it is, but the effort required would make it a silly waste of effort.

[Salk]

Thanks,Ghreyfain!

 

Speaking with egm, I took a big step forward.

 

This guy uses a scrpt of his own (it applies to ToB) to work around the problem (I found out he was trying to get to my same goal in a more realistic way).

 

And his method is partly just what you said!

If I had understood well, he selected a number of chests/doors that should be logically hard to find and make them detectable, like I thought too, with the thieving skill Detect Ability (a bug: the cleric spell Detect Ability doesnt work). The container is assigned a harmless trap and is invisible untill detected. Detection trigger a string of dialogue.

 

Please take a look here:

 

--------------------------------------------------------------------------------------------------

IF

Global("ContainerStuff","ARxxxx",0)

THEN

RESPONSE #100

ContainerEnable("Cont01",0)// the cntainer is

disabled by default

SetGlobal("ContainerStuff","ARxxxx",1)

END

 

This particular block ensure that the container can

only be discovered once...

 

Then, I make a trap (named traps01) with the same

positions than the container. Its script must contain:

 

 

IF

Detected([ANYONE])

Global("ContainerStuff","ARxxxx",1) //ensure that

party got the XP only once and all the stuff is

proceeded just once

THEN

RESPONSE #100

RemoveTraps("Traps01")//the trap is removed

ContainerEnable("Cont01",1)//the container is

enable

DisplayStringHead(LastTrigger,XXXXX)//You have

detected a secret container!

AddexperienceParty(YYY)//in my mind, those secret

containers are important for quests, so detecting them

is rewarded

SetGlobal("ContainerStuff","ARxxxx",2)

END

 

It's not very hard to do, but implementing this in

BgTutu requires to add several blocks to areas'

scripts, as well as creating many traps.

When the trap is revealed, there's the same red

overlay (it fades quickly) as usual. My method works

fine with doors and containers.

--------------------------------------------------------------------------------------------------

 

Do you think it possible to do the same for TuTu ?

 

I am no modder so I'd need somebody willing to do this and I'd help as much as I can with testing...

[igi]

Tutu runs on the BG2 engine, and so has access to the same features as BG2.

(Thats a yes).

[Salk]

Okay...Then I do need somebody who has free time, shares my (and egm's) opinion , and that is willing to add this script to TuTu (and perhaps even tweak it to make it better)! I tried reading SimDing0's complete guide to Scripting and my brain confirmed that I should not mess with such things!

[Domi]

Salk, I might be mistaken, but it seems to me that to implement this someone needs to go through every area, recording every container that does not have a trap on and meticulously add to each areal script.

It is relatively easy, but takes a LOT of time and research. So I suggest you do it yourself in these easy steps (obviously, test that it works after doing the very first area):

 

Step 1. Make NI run on your machine and familarize yourself with it.

Step 2. Open Override folder in NI and start going through each and every FWXXXX.ARE files writing down how many containers are there: they will show up in a separate window.

Step 3. Have not done that myself, but I assume that one can see if the containers are trapped or not in NI. Write down the ones that are not trapped

Step 4. Replicate egm's script for every area and non-trapped container as a seaparet text file with an expansion BAF, calling them something like N#FWXXXX.BAF where N# is your personal prefix and XXXX area number.

Step 5. Do it yourself or ask someone to make an installer that will append your scripts to every area in the game.

[igi]

Or learn weidu tp2 code, really really well.

[Domi]

well, he said he does not want to mess with anything complex. Creative coding is not something a novice could do, while replicating the already written script is quite feasable.

[devSin]

Note that the script won't actually prevent the containers from being highlighted - you just won't be able to access them until they're detected.

[igi]

Disclaimer

This code doesn't work. Though, it is a pretty good start. WeiDu could do with (even) more features to make life easier.

 

In the TP2

 

SET count = 0

COPY_EXISTING_REGEXP GLOB ~AR.*\.are~ ~override~  // don't do the XR area files
 READ_LONG 0x0070 "containerOffset"
 READ_SHORT 0x0074 "containerCount"

   WHILE (containerCount+1 > 0) BEGIN
       READ_ASCII (containerOffset + (containerCount * 192) + 0x0) "name" (32)
       READ_LONG (containerOffset + (containerCount * 192) + 0x0028) "flags"
       READ_SHORT (containerOffset + (containerCount * 192) + 0x002c) "detectionDifficulty"
       READ_SHORT (containerOffset + (containerCount * 192) + 0x0030) "trapped"
       READ_ASCII (containerOffset + (containerCount * 192) + 0x0048) "script"
       READ_ASCII (containerOffset + (containerCount * 192) + 0x0058) "name_maybe"  // (32)

       // NB. We should BOR the flag variable to disable the container, so we don't have to script it
       //  WRITE_LONG (containerOffset + (containerCount * 192) + 0x0028) "flags"

       // If the container has no attached trap, attach one
       PATCH_IF (trapped = 0) BEGIN
         WRITE_SHORT (containerOffset + (containerCount * 192) + 0x002c) 0  // detection difficulty
         WRITE_SHORT (containerOffset + (containerCount * 192) + 0x0030) 1  // trapped boolean
       END  // END PATCH_IF trapped = 0

       // If the container has no attached script, attach one
       PATCH_IF (script STRING_COMPARE_CASE "") BEGIN
           // NB. %count% doesn't seem to get evaluated on he next line
           WRITE_EVALUATED_ASCII (containerOffset + (containerCount * 192) + 0x0048) %count% #8
           INNER_ACTION BEGIN      
               COPY ~modDir/x.baf~ ~override/%count%.baf~
               REPLACE_TEXTUALLY _iiFTheObject_ ~%name%~  // Does't seem to work right. At all.
               REPLACE_TEXTUALLY __iiFTheTrap_ ~%name%~  // Trap name - is this %name% again?
           END  // END INNER_ACTION
       END  // END PATCH_IF ""

/*
       // The container has an attached script, so append out block to it
       // NB. We never seem to get here
       // NB. I use the inverse of the above condition, as I can't get the correct syntax for ELSE
       PATCH_IF NOT (script STRING_COMPARE_CASE "") BEGIN
           WRITE_EVALUATED_ASCII (containerOffset + (containerCount * 192) + 0x0048) %count% #8
           INNER_ACTION BEGIN      
               COPY_EXISTING ~%script%.bcs~ ~override/%script%.baf~
                 APPEND_FILE ~x.bcs~
                 REPLACE_TEXTUALLY _iiFTheObject_ ~%name%~  // Does't seem to work right
                 REPLACE_TEXTUALLY _iiFTheTrap_ ~%name%~  // Trap name - is this %name% again?
           END  // end INNER_ACTION
       END  // END PATCH_IF NOT ""
*/

// Maybe we need this for something, since no-one knows what it's used for, if anything
//      WRITE_ASCII (containerOffset + (containerCount * 192) + 0x0058) "name_maybe"  // (32)

     containerCount = containerCount -1  // One less container threatens the world
     count = count +1  // One more child of love and peace is born
   END  // end while

 

x.baf (x.bcs is just a compiled version of this)

 

IF
 Detected([ANYONE])
THEN
 RESPONSE #100
   ContainerEnable("_iiFTheObject_",TRUE)
   RemoveTraps("_iiFTheTrap_")
END

 

Apoligises for the terrible formatting and line-wrapping the board will impose.

 

I still think it's a very non-optimal solution. I'd be more inclined to use invisible creatures or some such, which would generally be more flexible.