47 réponses à ce sujet

[Dann-J]

The process would be made even more difficult by having to cycle through all equipped items first to check whether they have any 'light' properties. You don't want to be equipping and unequipping torches if there is already another light source equipped.

For characters with no light-emitting equipped objects that also have low-light or darkvision, you could always fake things by adding the appropriate effect to them. The OnClientEnter script could:

- Check whether ultravision is active when a character enters (if it's already on, do nothing)
- If it's not, and they have an ultravision feat, and no equipped light-emitting effect, then add a 'fake' low-light or darkvision effect to the character.
- Create another script that fires whenever a combat mode is activated or deactivated (IF such an event exists)
- Remove the 'fake' effect if that combat mode was an ultravision feat
- Also remove the 'fake' effect when leaving a darkened area

That all depends on whether activating/deactivating combat modes fires some sort of event number though.

[Lance Botelle]

kevL wrote...

well, the possible issue i see is ... what if their offhand (torch-hand) item is granting a Prime Ability bonus for a caster ( say +Wis for Cleric ), suddenly they're gonna lose a few memorized spellslots, no?

Hi KevL,

I don't normally have any items that do this kind of benefit for equippable "hand" items, but I can see your point if this was the case.

kamal_ wrote...

Lance Botelle wrote...
Trust me, a player definitely would want to equip a light source or turn on night vision in these cases.

In Path of Evil I had absolute pitch black areas with no lights anywhere, no one complained.

Given the amount of difficulty in implementing this, it seems like it's not really worth the trade in effort versus effect. It sounds like you've done the background work, area variables and having OnEnter scripts and such, so I would leave it out for now so it doesn't stop development. It could always be added later since the background stuff is in place and the only thing that would need to be done is updating of scripts, which can be done via a patch hak at any point.

With good project management, at some point, you have to know when something just isn't working and let it go so the project as a whole can get done.

Hi Kamal,

You are right Kamal. I gave up trying to implement the "Night vision" and went for light source only a couple of days ago. I agree that I need to try to focus on those other aspects really.

Sometimes, I get distracted though ....

DannJ wrote...

The process would be made even more difficult by having to cycle through all equipped items first to check whether they have any 'light' properties. You don't want to be equipping and unequipping torches if there is already another light source equipped.

Hi DannJ,
I already had a function to do this and made those checks.

For characters with no light-emitting equipped objects that also have low-light or darkvision, you could always fake things by adding the appropriate effect to them. The OnClientEnter script could:

- Check whether ultravision is active when a character enters (if it's already on, do nothing)
- If it's not, and they have an ultravision feat, and no equipped light-emitting effect, then add a 'fake' low-light or darkvision effect to the character.
- Create another script that fires whenever a combat mode is activated or deactivated (IF such an event exists)
- Remove the 'fake' effect if that combat mode was an ultravision feat
- Also remove the 'fake' effect when leaving a darkened area

That all depends on whether activating/deactivating combat modes fires some sort of event number though.

This is the more involved part that I have decided not to worry about for now. However, maybe after I have the module out, it could be something to consider in the future.

The good point is, I do have a function that overcomes the immediate darkness for the player - unless they are completely without any form of light source, in which case, they currently have to turn on their own "night vision" ... or remain in the dark

Lance.

[Dann-J]

Apparently there's something called a 'GUI callback' that can fire events. Event 2051 (EVENT_ROSTER_SPAWN_IN) is apparently fired in that way.

I don't know much about GUIs, but if it's possible to trigger a custom event number from a modified GUI, then the process I outlined should be possible (albeit probably quite complex).

[kevL]

The problem with the .Xml for the modebar -- one of them -- is that the buttons are not laid out all nice and well defined. Instead they're laid out by a 'prototype' button, and a hardcoded Gui function inspects the PC internally and decides what buttons to actually show on screen. If they were laid out individually, a script or 'callback' could be fired by pressing the Nightvision toggle, but as it is any solution would be ... inelegant

(maybe involving a HB that checks for when ActionMode #24 gets turned on)

[Dann-J]

After about half an hour trawling through GUI files, I figured out the right function.

In modebar.xml under the MODEBAR_GRID section, I added the following line:
OnLeftClick0=UIObject_Misc_ExecuteServerScript("gui_mode_used")

Now whenever a combat mode button is clicked, a script called gui_mode_used runs. That script could check whether ultravision is active, and whether the character currently has a 'fake' low-light / darkvision effect, and if both were true then the 'fake' effect could be removed to prevent it doubling up with the 'real' effect.

[Lance Botelle]

Hi DannJ and KevL,

It looks like KevL answered DannJ first post, and covered what I was going to type. i.e. It's not easy to get at the individual button being pressed for NightVision within the modebar.xml.

DannJ wrote...

After about half an hour trawling through GUI files, I figured out the right function.

In modebar.xml under the MODEBAR_GRID section, I added the following line:
OnLeftClick0=UIObject_Misc_ExecuteServerScript("gui_mode_used")

Now whenever a combat mode button is clicked, a script called gui_mode_used runs. That script could check whether ultravision is active, and whether the character currently has a 'fake' low-light / darkvision effect, and if both were true then the 'fake' effect could be removed to prevent it doubling up with the 'real' effect.

As you are probably aware, I am familiar with the UIObject_Misc_ExecuteServerScript callback; and the suggestion you make (DannJ) may be quite a good workaround.  However, I would have to take care handling the toggle state of the "night vision" switch, although carefully managed variables should resolve this. e.g. The switch state would (most likely) be "off" when the fake effect is applied. So when the player clicks to turn the fake effect off (which is mimicing the real one), it would be trying to switch the "real" effect back on. As I say though, checking variable states should be able to make sense of this.

OK DannJ, as you seem to be as keen as I was about this, I will look at trying this method out.

I will keep you updated.

Lance. 

Modifié par Lance Botelle, 14 février 2013 - 09:44 .

[Dann-J]

Yes, that's the main drawback of the method. You'd have to double-click to turn the effect off completely. Most work-arounds in NWN2 tend be on the clumsy side though.

I can see lots of other applications. Going into a certain mode in a certain location could broadcast what you are doing to an NPC within line of sight. Going into stealth mode right in front of them could result in a warning to "stop creeping around". Turning on power attack could be seen as provocative. Searching too intently in certain areas could raise the hackles of any NPCs who would rather you not discover certain things.

The XML approach is slightly better than a heartbeat approach, since the script only fires when you actually use the combat mode buttons (rather than every six seconds). Things get complicated if you have multiple combat modes on at the same time though, and you could also circumvent things by turning them on out of sight of the NPC before approaching.

010010's Enhanced LevelUp & Events Demo certainly looks interesting. I've started looking though the guts of the XMLs to see how they tick:
http://nwvault.ign.c...s.Detail&id=295

And of course there's the GUI/XML beginners tutorial by some guy named Lance.
http://nwvault.ign.c...ls.detail&id=92 

Modifié par DannJ, 14 février 2013 - 10:08 .

[kamal_]

DannJ wrote...
Going into stealth mode right in front of them could result in a warning to "stop creeping around". 

I pretty much already do that in Crimmor if they perceive you in stealth mode and you're somewhere you're not supposed to be. I can grant access to areas as well, making it ok for the player to be there. Because I do that I don't have any speaktriggers. I don't detect entering stealth mode, just being in it. OnPerception stinks though, and I have to run a custom script via the heartbeat.

[kevL]

DannJ wrote...

The XML approach is slightly better than a heartbeat approach, since the script only fires when you actually use the combat mode buttons (rather than every six seconds).

except w/ a pseudo-HB you can take down two three birds with one script: checking for Nightvision, also for an equipped light emitting item, plus for Light effect from spell. Said script could be started from onEnter for each possessible character, provided they don't already have a lightsource, and stopped when they activate Nightvision or equip a light emitter or get Light cast on them. Or the dweomer could simply expire along with the pHB after say 30s.

- whether it'd be 'best' with one repeating script cycling through all entering (possessible) characters, or fired individually for each, dependent on a local_var set by the onEnter, idk ... curious what Lance comes up with.


Edit. after re-reading that I'd think each character should run its own pHB: cycling all those characters and effects in a single running script is kinda intensive. And if it runs on each char individually the pHB can shut right down when none are in the area; no need for an area-wide script to go checking up on all creatures,

Modifié par kevL, 14 février 2013 - 11:23 .

[Lance Botelle]

Hi All,

DannJ:  I think I should be able to (possibly) get around the double-click problem. However, I did not have as much time to look at this issue today and so will have another look tomorrow (if all goes well). That tutorial is certainly a good read ... maybe I ought to try to remember some of it.   UPDATE: I am not sure I am going to get away from avoiding the double-click after all. I'll look a little more in the days ahead.

Kamal: I got distracted again.

KevL: Actually, this thing I am doing is using the best of both worlds: XML callbacks (when clicked on) and the heartbeat script to do an initial check after entering.

I will post the XML and function (called from a heartbeat) when and if I am successful doing this.

Lance.

Modifié par Lance Botelle, 15 février 2013 - 05:42 .

[Dann-J]

I've been fooling around with the settings in feats.2DA in the hope that something in there would solve the problem. I found a column called Togglemode that corresponds to the combatmode.2da line number, but setting the dark/low-light vision feats to '24' didn't make any difference. I tried setting the feats to active (so they can be dragged to hotbar slots), but that didn't work either. It allows them to be activated from the hotbar though, and the button on the mode bar activates at the same time.

It seems that SetActionMode will only turn off a subset of combat modes, and will turn on ever fewer. So far I've confirmed that Defensive Casting, Power Attack and Parry will all turn on and off on command. I'm unable to turn Detect, Tracking or Stealth on via script though, although Tracking and Stealth can be turned off. I've had no luck turning Detect on or off.

If there was a way of activating feats that don't target anything, then I think the problem could be solved that way. I've been unable to use ActionUseFeat on any of the non-targetting combat modes though. The game engine complains if you use the PC as the target object, even if the feat isn't set to Hostile.

Damn all this hardcoding...

[Lance Botelle]

DannJ wrote...

I've been fooling around with the settings in feats.2DA in the hope that something in there would solve the problem. I found a column called Togglemode that corresponds to the combatmode.2da line number, but setting the dark/low-light vision feats to '24' didn't make any difference. I tried setting the feats to active (so they can be dragged to hotbar slots), but that didn't work either. It allows them to be activated from the hotbar though, and the button on the mode bar activates at the same time.

It seems that SetActionMode will only turn off a subset of combat modes, and will turn on ever fewer. So far I've confirmed that Defensive Casting, Power Attack and Parry will all turn on and off on command. I'm unable to turn Detect, Tracking or Stealth on via script though, although Tracking and Stealth can be turned off. I've had no luck turning Detect on or off.

If there was a way of activating feats that don't target anything, then I think the problem could be solved that way. I've been unable to use ActionUseFeat on any of the non-targetting combat modes though. The game engine complains if you use the PC as the target object, even if the feat isn't set to Hostile.

Damn all this hardcoding...

Hi DannJ,

Thanks for all this feedback. It is useful.

I agree that getting to some of those "abilities" within the Mode bar are very difficult indeed. (Hard-coded.) I also tried to see if the "night vision" effect could be detected via script (in a way that it could be acted upon), but could not do so. It does not return as an effect as such, even though it uses the darkvision SEF by the looks of things.

I think I may have to accept that there may not be a way around avoiding the double-click problem.

I am still looking at this though, so do keep me updated if you are able to "get" the "night vision" ability in any way.

Cheers,
Lance.

UPDATE: I gave up trying to capture the "Dark Vision" effect to turn on or off and simply sent a message to the player saying they needed to click the button again to disable darkvision if they were attempting to turn it off after I had given them the Dark Vision effect for having that ability. They won't even get this message unless they want to use a different light source instead, as I will automatically remove the effect when they leave the area anyway.

However, if anybody is successful in "getting" the effect to allow it to be removed, then please let me know.

Modifié par Lance Botelle, 16 février 2013 - 05:25 .

[Lance Botelle]

Hi All,

Well, I decided to make do with a 99% good result: The PC being controlled will now no longer enter a 100% dark area without automatically checking for the ability to see in the area.

Now, an area that has a variable set on it will make the PC being played at the time do one of the following (in priority):-

1) Enable Dark Vision or Low Light Vision if capable.
2) Stop auto light if an equipped item has the light property.
3) Equip a torch or lantern if carried.
4) Take and equip a torch or lantern from a party member if not carried themselves.

I had considered moving the equipped light property check before the night vision checks (dark and low light vision), but felt the natural thing would have one's own natural vision take priority.

The Night Vision auto activation works just like the Dark Vision or Low Light Vision feat button in the mode bar, in that only the PC that has the night vision sees with it. i.e. If you change PC, the SEF used turns off until you possess the PC that had the night vision in question, so a player does not gain an advantage of being able to see from another PC by the SEF effect attached to the PC that does have the feat.

The only caveat to how this auto-activation works, is that if a player clicks on the night vision button to turn the auto-activation off, they get a message saying they have to click the button again to do so. I don't think thats such a hardship for the auto-activation usage.

Furthermore, when the PCs leave the dark area, the auto-activation will automatically turn off again, so a player may never need to use the night vision button, unless they wish to override the auto functionality.

I have defined my own fx_low_vision to replace the OC fx_lowlight_vision sef so as not to clash with the lowlight vision spell.

Any comments, please let me know.

Cheers!
Lance.

Modifié par Lance Botelle, 16 février 2013 - 10:24 .

[Dann-J]

That sounds like a good compromise.

I've noticed that if you transition to a new area with ultravision already active that you lose the SEF, and have to turn the mode off and on again. I suppose you could add the effect back if your script checked for the feat being active when you entered the area. At least in that instance, turning the mode off manually would actually turn it off without the need to click twice.

[Lance Botelle]

DannJ wrote...

That sounds like a good compromise.

I've noticed that if you transition to a new area with ultravision already active that you lose the SEF, and have to turn the mode off and on again. I suppose you could add the effect back if your script checked for the feat being active when you entered the area. At least in that instance, turning the mode off manually would actually turn it off without the need to click twice.

Hi DannJ,

I just tested the area transition you mention (while on) and the night vision remained active!

Therefore, I am not sure what it is you are experiencing ....  .... which of course means I do not need to worry about this being an issue.

Could you double check this again and tell me what happens?

Many Thanks,
Lance.

[Dann-J]

Losing the ultravision effect when transitioning to a new area is a known bug:
http://social.biowar...5690489#5691005 

It sounds like your script might not be checking whether ultravision is active or not and adding the effect regardless, which would solve the ultravision bug automatically.

If ultravision was working properly, then not checking whether it was already on would result in a double-dose of the VFX. But it's not. So it isn't.

[Lance Botelle]

DannJ wrote...

Losing the ultravision effect when transitioning to a new area is a known bug:
http://social.biowar...5690489#5691005 

It sounds like your script might not be checking whether ultravision is active or not and adding the effect regardless, which would solve the ultravision bug automatically.

If ultravision was working properly, then not checking whether it was already on would result in a double-dose of the VFX. But it's not. So it isn't.

Hi DannJ,

I recognised that post.  Funny enough, I have not experienced that bug. HOWEVER, my checks are for DARKVISION and LOWLIGHTVISION and not ULTRAVISION. Is there a difference?

That said, you have got me curious now and I wll remove my code to see what happens when I transition without it .... just to try to experience that bug.

Back in a minute .....

UPDATE: OK, I just tested default PCs Adaur (Darkvision) and Caled (Low Light Vision). Switched both their Enhanced Visions on and transitioned to a new area and they both still worked fine!

Can you check the same your end and let me know if you definitely experience this problem?

ALSO, were you aware that the enhanced vision only works for the PC who has it? What this means is that if you are playing a PC other than your main PC and turn on that PC's enhanced vision and transition ... you may be being switched back to your main pc (who does not have enhanced vision) and so it may appear to be turned off. However, switching back to the PC who has it will make it come back on again. It may be depending on how the transition handles PC possession.

(YOU TUBE VIDEO OF TRANSISTION)   <--- Link only shows normal nightvision usage and not broken. It does not show my updated version which automatically turns on when entering a total dark area.

Lance.

Modifié par Lance Botelle, 18 février 2013 - 10:46 .

[Dann-J]

The low-light/darkvision effect has never persisted across areas for me. It might be graphics card related, in which case it might not be a problem for everyone. I've learned to live with it.

EDIT: Do you have Skywing's Client Extension by any chance? Apparently that fixes the vision FX problem after a transition.

Modifié par DannJ, 19 février 2013 - 02:41 .

[Lance Botelle]

DannJ wrote...

The low-light/darkvision effect has never persisted across areas for me. It might be graphics card related, in which case it might not be a problem for everyone. I've learned to live with it.

EDIT: Do you have Skywing's Client Extension by any chance? Apparently that fixes the vision FX problem after a transition.

Hi DannJ,

No I do not have that extension.

I can also let you know that this effect works with both a Radeon and a Geforce graphics card, so the problem may be related to something elsewhere.

If you have two basic connected areas (from scratch and nothing else interfering), do you still get the problem? If you do, send me the two basic areas and the script that links them and I can take a look for you if you like.

I think you should be able to have that working.

Lance.

[Dann-J]

It's always been a problem with every module I've ever played. It's a widely known bug, so plenty of other people have also encountered it (otherwise Skywing wouldn't have gone to the trouble of fixing it in his Client Extension). It's not exactly a game-breaker though.

[Lance Botelle]

DannJ wrote...

It's always been a problem with every module I've ever played. It's a widely known bug, so plenty of other people have also encountered it (otherwise Skywing wouldn't have gone to the trouble of fixing it in his Client Extension). It's not exactly a game-breaker though.

Hi DannJ,

Isn't it strange how one can go for years without experiencing a certain bug.  

Hopefully you noticed the video link two posts above and took a look at the transition where night vision was not affected.

In that case, one other thing that may be worth trying (but only if you wanted to), is to delay the jumping to the new area by a fraction of a second to see if that made a difference. That's how all my transitions work compared to most people's.

I'm just one of those people who likes to get to the bottom of a problem and know why something is not working as it should be. Maybe I can take a look at Skywing's work to see if I can notice what we might have in common that was causing the problem for so many people.

Cheers, Lance.

Modifié par Lance Botelle, 19 février 2013 - 10:10 .

[Dann-J]

It turns out that low-light vision persists across areas for me. It just seems to be darkvision that doesn't. It seems that I don't play as elves or gnomes very often.

[Lance Botelle]

DannJ wrote...

It turns out that low-light vision persists across areas for me. It just seems to be darkvision that doesn't. It seems that I don't play as elves or gnomes very often.

Hi DannJ,

How strange? Maybe there is a file conflicting somewhere. As you can see from my video, I get consistency in both.

Anyway, if I ever finish this module, and you have the chance to play it, maybe you can "see" what happens there.

Cheers!
Lance.