Aller au contenu

Photo

making objects go from static to useable


  • Veuillez vous connecter pour répondre
23 réponses à ce sujet

#1
Laugh out loud

Laugh out loud
  • Members
  • 109 messages
 I was wondering is there a way I could write an action script that would be activated during a conversation that would cause an object to go from being a static object to being a useable object.  In case it matters, the object being converted is a door.

#2
Shallina

Shallina
  • Members
  • 1 011 messages
no you can't make a static into a usable object.



But you can make a no static object not usable or usable at will.

#3
PJ156

PJ156
  • Members
  • 2 982 messages
Or if it is a door you can lock and unlock it. Set it to key required and plot and the player will know it is there but not how to get through it.

PJ

Modifié par PJ156, 21 novembre 2010 - 10:19 .


#4
The Fred

The Fred
  • Members
  • 2 516 messages
You can of course destroy the existing object and replace it with another one, but I'm not sure if/how this works for doors.

#5
_Knightmare_

_Knightmare_
  • Members
  • 643 messages
Yeah, as Shallina said you can't make it non-static in game. Static objects can not be affected or destroyed, even through script. What you can do though is leave it Static = False and then Useable = False. The useable flag can then be changed via script to make it Useable = True. However, that all applies to placeables, doors have no Useable setting in their properties.

Best is probably to follow PJ's advice. Set it so that it requires a key. Seeing the door is useable but locked and not being able to open it yet will usually mess with the player's head (in a good way) more than just seeing a static door there anyhow. In your conversation, you can unlock the door via an Actions script on the appropriate convo node

Modifié par _Knightmare_, 21 novembre 2010 - 01:14 .


#6
Laugh out loud

Laugh out loud
  • Members
  • 109 messages
I was just hoping since it is technicaly a secret door to keep it hidden until the players find the hidden key.  I guess the way I have it with a painting covering it is the best way to go.  I'll just simply have the script remove the painting once the key is found.

#7
Dann-J

Dann-J
  • Members
  • 3 161 messages
You can always create a template for a usable version of the static object, then destroy the static one and replace it with the usable version using ActionCreateObject (in 'ginc_actions').



My 'kill/replace' script does the opposite (replaces usable with static), but the reverse should also be possible - provided static objects can be found via their tag and destroyed:



http://nwvault.ign.c...s.Detail&id=344



A destroyed object takes two seconds to fade away, so I use the ActionCreateObject wrapper to delay spawning the replacement by 2 seconds to prevent them doubling up briefly. I also assign the action to the PC rather than the destroyed object, since no actions (delayed or otherwise) can be queued up against an object if it is destroyed in the same script.




#8
_Knightmare_

_Knightmare_
  • Members
  • 643 messages

DannJ wrote...

My 'kill/replace' script does the opposite (replaces usable with static), but the reverse should also be possible - provided static objects can be found via their tag and destroyed:


The reverse is not true. Static objects can not be destroyed or interacted with in any way really - even via script.

#9
MasterChanger

MasterChanger
  • Members
  • 686 messages
Being able to create secret doors in general would be really useful. I know there are some tools for this on the Vault, but I have no idea how thorough or up-to-date they are.

Perhaps if this is for an interior it might suffice to use an appropriate placeable of some kind, which could then have an appeance change when it's slid open?

#10
Laugh out loud

Laugh out loud
  • Members
  • 109 messages
MasterChanger ~ In NWN2 secret doors can be found in the toolset under the doors section. You just have to tint them to match the walls where you place them. The problem is that they are too easy for the player to find. If they put the cursor pointer over the secret door it will still turn into a door symbol.

#11
MasterChanger

MasterChanger
  • Members
  • 686 messages

Laugh out loud wrote...

MasterChanger ~ In NWN2 secret doors can be found in the toolset under the doors section. You just have to tint them to match the walls where you place them. The problem is that they are too easy for the player to find. If they put the cursor pointer over the secret door it will still turn into a door symbol.


Right, the problem isn't the model--as you point out, that's available. Don't they also still light up when you press the key for interact-able objects ('z' by default) ? Not so secret, in effect.

#12
Dann-J

Dann-J
  • Members
  • 3 161 messages

_Knightmare_ wrote...

DannJ wrote...

My 'kill/replace' script does the opposite (replaces usable with static), but the reverse should also be possible - provided static objects can be found via their tag and destroyed:


The reverse is not true. Static objects can not be destroyed or interacted with in any way really - even via script.


Well, it should be. Whether or not the game allows you to do so is another matter entirely Posted Image

#13
The Fred

The Fred
  • Members
  • 2 516 messages
I think someone has produced a work-around for this (check the 'Vault) but whether they have or not, it should theoretically be possible to use the door models to make placeables which could cover actual doors - this prevents them from showing up when moused over.

#14
Dann-J

Dann-J
  • Members
  • 3 161 messages
In the original campaign, there was an area where you had to use an old box of blast globes to destroy some rocks (part of the Old Owl well quest). I don't seem to remember those rocks behaving like non-static placeables (ie. glowing when you hit the Z key, or changing the cursor when moused over). Is my memory faulty? Or were there some other tricks employed in that map?

#15
_Knightmare_

_Knightmare_
  • Members
  • 643 messages
It was most likely Static = False, Useable = False and Dynamic Collisions = True. That way they are not useable/selectable, don't z-glow nor can a creature walk through them. Unuseable placeables can be destroyed through script, just not static ones.

Modifié par _Knightmare_, 24 novembre 2010 - 12:11 .


#16
Dann-J

Dann-J
  • Members
  • 3 161 messages
That seems to solve the problem then.



I'm working on a 'secret door' script at the moment, that has a non-static non-usable collidable scaled cave rock seemlessly blocking a doorway (you can't tell it's not part of the cave wall unless you know exactly what to look for). The plan is to have its heartbeat script periodically check its search radius for party members with an appropriate search rank, and when it is 'found' the rock is destroyed and replaced by a cave secret door. That way nothing shows up with the Z key or if the cursor is over it. The down side is that with no closed door behind it, the 'secret' area is always visible on the map. Therefore I've got a locked 'decoy' grate elsewhere that can't be opened, so the way in isn't immediately obvious.



I'm using GetFirst/NextObjectInShape, and although it finds the PC as the 'first' creature it seems to be having trouble recognising other party members as 'next' creatures. I'll have to do some more experimenting.

#17
MasterChanger

MasterChanger
  • Members
  • 686 messages

DannJ wrote...

That seems to solve the problem then.

I'm working on a 'secret door' script at the moment, that has a non-static non-usable collidable scaled cave rock seemlessly blocking a doorway (you can't tell it's not part of the cave wall unless you know exactly what to look for). The plan is to have its heartbeat script periodically check its search radius for party members with an appropriate search rank, and when it is 'found' the rock is destroyed and replaced by a cave secret door. That way nothing shows up with the Z key or if the cursor is over it. The down side is that with no closed door behind it, the 'secret' area is always visible on the map. Therefore I've got a locked 'decoy' grate elsewhere that can't be opened, so the way in isn't immediately obvious.

I'm using GetFirst/NextObjectInShape, and although it finds the PC as the 'first' creature it seems to be having trouble recognising other party members as 'next' creatures. I'll have to do some more experimenting.


To double-check: are you using the placeable's heartbeat script, or a trigger's? I really think you'd be best off doing this with a trigger (OnEnter or OnHeartbeat, depending on the options you want to have).

#18
Dann-J

Dann-J
  • Members
  • 3 161 messages
I try to avoid triggers were possible (they're too unreliable), so I'm using the non-static non-usable placeable to run the HB. The problem with search checks and triggers is that once you've entered a trigger, you need to leave and re-enter to do another search check. So if your search circumstances change (ie. equip something that boosts search, or go into detect mode) the trigger won't know about it.

I'm using the party member's search skill + bonuses + ( 1D10 X [actively searching is TRUE ] ) compared to a search DC I set as a variable on the placeable. That way a player can find something in passive detect mode if their skill is high enough, and they get a 1D10 bonus on top of their search skill if actively searching.

I've noticed that the SoZ 'secret door' script loops through *every* creature in an area and discards those too far away and/or not in the PC's party. That sounds potentially laggy in areas with a lot of creatures about. I was hoping that the 'ObjectInShape' functions were a bit more efficient - if I can get it to recognise more than one target. It works great with just the PC, but I'd like other party members to be able to do their 'I've found something' voice-chat as well.

Modifié par DannJ, 26 novembre 2010 - 03:08 .


#19
Dann-J

Dann-J
  • Members
  • 3 161 messages
I think I've figured out my problem (well, one of my script-related problems). I was using GetMaster is valid or GetIsPC to check for either the PC or a roster member. This would have worked in NWN1, where henchmen were 'owned' by the PC, but apparently doesn't work in NWN2.

When I get home I'll try GetIsPC(object) or GetFactionEqual(object,GetFirstPC()) instead to check that a creature within the shape is a party member.

So maybe the script is working the way it should after all, and the scripter is to blame. Posted Image

Modifié par DannJ, 26 novembre 2010 - 04:11 .


#20
BigfootNZ

BigfootNZ
  • Members
  • 131 messages

DannJ wrote...

That seems to solve the problem then.

I'm working on a 'secret door' script at the moment, that has a non-static non-usable collidable scaled cave rock seemlessly blocking a doorway (you can't tell it's not part of the cave wall unless you know exactly what to look for). The plan is to have its heartbeat script periodically check its search radius for party members with an appropriate search rank, and when it is 'found' the rock is destroyed and replaced by a cave secret door. That way nothing shows up with the Z key or if the cursor is over it. The down side is that with no closed door behind it, the 'secret' area is always visible on the map. Therefore I've got a locked 'decoy' grate elsewhere that can't be opened, so the way in isn't immediately obvious.

I'm using GetFirst/NextObjectInShape, and although it finds the PC as the 'first' creature it seems to be having trouble recognising other party members as 'next' creatures. I'll have to do some more experimenting.


Wow, heh, we seem to be working on similar things... i tried this more or less the way you have a few months back. Seems you had all the same issues i did also, I however used an invisible door (a door with no model, there is one in the OC if I remember) filling the door frame. Its invisible to clicks and Z  and it hides the room you want hidden. Over this door a unuseable nonstatic boulder.

I used a trigger though that started a localised script on the triggerer that did checks if the character was in search mode, if not they couldnt spot the secret door, if they where a dwarf or an elf they got an automatic check thanks to elves always being in search mode and dwarves having stone cunning. If they left the trigger it ended the search checks, this allowed me to set the timing of the checks (2 per round) and avoid the problem of only having checks onenter and onexit.  If a check succeeded the rock became usable and on using the rock it destroyed it and teh door. The main problem was people walking through the trigger before the first firing of it happened (easily fixed by having an initial onenter check, which was mostly an elf problem since they can run and search at the same time... wasnt perfect, and sometimes bugged out but it wasnt to bad.

Im personally going to go with a custom AoE effect applied to the Rocks location by the Rock, since it will have both enter, exit and heartbeat scripts attached to them. Theres also the old NWN1 way where you just spawn something that lets the play teleport with party over to the hidden area and vice versa.

Modifié par BigfootNZ, 26 novembre 2010 - 09:25 .


#21
MasterChanger

MasterChanger
  • Members
  • 686 messages

DannJ wrote...

I try to avoid triggers were possible (they're too unreliable), so I'm using the non-static non-usable placeable to run the HB. The problem with search checks and triggers is that once you've entered a trigger, you need to leave and re-enter to do another search check. So if your search circumstances change (ie. equip something that boosts search, or go into detect mode) the trigger won't know about it.


Triggers have OnHB as well, not just OnEnter. The reason I recommended triggers is that a trigger's OnHB only runs when there's something standing inside the trigger area. I'm pretty sure a placeable's OnHB is going to run like a creature's, i.e. constantly. Maybe that doesn't matter to you, but I wanted to throw it out there.

Also, how are you defining the shape that you're checking inside of?

#22
BigfootNZ

BigfootNZ
  • Members
  • 131 messages

MasterChanger wrote...
Triggers have OnHB as well, not just OnEnter. The reason I recommended triggers is that a trigger's OnHB only runs when there's something standing inside the trigger area.


Eh what!?... **BigfootNZ does a backflip in surprise**... they do?.. good lord, you sure?.. ive never seen them...

**Runs to his NWN2 PC to check this earth shattering monumental revelation**

Honestly I had no idea they did... if true, all ill  be able to do is grin like spongebob for the next few hours.

Edit:- Wow so they do... how the HELL did I ever miss that?.. **starts grinning**

Modifié par BigfootNZ, 27 novembre 2010 - 12:28 .


#23
M. Rieder

M. Rieder
  • Members
  • 2 530 messages
I don't have the toolset in front of me, but are there placeables that look like doors? If so, then you could script them in the way Nightmare and Shallina described.

#24
Dann-J

Dann-J
  • Members
  • 3 161 messages

MasterChanger wrote...

Triggers have OnHB as well, not just OnEnter. The reason I recommended triggers is that a trigger's OnHB only runs when there's something standing inside the trigger area. I'm pretty sure a placeable's OnHB is going to run like a creature's, i.e. constantly. Maybe that doesn't matter to you, but I wanted to throw it out there.


That sounds even better - except that I just don't trust triggers very much. Too many times while testing a module I've sailed over the top of one like a ghost and not triggered it, or watched a creature do the same.

MasterChanger wrote...
Also, how are you defining the shape that you're checking inside of?


I'm just using a simple sphere with a radius defined by a variable on the placeable.

I've got the search script running like a dream - except for one rather major hiccup. It seems that CreateObject can't spawn in a door object. So instead I'm just using the search script to make the non-usable placeable usable, and either making it bashable, giving it a conversation, or attaching an OnUse script. It also has the option of spawning in another placeable, like a pre-defined lever blueprint.

Here's the script so far:

--

// Radius = search radius from object
// SearchDC = search rank required
// Spawn = resref of placeable to spawn (if using an Ipoint as the origin)

void main()
{
location lTarget = GetLocation(OBJECT_SELF);
float fRadius = GetLocalFloat(OBJECT_SELF,"Radius");
int iSearchDC = GetLocalInt(OBJECT_SELF,"SearchDC");
string sSpawn = GetLocalString(OBJECT_SELF, "Spawn");
int iSkill;
int iSearching;

if (GetLocalInt(OBJECT_SELF,"Found") == 1)
  return; // Don't check again if already found

object oSearcher = GetFirstObjectInShape(SHAPE_SPHERE, fRadius, lTarget, TRUE, OBJECT_TYPE_CREATURE);
while ( GetIsObjectValid(oSearcher) )
{
iSearching = GetDetectMode(oSearcher) == DETECT_MODE_ACTIVE;
iSkill = GetSkillRank(SKILL_SEARCH,oSearcher) + (d10(1)*iSearching);

// If a party member
if(GetFactionEqual(oSearcher, GetFirstPC()) || GetIsPC(oSearcher))
{
if ( iSkill >= iSearchDC )
{
PlayVoiceChat(VOICE_CHAT_LOOKHERE, oSearcher);
SetUseableFlag(OBJECT_SELF,1);
effect eVis = EffectNWN2SpecialEffectFile("fx_nolaloth");
ApplyEffectToObject(DURATION_TYPE_TEMPORARY,eVis,OBJECT_SELF,10.0);
PlaySound("sim_magsee");
SetLocalInt(OBJECT_SELF,"Found",1);

if (sSpawn != "")
{
CreateObject(OBJECT_TYPE_PLACEABLE,sSpawn,lTarget);
}
}// end if found object
}// end if party member
oSearcher = GetNextObjectInShape(SHAPE_SPHERE, fRadius, lTarget, TRUE, OBJECT_TYPE_CREATURE);
}// end while
}