28 réponses à ce sujet

[Batmanis64]

Can this be done?  Here's the scenario I'm looking at:

There are lots of chests, caches, etc., strewn about my game world.  It is easy to just hit "tab" or whatever hotkey you're using to highlight these objects.  Wouldn't it be great for the player to only be able to use this feature when a wizard casts a custom spell?  For those of you who played the original Betrayal at Krondor, it would emulate the "Eyes of Ishap" spell.

So, basically what I'm looking for is a script to set hotkeys.

Modifié par Batmanis64, 20 mars 2011 - 08:59 .

[dethia]

Don't think this is possible hence no replies. It would mean editing the INI file which I wouldn't suggest doing even if you've found a way to.

[Lance Botelle]

Hi Batmanis64,

The best option here would be to make use of one of the hotkeys already in use, but "hijack" its use if within vicinity of the object you want it to interact with.

E.g. We know we can use "R" to rest or "I" to open an inventory, and both of these (as well as many others) can have their code intercepted by editing the GUI XML files.

So, for example, if you are within 10' of a chest and you press the "R" key, it will run the chest code you want rather than the rest code.

You could redefine the key you choose as your "interaction" key that has a default action of resting (if using the R key for instance).

Lance.

Modifié par Lance Botelle, 21 mars 2011 - 02:03 .

[Batmanis64]

Interesting idea, but what if the player wants to actually rest when near a chest?

Do you know which XML file deals with the highlighting of usable objects? I could simply turn it off by editing that file like I did with the spell selection GUI, and then have the custom spell perform a special effect over usables for a temporary period of time.

[M. Rieder]

Here's a work-around:

We will use the idea of a chest as an example.


1) Set chest useable flag to false.
2) Surround the chest with a trigger of abou 8 to 10m radius
3) Invent a special spell to highlight the objects.
4) Put a local int on your object to identify it.
5) Put a script on the trigger so that when a player enters the trigger, it makes the chest useable (and it can be highlighted, but only at the short range when the player is in the trigger).
6) When you cast the special detect spell, you will make the chest useable and maybe make some sort of effect appear above it, or script it to turn colors appropriately.


I think this should accomplish what you want, and it really won't be that much work.

[Batmanis64]

Another great idea, but how would a player know to approach an object that is usable, without walking right next to it or CONSTANTLY casting the custom spell? I still want the object to highlight when moving the mouse cursor over it. Ultimately it would be great to simply get rid of the highlight option.

[M. Rieder]

There is a way around that as well. You can put a small collision box over the chest, make it walkable and useable. Script the collision box to disappear when the PC enters the trigger which will allow the chest to light up.

[PJ156]

Would this work?

Create your chest that is usable.

Create a second static chest as an environmental object, scale it to 1.1 and place it over your usable chest as a skin. Give it a certain tag which is shared with all such skins.

When your player casts the spell have it centered on the PC and search for all items with the skin tag within the spell radius. Destroy all these object revealing the usable item underneath. 

Have not tried this, just throwing a possible into the pile.

PJ

[Batmanis64]

Well, I checked out the keymap.2da file, and when I edit it, it removes the availability of ALL customizable hotkeys (the menu in the game just appears blank), but maybe this is on the right track.

[Lance Botelle]

Batmanis64 wrote...

Interesting idea, but what if the player wants to actually rest when near a chest?

Do you know which XML file deals with the highlighting of usable objects? I could simply turn it off by editing that file like I did with the spell selection GUI, and then have the custom spell perform a special effect over usables for a temporary period of time.

Hi Batmanis64,

If you make the check range < 2.0 (experiment with best distance), then resting can take place about one step away from and without actually interacting with the chest.

Hilighting is not really required, unless you want to add more scripts (triggers etc.) to enable this. The reason being, the moment the PC is next to the chest you wish to interact with, you simply use a GetNearestObjectByTag to acquire the chest you are near to interact with when the XML related hotkey is pressed.

Any button that has an editable XML file can do what you want. Those I can think off the top of my head are:

R- Rest
I - Inventory
M - Area Map
N - Mini Map

All these buttons fire off a related XML file, which you can edit to fire its own gui_script script, which can be made to check its vicinity to a chest prior to carrying out its default function. The easiest to work with would be the R (rest) as this has some scripts that are checked prior to opening the GUI, which means you definitely could use it to do something other than rest, without even seeing the GUI as well. (I did something similar in my NWN1 module, Soul Shaker.)

REST BUTTON
===========

If you then alter the module's On Rest to intercept the call to rest, you can have it fire your own code subject to conditions you write in the On Rest script.

Pseudo Code ..... Module's On Rest

object oChest = GetNearestObjectByTag("ChestToOpen");
if(GetDistanceToObject(oChest) < 3.0){ Run chest code ...  cast spell or whatever}
else{ Run resting code.}

I am sure there are a number of other checks you could add as well if you like. There is nothing to stop you from even offering the player a choice of what they intended to do if they select R while sitting on top of a chest, but you think they may be wanting to rest. However, I think if the player is made aware that the R button can be used to interact with chests if they stand next to them (within 3.0), but rest when not next to one (> 3.0).

Lance.

Modifié par Lance Botelle, 21 mars 2011 - 11:31 .

[Batmanis64]

I GOT IT!  It WAS the keymap.2da file, the only reason it wasn't working before was because I was editing it in the toolset itself. Using Notepad++, I inserted a blank entry for "Inspection," and voila, no more inspection binding, and no more highlighting of all objects on the adventure screen. YAY!

Modifié par Batmanis64, 22 mars 2011 - 04:03 .

[M. Rieder]

Well done!

[Lance Botelle]

Batmanis64 wrote...

I GOT IT!  It WAS the keymap.2da file, the only reason it wasn't working before was because I was editing it in the toolset itself. Using Notepad++, I inserted a blank entry for "Inspection," and voila, no more inspection binding, and no more highlighting of all objects on the adventure screen. YAY!

Hi Batmanis64,

Sorry, I only just understood what you were on about ....

I must have sounded like a madman  going on about XML files.

My attention has been a little off lately. I thought you wanted to make a hotkey that did a spell for a certain situation.

Glad you sorted your issue.

EDIT: By the way, I think there is another way to do this, which was detailed a long while ago. If I find it, I will post a link.

Lance.

Modifié par Lance Botelle, 22 mars 2011 - 12:12 .

[Batmanis64]

Thanks for your help everybody! Lance, perhaps the other way of doing this has to do with the targetobject.xml (or, targetcreature.xml) file. There are several lines in there referring to UPointLights, colors, etc. that I assumed had to do with the "glow" of the targeted object, but messing with it made no difference.

[Batmanis64]

Hey Lance, you were mentioning another way of doing this? My solution has hit a snag- the keymap.2da does not work in hak packs or campaign folders, only in the override.

[M. Rieder]

I don't see a problem with using the keymap.2da in the override. When you release you can just instruct players to put it in their override and remind them to take it out when they want to use the "z" key again. It wouldn't bother me.

[Lance Botelle]

Batmanis64 wrote...

Hey Lance, you were mentioning another way of doing this? My solution has hit a snag- the keymap.2da does not work in hak packs or campaign folders, only in the override.

Hi Batmanis64,

No, I have not really looked into this. I had misunderstood what you were after.

However, as M. Rieder says, allowing the player the option by using the override is probably the best solution anyway. After all, one of the reasons why the "Z" key was enabled was to prevent players from having to play "hunt for the interactive objects".

That said, I do agree that *some* objects should be made harder to find because of their very nature. For this, I have adopted a system that checks for the PCs location to the object and makes it "useable" (what the "Z" key checks for) only if (a) they make a succesful search roll or ( I allow automatic find simply due to proximation. To set this up, disable "useability" for any object in the toolset and have a check in its HB script that will swicth useability back on again, subject to the conditions you want met.

This works very well for me and I have used it in a number of situations. E.g. Secret doors really are secret unelss found in my game.  (EDIT: This was a poor example and actually uses different code. See later post. However, I do have placeable objects that do exactly what I explain above.)

Lance.

Modifié par Lance Botelle, 02 avril 2011 - 11:02 .

[Morbane]

Lance,

How did you make a secret door "not useable"? From what I can tell there isn't such a flag on doors.

[Lance Botelle]

Morbane wrote...

Lance,

How did you make a secret door "not useable"? From what I can tell there isn't such a flag on doors.

Hi Morbane,

It was a poor example actually (previous post edited to reflect that now), but ....

I talk about my secret doors in this blog post. Links and credits within. I did have to alter the code for my liking. They use slightly different coding than other items that I wish to keep hidden, but the principle of keeping items "not useable" until desired was the main thing I was trying to support. I actually have other code for keeping placeable "not useable", which is quite possible.

The images have been made brighter so the door stands out easier. However, in the shadowy settings that are normally used, such doors will be less obvious visually - and as I say, hovering over them will not reveal them either.

Lance.

Modifié par Lance Botelle, 02 avril 2011 - 11:02 .

[Morbane]

Yep, I went the placeable route as well.

I do like the way you open the secret, it is a nice touch.

[Morbane]

@Lance

Do your placeable secret doors actually move out of the way to allow passage or do they respawn out of the way?

[Lance Botelle]

Morbane wrote...

@Lance

Do your placeable secret doors actually move out of the way to allow passage or do they respawn out of the way?

Hi Morbane.

They spawn out of the way and back into place. I'm not clever enough to do animations.  

Lance.

[Morbane]

AH, ok. Too bad. I was hoping you figured out a way to do it.

[MasterChanger]

Lance Botelle wrote...

Morbane wrote...

@Lance

Do your placeable secret doors actually move out of the way to allow passage or do they respawn out of the way?

Hi Morbane.

They spawn out of the way and back into place. I'm not clever enough to do animations.  

Lance.

It's just a question of marketing. It's not that you're "not clever enough", it's that you're using a "charmingly classic stop-motion style."

[M. Rieder]

Here is how you *could* fake it. You would position several door placeables in the appropriate position for a door movement, then script them not useable and set scale very small. then when the door opend, you can sequentially make the different placeables large then small again to get a stop motion door opening effect. In theory, I think it would work, but I've never tried it.