This thread shows my progress as I develop a set of scripts for persistent rental housing (inns/hotels etc...). I saw a few nice systems on the vault, but they weren't exactly what I wanted. To show my work in progress, I have pasted all of the scripts which are part of this project to pastebin. For the most recent code, you'll need to see the most recent posts. I want to track the evolution of the scripts, and thus leave the older posts unedited. (EDIT I broke this rule to activate syntax highlighting)
[edit - I've been working on this again and am nearing completion of all the needed features.
the updated code is v2_inc_housing]
Description of the parts:
- Persistency is set up to use NBDE(improved bioware database). But could likely be very quickly adjusted to use any DB system. I have but 2 or three database calls.
- "aa_rentroom" is the name of the conversation file. It is reusable for any inn, and has dynamic text at every owner's node and every player reponse. Custom tokens are used for everything the player reads.
The conversation "aa_rentroom" is defined by three nodes as follows:
- (1) show the room types available - up to 5 as defined by the builder. player selects one of the room types
- (2) show up to 3 duration options (1 night, 1 week, 1 month) for the room of the type selected by the player along with the cost associated with each duration. Display important info about the room such as how many occupants can fit, cost, services available (does it have a locked door? bath? continental breakfast? laundry?) etc....
- (3) display for the pc what room they got, and any of the specifics the innkeeper needs to explain (such as check out time, where the room is, how to request services if any, house rules etc...) And if one of the room's services is "private" then give to the player a room key and set it up to work with their room door.
- The most important script in the conversation file is "aa_rentroom_tok". This script is attached to every one of the "owners's" nodes in "Text appears when"
- Every "text appears when" slot for the player's responses has something like "aa_ck_token100" and an "action taken" script like "aa_conv_branch1". Each node has at most five of these kinds of responses. So there are 5 of each of these files as follows:
aa_ck_token100,aa_ck_token101, aa_ck_token102, aa_ck_token103, aa_ck_token104, aa_conv_branch1, aa_conv_branch2, aa_conv_branch3 aa_conv_branch4 aa_conv_branch5
-The script include for the system is "aa_inc_housing" and is called thus far by "aa_rentroom_tok". This contains all the working parts. I have not included my own master which has the utility scripts and the NBDE database system.
- I need one more script that handles garbage collection, and to place it in both the onconversation abort and finish slots. This will be a simple thing that deletes all temporary local variables set on both the PC and NPC dyuring the course of the conversation. I have not yet written it.
Objects required:
Perhaps the biggest drawback for the builder are the number of data objects, and local variables that this system requires. Its complicated enough that I may have to make some palette items (waypoints so that they can double as map points) prepopulated with local variables, and documentation of how the system works in the "comments" section. I hate to create items in teh palette and add objects to the module, but without these this system is hard to understand.
These objects include:
- one or more inn keepers with a conversation that is either composed entirely of "aa_rentroom" or launches that conversation on the innkeeper. Each innkeeper needs a local string that contains the tag of the "inn" waypoint. See below. I think it is better to only have one innkeeper, and to only allow one PC at a time to converse with the innkeeper. But perhaps someone can improve the system to elimnate the problem of one pc quickly renting a room that another PC was just about to rent. (This would break the conversation if it occurred).
- an "inn" waypoint with a tag unique to the inn. The inn is loaded with a ton of local variables. See the INN struct in "aa_inc_housing"
- Each room is created by placing a waypoint tagged with the inntag + the number of the room. A number of local vars further define the room see the function InitializeRooms() in aa_inc_housing for more information.
- A generic "room key" that is retagged, renamed and redescribed (SetDescription) by this system to work with the specific room door.
Keys:
A subsystem that I use alongside this but which is not strictly necessary is my key system (not to be confused with the old public transit system in Alameda County, CA). I have tag scripted keys that can unlock/lock doors that have a matching identifier. This enables all doors in an inn to be accessed by the innkeeper's master key, and yet room keys can open specific room doors. Its a very simple system that anyone can code. One more caveat - I rewrote my tag script activation so that they don't read the whole tag but only a subtag within the tag. GetTagPrefix() is used in that script. so a key could be tagged with key_innroom1 which would launch the do_key script instead of do_key_innroom1. And it functions as a key that looks for a local string on a door of "key_innroom1"
* * *
Issues I've already seen that need to be changed so that the code makes more sense and functions more naturally:
- In retrospect I wish I had named those token scripts 101-105, instead of 100-104 and may change that later.
- I should increase all of my indexes by 1, because my roomtype index starts at 0 instead of 1. That was a mistake, and creates a problem with the scripts.
- Also my use of the Struct is kludgey and clumsy, and can be improved, but I'm not sure how to stream line it yet. Perhaps by making a sub struct for roomtype. Can you put a struct inside of a struct?
* * *
I know this system is no big deal for the real programmers out there, but for the lesser skilled amongst us such as myself I think its good to look at each other's work, share ideas, and thus improve. Thats why I am posting this in progress. Feedback is welcome. Especially that which pushes me to structure my code more effectively and efficiently.
Modifié par henesua, 27 avril 2014 - 10:01 .
