Invisibility

I know it was only a short while ago I spoke about the same topic of invisibility, but as I have been working on this in the toolset again, I thought I would blog about it again too. I felt this ability required special attention as it affected the way a PC could interact with the environment more than most other effects. Furthermore, as I have increased the duration of the invisibility spell to 10 minutes per level from its original 1 minute per level, there is a greater chance of its impact during play. (NB: Spells that last 10 minutes per level, like invisibility, are subject to game time warping. i.e. Time passes in game time amounts when lasting longer than ten minutes.)

The idea I have in mind is to try to allow invisibility to make more of an impact in some situations if used by the player. I imagine most players will prefer the direct approach and confrontation to problems in a game, but there may be a few who like the idea of playing more stealthily in some situations if possible. That's the idea anyway, and to this end I have set some "safety-nets" in place. These safety-nets have primarily been set in conversations, where a PC is protected from automatically becoming visible when given the choice to talk to an NPC. I have had to make some amendments to this code, such as allowing a PC to be able to talk to another player or inanimate object, but overall, the tests appear to be quite playable to date.

GetNearestCreature(NOT_MY_PC)

On a side note, I discovered that using the GetNearestCreature with the parameter to not return a PC (NOT_PC), will still return a companion. (i.e. A PC not currently controlled by the player.) I thought this was a little misleading, so mention it now. I had to make my own function in the end to ensure the nearest creature was an NPC rather than a companion. I then checked over all my other scripts that had made the same assumption and corrected those.

Playing Poll Results

The latest poll ended last week and here are the results from 25 voters:

I was most encouraged to see that 40% of the voters will be playing the module as a multi-player game. As regular readers of this blog will know, Better The Demon (and other modules I make) are designed MP from the base up. This is not a SP to MP conversion, but all systems are designed with MP in mind from the very start. I have to say that I have slipped up on occasion. However, as all testing I do involves a MP test every now and then (using two computers), any MP issues that do appear are addressed as soon as they are brought to my attention.

I am also pleased to see that 16% of players will be trying an "evil" approach to the game. It will be interesting to see if any others change their style during play - simply because the "evil" path is easier to play than the "good" path. Also, if their are players who try both "good" and "evil", I will be interested to see what options they take in each case.

Very encouraging is to see players who will play the game more than once - assuming they are pleased with the module in the first place. In these cases, I will be interested to hear if their different experiences were due to playing different alignments or during SP and MP gaming.

In all, the results were very interesting to me and I look forward to getting this beast out (at least this first part) as soon as I can to start receiving some feedback.

Focus & Return (GUIs)

I continue to thrash out the story for Better The Demon, which is slowly coming along in the way of added conversations. However, I have also been looking at some minor issues to do with the new GUIs that will be available in the game. In particular, there are some GUIs that are presented to the player which require a text input. Previously, the player had to click in the text input box and then type what they wanted to say, followed by clicking on another button. This all worked well enough, but I found during testing that it was more natural for me to want to type in information the moment the GUI appeared and then simply hit the Return key to enter my input. To this end, I did a little checking over some OC files to see how it was done ...

Focus & Return In GUIs

In my searching, I discovered that to make the cursor appear in an input box the moment the GUI opened, I needed to add the following parameter to the UISCENE:

OnAdd=UIScene_OnAdd_SetFocus(TextNameInput) where TextNameInput is the name of the UIText box requiring the input.

Then to make it so the Return key worked with this textbox, I needed to ensure the following two parameters were added to the same UIText box:

multiline="false" returnrestricted="true"

Once these two parameters were added, I found I could then add a simple OnReturn section to the same UIText like this:

OnReturn=UIObject_Misc_ExecuteServerScript("gui_textinput",local:0)

This OnReturn does exactly the same thing as if the player clicks on the button which has the same command line, but uses OnLeftClick instead of OnReturn.

The good news with all this is that it makes the game flow more intuitively. And there are also some GUI text input windows where this kind of input is almost essential due to time factors involved.

And so the module continues to be written ....