Author Topic: Persistent Inn System - W.I.P. (Read 1429 times)

Legacy_Lightfoot8 · « **Reply #15 on:** January 07, 2012, 05:27:45 am »

From the little bit that I have looked at zz-dialog, I do not like it much. I guess O should not even say that since I have not looked into that deep yet. You my however be interested in Kato's thread.
On the road to a debugged dynamic convo system for Windows

How does one kick a PC out of a room that they are no longer paying for?
What happens if a PC keeps a key rather than returns it?
How does a PC request an extension of their stay?
How does a PC tell the innkeeper that other PCs will be sharing their room?

I have not looked at your system fully yet either, But here is how i would handle it.

To make sure that PC leave the key,  Hmm, Well since the did not pay with a credit card, You make them leave a deposit.   The deposit should be enough to cover the calling of a lock smith to change the lock and a little extra for the hassle.   The Key should also be returned before the lease on the room expires to get the deposit back.   Of cource if you have a reputation system in the module you could wave the deposit for VIP's.

Scripting wize I would handle it by never giving the same Key twice. If the tag of your door was say BarRoom1 the first key given to a renter would be. BarRoom1_K1 and the the Key needed to unlock to that on the door.   when the room is rented by another player increase the key number to 2.   once that is in place every thing else fall into place easer.

For kicking the player out. you simply change the Key number.
For extention of stay you increase the time Stamp for when there stay is up.
For shairing a room you let them request an extra Key. (All keys need to be returned or no refund of deposit)



I have head the sugestion for a HB script. I think that is a little over the top, even if you wanted to go that rout a pseduo HB that ran just once a day would do the trick, at the standard 11:00am check out time or so.   still not really needed.   The only time a PC could use the room is when they are in the area, an area OnEnter script to adjust the doors to the correct keys needed would do the trick.

Legacy_Lightfoot8 · « **Reply #16 on:** January 07, 2012, 05:59:08 am »

I guess I just feel like babeling some more.

In the System I see no need to have a time stamp that is any more acurate the per hour. say something like.

int StampGetCurentTime()
{
return GetTimeHour()
         +GetCalendarDay()*24
         +GetCalendarMonth()*672
         +GetCalendarYear() * 8064;
}

to adjust the time stamp to 11:00an on the current day would be a simple as:

nStamp = (StampGetCurentTime()/24) * 24 + 11;

Then just add 24 to it for how ever many days they rent the room for.    in the On AreaEnter you check the TimeStamp for any rooms that are rented vs the currentTime time stamp.   If current time is greater change the Key.

An even better question then the ones you have asked is: What happens to any items the PC happens to leave in the room.   The last time I had that conversation it was anything from selling them off a little at a time to extend the rent on the room.   To treating them more like a storage unit today. ( Not removing the ownership of the room right away, After X amount of time on the room not being paid for auctioning off the rooms contents in bulk. Selling then to the local pawn, Having the cleaning staff claim them( Placing them into there invemtories, with the posiablity of them selling them to PC's) to just wipping them from the server.

There really are a lot of things to think about once you start a project like this.

Legacy_henesua · « **Reply #17 on:** January 07, 2012, 02:04:09 pm »

You've given me much to think about, Lightfoot8. And I think many of your suggestions would work, but I do not think that every Inn or Apartment will handle it the same way. What this means is that the first challenge is creating a framework that all these methods can plug into.
The lock changing idea for example is very good. My system is not yet set up for that, but I can write a function that generates key tags AND adjusts the door's matching variable to match the key tag. The next thing I need is a means for the Innkeeper to know when a key is missing - key memory. With all of that in place, the Inn will be able to decide when to call a locksmith to change the locks.
But not every place is going to change the locks at the same time, or have the resources to do it every time the room changes. Its not like these are electronic keys. So my intention is to leave it up to the Inn to DECIDE to do so.
That is the trick.
From the big picture standpoint I need the following:

Tracking who is staying at the inn, and when their time is up: I have done this already with the rooms database
Detection of when "times up" at the Inn: Your time stamp is the right idea, and it works with the "checkout" variable I have allowed each inn to set. I'll think more about the OnEnter detection of this, BUT I think I need a time based stimulus rather than an OnEnter stimulus - otherwise it is possible for a PC to sit around in their room beyond checkout time and then leave without dealing with the consequences.
Response hook for "times up": After some thought I think the best way to handle this is to have a "times up" function that decides between default behavior, and custom script. If the string identifier for a custom script is missing, default behavior happens.
Memory: The Inn needs to remember who their customers have been over time so that the inn can track debts, damages, or other special circumstances. This was the idea behind my "Patrons" database which is currently commented out since I am not sure how to set up the data string yet, and whether I want to key this data specifically to the PC object. The problem with keying to the PC object is that the Bioware database doesn't seem to be able to handle that when the PC is offline - and so that is why I have a long "Patrons" string keyed to the Inn.

And again my thinking is that I want each Inn to be able to respond in their own unique way. The "aa_inc_housing" script will contain the functions that can be used to respond to various situations, but the builder and DM should be able to decide what an inns actual response is in a given situation. i haven' mentioned DMs yet, but I think they need an Inn tool to interact with this system too.

Will I code all of this? Probably not down to every detail. I only need to get a basic framework in place so that I can add to it later, and move on other aspects of my module in the meantime. The bullet points above are my target right now. But they will be coded as a framework which custom repsonses can be plugged into.

Legacy_henesua · « **Reply #18 on:** January 07, 2012, 05:31:12 pm »

               Adjusted my time functions to work with this system, (and also needed to adjust time functions throughout my module that can take advantage of the change).

Now I can specifiy whether I want to return the Game Second, Minute, Hour or Day (relative to the campaign's starting time) in the GetCurrentGameTime function.

Both game hour and game day appear that they will be useful for the inn system. I will be including my time functions for this system when posting to the vault. Here they are:

aa_inc_time

I'll strip out extraneous functions when the time comes.

                     ModifiÃ© par henesua, 07 janvier 2012 - 05:40 .

Legacy_Rolo Kipp · « **Reply #19 on:** January 07, 2012, 06:08:07 pm »

<rifling through...>

A couple thoughts that are probably irrelevant and certainly irreverent:

First, Why check *anything* at checkout time? Would a real clerk go pounding on all the delinquent doors at exactly 11:01am? I'm not a fan of HB :-P
Heh, The time stamp is good to know when the rental window is closed, but just use a simple compare when a) they try to unlock the door, 'B)'

the maid (if the inn is classy enough) goes to clean the room or c) you need to find an available room to rent. Imagine the PCs surprise (if they attempt to squat in the room as you outlined above) when Palemaster Zog the Unforgiving unlocks his newly rented room and his 12 13 Doom Entourage start piling into the room... ;-)

The Patrons db is a good idea, as I think *anything* that keeps PCs in NPCs memory is a good idea in general. But signing the register doesn't mean *only* those patrons have keys... and if you use the incremental key idea *and* if some of the inns are a bit laggardly (perhaps even on *purpose*), there's the possibility of unauthorized people gaining access to the key, and the room.

One of the moments in A Dance With Rogues that bumped a "friend's" involvement meter was returning to *her* apartment to find a burglar... She was instantly outraged and slaughtered the fool. It was a minor thing and a very short encounter, but it made her feel quite possessive.

Imagine if the inn in question was questionable (a fact the PCs *should* have discovered from talk in the tavern, but ignored) and they regularly burgled or set upon patrons... We have all heard the phrase "disreputable" before. Wouldn't it be neat if it *meant* something? And "Shanghai-ing" could be a perfect hook for an adventure.

For what it's worth, I'm quite enjoying your thread :-)
Um, do you carry your house key in the left pouch or the right...?

<...Henesua's pouches>

                     ModifiÃ© par Rolo Kipp, 07 janvier 2012 - 06:16 .

Legacy_henesua · « **Reply #20 on:** January 07, 2012, 06:51:44 pm »

Rolo Kipp wrote...
First, Why check *anything* at checkout time? Would a real clerk go pounding on all the delinquent doors at exactly 11:01am? I'm not a fan of HB :-P

Not necessarily. It depends on the Inn. Hence my post above about making this system a framework that other builders can plug into. So the system enables a custom script call on checkout time, but if nothing is set, only default scripts will run. What those default scripts do... is the real question. I have not decided yet but I'll most likely leave a variable that will enable a builder to TURN OFF the default responses. Default responses however are good for those that just want an inn to work without digging in and customizing stuff.

Rolo Kipp wrote...
Heh, The time stamp is good to know when the rental window is closed, but just use a simple compare when a) they try to unlock the door, the maid (if the inn is classy enough) goes to clean the room or c) you need to find an available room to rent. Imagine the PCs surprise (if they attempt to squat in the room as you outlined above) when Palemaster Zog the Unforgiving unlocks his newly rented room and his 12 13 Doom Entourage start piling into the room... ;-)

I agree that all of that works. But I think it depends upon the Inn. For example: a "house of ill repute" would probably have the enforcer come around at a particular time to extract money out of the patron before kicking them to the street. So I want to enable each Inn to respond in different ways within the framework.

Rolo Kipp wrote...
The Patrons db is a good idea, as I think *anything* that keeps PCs in NPCs memory is a good idea in general. But signing the register doesn't mean *only* those patrons have keys... and if you use the incremental key idea *and* if some of the inns are a bit laggardly (perhaps even on *purpose*), there's the possibility of unauthorized people gaining access to the key, and the room.

Of course. I still have not worked out exactly how to determine the WHEN or IF of lock changing. Working on that now. I think part of this is tracking who has the room key in the ROOMS DB, and providing the ability for an inn keeper to be "forgetful".

Rolo Kipp wrote...
Imagine if the inn in question was questionable (a fact the PCs *should* have discovered from talk in the tavern, but ignored) and they regularly burgled or set upon patrons... We have all heard the phrase "disreputable" before. Wouldn't it be neat if it *meant* something? And "Shanghai-ing" could be a perfect hook for an adventure.

I definitely want the system to work with these options. And I think the "key" to that is to provide hooks that DMs and Builders can latch onto.

But this can get ridiculously complicated. I need to wrap up version one of this soon and get back to building my module. At this point its all going to be about planning ahead, and providing paths for future development. I just need the base functionality for the Inn I am currently building, and then tie this one off for later work.

Legacy_henesua · « **Reply #21 on:** January 08, 2012, 11:38:04 pm »

One of the issues related to changing the key tag on these rental doors is that I have to ensure that the doors are always updated to the latest key tag. Especially after a server boots.

So I created a function which will intialize all of an inn's rental room doors. At present this function merely adds a local string to each door of each room which matches the rental key for the room.

void InitializeDoors(string sInnTag)
{
  object oRoom, oDoor;
  int nIt, nRoom;
  string sRoomKey;

  nRoom   = 1;
  oRoom   = GetRoom(sInnTag, nRoom);
  while(GetIsObjectValid(oRoom))
  {
    sRoomKey    = GetRentalKey(sInnTag, nRoom);
    nIt   = 0;
    oDoor = GetRoomDoor(oRoom, nIt);
    do
    {
      SetLocalString(oDoor, ROOM_KEY, sRoomKey);
      oDoor = GetRoomDoor(oRoom, ++nIt);
    } while(GetIsObjectValid(oDoor));

    oRoom   = GetRoom(sInnTag, ++nRoom);
  }
}

GetRentalKey - returns the key tag from the inn's room database
GetRoomDoor - iterates through the doors associated with a room

The question I have is how do{}while will work for me here. Does it evaluate itself after executing all of the code inside the curly brackets?

The reason why I ask is that it is possible that Door 0 does not exist. And if it doesn't there are either no locked doors (and thus no key) or there are multiple doors (the situation I want to catch). This enables Rental Rooms to have a pair of doors which transition between areas or other combinations of doors, and all will respond to the same room key. So to wrap up I don't want the loop to cease if Door 0 is invalid. I want it to also look for Door 1.

So will this do{}while work the way I want it to? This is the first time I have found a use for do..while that is more graceful than using while would have been - so I'm uncertain that I am on the right track.

                     ModifiÃ© par henesua, 09 janvier 2012 - 12:03 .

Legacy_Lightfoot8 · « **Reply #22 on:** January 09, 2012, 12:55:19 am »

               Yes, that would work as you expect, I however do not like it.   The reason is that you are still trying to set the local int on the nonexistant door 0, When it does not exist.   I think this would be better.

void InitializeDoors(string sInnTag)
{
object oRoom, oDoor;
int nIt, nRoom;
string sRoomKey;

nRoom   = 1;
oRoom   = GetRoom(sInnTag, nRoom);
while(GetIsObjectValid(oRoom))
{
    sRoomKey    = GetRentalKey(sInnTag, nRoom);
    nIt   = 0;
    oDoor = GetRoomDoor(oRoom, nIt);
    if (!GetIsObjectValid(oDoor)) oDoor = GetRoomDoor(oRoom, ++nIt);
    while(GetIsObjectValid(oDoor))
    {
      SetLocalString(oDoor, ROOM_KEY, sRoomKey);
      oDoor = GetRoomDoor(oRoom, ++nIt);
    }

    oRoom   = GetRoom(sInnTag, ++nRoom);
}
}

The question I have is why are you setting the local on the door?
would not
SetLockKeyTag(oDoor, sRoomKey);
work better?

Legacy_henesua · « **Reply #23 on:** January 09, 2012, 02:07:08 am »

               ah, nicely done. I should have thought of that. Thank you.

And to answer your question:
all of the doors are opened by a master inn key which is what I have set in the LockKeyTag field. I did this so that NPCs (carrying the master inn key) can enter any room in the Inn.
That left the need to also enable specific keys to only open a single room.door in the inn. A door script checks for a match between the local string "KEY" and the tag of the door, and if there is a match the door (if locked) is unlocked

Legacy_henesua · « **Reply #24 on:** January 10, 2012, 05:23:20 am »

                I've come across a bug.

In the Inn Room database I have stored PCs as a combination of player name and character name, yet I am using data delimiters that could be entered by a player when typing in their name.

The delimiters I am currently using:
* . _ :

So I hope that there are some other string characters that I can use as delimiters which a player will not be able to enter into their name fields. I am considering using unusual characters like:
Â© ` â€¡ â€  Â¤ Â§

Are any of these enterable by a player? I tried with my keyboard but was unable to find the keystrokes that would create them.

Legacy_Lightfoot8 · « **Reply #25 on:** January 10, 2012, 06:09:32 am »

               Â§ is Shift+RightAlt+s
Â¤ is RightAlt+4
Â© is RightAlt+c

On the Us international key board layout.

I can not get the +/- here because my web broser is currently taking it as a back command.

oh â€¡ is Hold-Alt 0135 on the us english keyboard layout
I for got to have the num lock on for the +/-

Â± is hold-alt 0177 on us english keyboard.

and all of this has been typed from the keyboard.

refferances.
http://tlt.its.psu.e...ts/codealt.html
http://tlt.its.psu.e...ts/codeint.html
http://tlt.its.psu.e...ts/fullint.html

Legacy_henesua · « **Reply #26 on:** January 10, 2012, 06:32:10 am »

               Damn... so no way around it. Hmmm. I suppose I'll have to check character names and swap in substitutions or boot players that use these weird characters.

Legacy_Lightfoot8 · « **Reply #27 on:** January 10, 2012, 06:37:55 am »

               Well the text in NWN that can be displayed is limited, if the entered on of the characters above into there name,, It would not display properly, so I dout they would use one. It would show up ingame as one of the boxes most likely.

Legacy_henesua · « **Reply #28 on:** January 10, 2012, 06:47:15 am »

               Unlikely by normal players, but possible for a griefer to take advantage of. I'd rather not give them the opportunity.

Legacy_henesua · « **Reply #29 on:** January 10, 2012, 09:36:20 am »

               I have made many changes to the core functions to this system. The updated file is on pastebin:
aa_inc_housing

The discussion above since the previous update exposed for me a number of essential changes that I needed to make. Almost every function has seen at least minor changes. A number have seen significant change, some were renamed in the process, and some new functions were created. Some highlights to look at are the following functions:

InitializeDoors
GetAvailableRoomByType
GetRoomDoor
GetRentalKey
AddRoomOccupant
RemoveRoomOccupant

There is a logical error still in InitRoomtypeAvailability
rather than searching for occupants in the room to determine whether the room is occupied, it is looking at the time the occupants are expected to checkout. This is problematic and needs to be changed. I have already aswitched the check from ROOM_EXIT to ROOM_OCCUPANTS in GetAvailable RoomByType

By looking at room occupants rather than when present occupants check out, the inn keeper can place PCs in a common room until it is "full", AND the inn keeper won't rent out rooms where the present occupants might want to extend their stay. It is possible for someone to request a room before checkout time, so this prevents that from happening until the present occupants checkout. This also enables better handling of delinquent room payments and rekeying of locks.

Anyway... lots was changed here, and the stage was set for putting other aspects of the system in place.

[Edit]
Noticed lots more to clean up and improve ont he bus to work. Made more changes to how the room string is parsed into subchunks and then how the subchunks are processed. This should reduce the amount of code int eh include, but increase the number of function calls.

Question:
Is it problematic in terms of efficiency to have many function calls? Or is it worth it if you have less lines of code in your include?
My goal is to cut down on repetitive code so it is easier to manage, but I don't want to reduce efficiency at run time.

Bioware Archive

News:

Author Topic: Persistent Inn System - W.I.P. (Read 1429 times)

Legacy_Lightfoot8

Persistent Inn System - W.I.P.

Legacy_Lightfoot8

Persistent Inn System - W.I.P.

Legacy_henesua

Persistent Inn System - W.I.P.

Legacy_henesua

Persistent Inn System - W.I.P.

Legacy_Rolo Kipp

Persistent Inn System - W.I.P.

Legacy_henesua

Persistent Inn System - W.I.P.

Legacy_henesua

Persistent Inn System - W.I.P.

Legacy_Lightfoot8

Persistent Inn System - W.I.P.

Legacy_henesua

Persistent Inn System - W.I.P.

Legacy_henesua

Persistent Inn System - W.I.P.

Legacy_Lightfoot8

Persistent Inn System - W.I.P.

Legacy_henesua

Persistent Inn System - W.I.P.

Legacy_Lightfoot8

Persistent Inn System - W.I.P.

Legacy_henesua

Persistent Inn System - W.I.P.

Legacy_henesua

Persistent Inn System - W.I.P.