|
|
 Accueil  Forums Archives Forum Pre-Release NWN Archives Archives - Beta Toolset General Wacky idea with books and scrolls
Archives - Beta Toolset General
Amurayi
Game Owner
 NWN
NWN: SoU
NWN: HotU
Lié: 10 jun 2002
De: Wiesbaden, Germany |
 Posté: samedi, 15 juin 2002 12:04 |
Couldn't you use staff with charges as variables holders?
If you can keep the player fromusing the staff and scripts could alter the charges then this could work, no?
_________________
Amurayi
_____________________
Our mods and a collection of nice scripts: http://www.lemonbutter.com | 
|
Shadowspawned
Game Owner
 NWN
NWN: SoU
NWN: HotU
Lié: 10 jun 2002
De: Sophia, NC - USA |
Posté: samedi, 15 juin 2002 12:08 |
Price on that - Yea everything you own for the rest of your life  Ain't love grand. I am going on 13 years with a ring through my nose.
As for Blinders no. If I had blinders on I world say you are doomed to fail. But you won't fail, it may not be 100% correct, but such is life.
Most of the games people talk about on here I have never played. My time will not permit such usage. The last three games I bought were POR-RMD, Civ III, and this one. Sort of down on the first one, love the second, and we will see about the third.
Me I will lose lots of sleep just to create a module that the my kids & friends can play because that is the only time I have left to give up.
Later, time to put the kids to bed.
_________________
10 Lvl Ranger
Just going into the Neverwinter Woods.
K7-800mhz
700+ meg memory
GS790 Viewsonic 19"
64meg evga-e-GeForce2 MX Video Card
Creative AWE64 soundcard
Win XP | |
|
Trulain
Game Owner
 NWN
NWN: SoU
NWN: HotU
Lié: 11 jun 2002
De: North York, Ontario |
Posté: dimanche, 16 juin 2002 01:37 |
Very interesting thread… I’m not sure I understood 100% of the technical stuff as I’m not really a programmer but an idea did form in my head as I pushed through all the great ideas people have posted. My idea builds upon the widely accepted premise (from what I’ve read in this thread) that until the good folks at BioWare design a robust solution to this problem, items will in fact be necessary to communicate information between modules. My idea addresses the efficiency with which items can communicate information and I hope provides a fairly intuitive model for building and maintaining a consistent system for implementing this across a multi-DM, multi-server setting.
Before I launch into the idea, let me reiterate that I’m not a programmer and since I’m not positive that I fully understand what information needs to be communicated, this solution may not be viable. I hope that my intuition is on the mark and that this idea can be evolved into a solid solution, but if not maybe it’ll at least spark some ideas in those of you with a stronger technical understanding of the problem at hand. Also, forgive my potential bastardization of terms like class, instance, and state in the paragraphs to follow – I’m using them in a general sense rather than as programming terms.
If I understand the token system idea and “bitfields” correctly, the main problem is that as the amount of custom information that you want to communicate across modules/servers increases, the number of required tokens quickly multiplies and becomes unwieldy. As worlds become larger and more customized, the lack of scalability of bitfields becomes evident. Here’s how I picture the information that needs to be passed:
A world will have set of custom CLASSES of information to be communicated between modules/servers (e.g. Prestige Classes, New Spells, Info on Quests, etc…) and each of these classes will have a number of INSTANCES (e.g. a variety of prestige classes, specific spells, and specific “multi-module” quests). Finally, each of these instances will have a number of STATES (e.g. the PC has a certain spell memorized twice, part II of the quest has been completed). The number of tokens needed to map the ever-growing number of possible combinations would be ludicrous.
Ok, enough preamble, here’s my idea: use a *single* item (tucked safely away in that awesome perma-locked container idea) as a “token” to communicate all of this information. I’m not suggesting embedding the information in the TAG or any of the text fields, as I’ve read that there are problems with this approach. Instead, my idea is to embed the information in the physical attributes of the item: the pieces, models, and colors that define the item’s appearance. When any of the custom information for that character changes, the item/token is automatically “trashed” and replaced with new copy of the item/token that incorporates the new information. Here’s a simple example using a dagger to clarify what I mean:
The following describes the possibilities for the look of a dagger, as it appears in Aurora beta:
Pieces: TOP, MIDDLE, BOTTOM
Model Types: 6 for TOP, 6 for MIDDLE, 6 for BOTTOM Colors Available: 3 for TOP, 3 for MIDDLE, 3 for BOTTOM
This dagger has 104,976 possible variations [(6x3)^3] to its physical appearance. This allows for the 104,976 “state sets” to be communicated, where a state set is a complete enumeration of that character’s current status for *all* the custom information that exists in that world. Even though you can create an item with an ungodly number of possible physical appearances (the half plate that comes with the beta for example has 666,899,365,418,237,952,000 possible model/color/gender combinations – now *that’s* storage capacity!), this approach only partially solves the scalability problem because the number of possible state sets can become staggering as the world becomes more customized and the lookup table administrators would kill themselves after coding the first several million state sets.
So how do you reduce the number of entries in look-up tables? Maybe breaking the information into a set of look-up tables would help… The idea I thought of involves thinking of the token as being analogous to a header frame and to use the PIECES of the item to define the structure of the frame. Hope I’m not bastardizing another word here or confusing anyone. Here’s what I mean, using the class-instance-state hierarchy outlined above and sticking with the dagger example:
CLASS information can be embedded in the configuration of the TOP piece of the dagger:
When the PC moves to a new module, this part of the token says “I have custom information you need to know about in the following subjects: Custom Spells and Quest Information.” Based upon this, the server knows which lookup table(s) to refer to. For our dagger example, its top piece has 6 models and 3 colors, allowing for 18 classes or combinations of classes.
INSTANCE information can be embedded in the configuration of the MIDDLE piece of the dagger:
As the class-level part of the token has told the server to refer to one or more “class tables”, the next thing it needs to be told is what entry or entries on that table it should refer to. Following the example above, the instance part of the token says “I have the following Custom Spells: Flesh to Oatmeal and Polymorph Self:Molten Bunny. I also have information you need to know I have concerning The Uber Item Quest.” Based on this, the server knows to access the Flesh to Oatmeal, Polymorph Self:Molten Bunny, and Uber Item Quest reference pages. It might make sense for the instance part of the token for be made up of a number of item pieces, with one piece per class. This way, the class part of the token basically just tells the server which instance parts of the token to pay attention to – food for thought.
STATE information can be embedded in the configuration of the BOTTOM piece of the dagger:
As the instance-level part of the token has told the server what look-up table entries to access, it now needs to update its records to reflect the current status of each instance for that player. Finishing off the example above, the state part of the token says “I currently have Polymorph Self:Molten Bunny memorized twice. Also, I do not have Flesh to Oatmeal memorized at all. Also, I have completed parts I and II of the Uber Item Quest but have not finished part III.” It might be necessary for the state part of the token to consist of multiple item pieces, one for each “instance” or look-up table entry that the player’s token refers to. This might cause scalability problems if you have highly customized characters or if that player is in the middle of a lot of multi-module quests. (Does anyone know how many pieces an item can have?) Maybe someone can think of a way around this… Perhaps by adding another layer or two to the model by through some mathematical transformation – something to dwell on…
In any case, that’s an overview of the model. I think it gives the server everything it needs to know to run the scripts to accommodate a PC with custom information. If the idea - or wherever the idea may evolve to – works, it still isn’t a complete solution. It just provides a scaleable *framework* for passing custom information between modules. On top of this framework, I would think you’d also need:
1) to define a protocol for mapping the token information to the look-up tables (obviously this is closely tied to the final design of the model I just talked about, in terms of number of layers, and pieces, models, and colors)
2) have probably one person per world who’s responsible for maintaining the custom tables… Maybe one person per class would work but the more fingers in this pie, the more problems that will likely develop…
3) a set of policies for implementing new content into your world, that all DM’s have to follow. Things like, “new global custom scripts will be introduced once a month” and “DMs are responsible for ensuring that custom scripts have been propagated and for verifying that look-up tables have been updated before giving players access to new custom features”. These are not well thought out examples, but the point is that some controls will need to be put in place to ensure that the system doesn’t get buggered up. It would be no fun to go to cast my new Polymorph Self:Molten Bunny spell, only to find the look-up table hadn’t been updated and have Flesh to Oatmeal to go off in its place! (“what the….mmmmmm, I’m lumpy.”)
Well, I’d better stop typing before this turns into a novel. I’m sure the idea can be improved upon but I thought it best to get everyone’s input and your thoughts on its feasibility before working about improvements. No sense in spending more time in it if there’s a fatal flaw… If nothing else, maybe it'll spark a better idea from someone...
Trulain
[ Edited By Trulain: Sunday, 16 June 01:40AM (GMT) ] | |
|
Phyrndyl
Game Owner
 NWN
NWN: HotU
Lié: 01 jun 2002 |
Posté: dimanche, 16 juin 2002 03:51 |
Well, I like the idea of it but I'm not sure any of that information can be read from the item (the dagger in your example.) For example, I see no reason (although I may have missed this, obviously) that Bioware would have scripted easy access to say--the color of the hilt.
The reason I had suggested using a tag ("StateBook_7a3") was that we know we can access the tags. Do a search for all possible "StateBook_XXX" and when you've found one, you've got the state. How one generates that state from disparate component parts is obviously quite flexible, but it is a relatively unlimited number of states that can be passed this way using alphanumeric codes and as many of the Tag string places as necessary.
_________________
Phyrndyl
Phyrndyl@msn.com | |
|
Trulain
Game Owner
NWN
NWN: SoU
NWN: HotU
Lié: 11 jun 2002
De: North York, Ontario |
Posté: dimanche, 16 juin 2002 03:18 |
I just figured that you'd have access to those variables through a "page" which contains information for all of the properties of that instance of the sword. Besides, I thought I read somewhere that BioWare was giving people access to pretty much all the code... Does anyone know for sure whether or not it's possible to access the information in order for the single item token idea to work?
I think the TAG idea is great but I thought I'd read somewhere in the depths of this thread that there was a problem with doing that. Hopsefully I'm mistaken and it will do the trick!
Tru | |
|
Phyrndyl
Game Owner
NWN
NWN: HotU
Lié: 01 jun 2002 |
Posté: lundi, 17 juin 2002 03:56 |
Yes, we'll have access to the code...but not from WITHIN the game. What we need here is something the module can read. A GM could go in and look at it, but we want something that will work automatically without intervention.
_________________
Phyrndyl
Phyrndyl@msn.com | |
|
drako_wolfheart
Game Owner
 NWN
NWN: SoU
NWN: HotU
NWN 2
Lié: 14 mai 2002 |
Posté: lundi, 17 juin 2002 01:30 |
Quote: Posted 06/16/02 01:37:19 (GMT) by Trulain
My idea builds upon the widely accepted premise (from what I’ve read in this thread) that until the good folks at BioWare design a robust solution to this problem, items will in fact be necessary to communicate information between modules. My idea addresses the efficiency with which items can communicate information and I hope provides a fairly intuitive model for building and maintaining a consistent system for implementing this across a multi-DM, multi-server setting.
"consistent system for implementing (data transferal) across a multi-DM, multi-server setting"
That is a very good description of the problem and the needed functionality.
[ Edited By drako_wolfheart: Monday, 17 June 01:30PM (GMT) ]
[ Edited By drako_wolfheart: Monday, 17 June 01:31PM (GMT) ]
[ Edited By drako_wolfheart: Monday, 17 June 01:31PM (GMT) ]
_________________
- City of Tanjee PW ( Click Here )
- PennaTavern Prefab World ( Click Here )
- PWUM Persistence System | |
|
Master Aradorn
Game Owner
NWN
Lié: 16 jun 2002 |
Posté: lundi, 17 juin 2002 01:52 |
Some suggestions:
While I like the book idea, it might not be necessary. I dont have the player client yet, but I believe it has some sort of Player Journal that you might be able to make additions to.
Again, i'm not certain, but I believe you will be able to make up 'custom' factions. If so, you could make a faction for each of the quests, and give it to the player when it is completed.
If your 'elemental' example above is actually something you are trying to do, another way you could do it is the more traditional way: at quests end, give the PC a token item, like 'Gem of Fire', 'Gem of Air' etc. and when they have all 4, script in some nice visual candy and take the gems away, giving back the 'Gem of the Elements' or whatever as proof that all of the quests have been completed.
-Master Aradorn | |
|
Trulain
Game Owner
NWN
NWN: SoU
NWN: HotU
Lié: 11 jun 2002
De: North York, Ontario |
Posté: lundi, 17 juin 2002 02:43 |
Quote: Posted 06/17/02 03:56:42 (GMT) by Phyrndyl
Yes, we'll have access to the code...but not from WITHIN the game. What we need here is something the module can read. A GM could go in and look at it, but we want something that will work automatically without intervention.
The module can't read item properties? It not, bummer. If so, then there's hope for my idea.
Tru | |
|
drako_wolfheart
Game Owner
NWN
NWN: SoU
NWN: HotU
NWN 2
Lié: 14 mai 2002 |
Posté: lundi, 17 juin 2002 07:14 |
Quote: Posted 06/17/02 14:43:33 (GMT) by Trulain Quote: Posted 06/17/02 03:56:42 (GMT) by Phyrndyl
Yes, we'll have access to the code...but not from WITHIN the game. What we need here is something the module can read. A GM could go in and look at it, but we want something that will work automatically without intervention.
The module can't read item properties? It not, bummer. If so, then there's hope for my idea. Tru
It is also my understanding that there is no functionality in the scripting language to pull properties from items (to be calculated on and what not). I may be wrong about this, however, so if someone knows otherwise, feel free to correct me.
-------------
Also, for those of you who haven't been able to read this thread in its entirity (which is becoming large), below is the 'primary' work-around that will be used to transfer data from one module that is linked to another.
When a PC comes to a portal to another server (standard area transition, such as a portal placeable object) all variables that are going to be transferred get converted into tokens. The character is then transferred to the linked module. Upon entrance into the new module, these tokens are automatically converted back into usable variables. BOOM. We transferred data from noe module to another (although it is specific to the player, not the world). As you can see, this can and will be alot of work for those who want to transfer large amounts of data. Any comments or suggestions are welcome.
[ Edited By drako_wolfheart: Monday, 17 June 07:17PM (GMT) ]
_________________
- City of Tanjee PW ( Click Here )
- PennaTavern Prefab World ( Click Here )
- PWUM Persistence System | |
|
Trulain
Game Owner
NWN
NWN: SoU
NWN: HotU
Lié: 11 jun 2002
De: North York, Ontario |
Posté: lundi, 17 juin 2002 10:33 |
Quote: Posted 06/17/02 19:14:31 (GMT) by drako_wolfheart
When a PC comes to a portal to another server (standard area transition, such as a portal placeable object) all variables that are going to be transferred get converted into tokens. The character is then transferred to the linked module. Upon entrance into the new module, these tokens are automatically converted back into usable variables. BOOM. We transferred data from noe module to another (although it is specific to the player, not the world). As you can see, this can and will be alot of work for those who want to transfer large amounts of data. Any comments or suggestions are welcome.
[ Edited By drako_wolfheart: Monday, 17 June 07:17PM (GMT) ]
Sounds good! How do you ensure that someone doesn't have items that can be misinterpretted as tokens? By using a special token or container that can't be found anywhere in the world?
Tru | |
|
drako_wolfheart
Game Owner
NWN
NWN: SoU
NWN: HotU
NWN 2
Lié: 14 mai 2002 |
Posté: mardi, 18 juin 2002 01:00 |
Quote: Posted 06/17/02 22:33:22 (GMT) by Trulain
Sounds good! How do you ensure that someone doesn't have items that can be misinterpretted as tokens? By using a special token or container that can't be found anywhere in the world?
Tru
The tokens would not be found anywhere else in the modules except for the outbound portal. THey would be destroyed upon entrance to the next world. As for the container, I'm not sure if we will need them. It depends on the size of a PCs inventory which would limit the number of tokens slots available. A large world would need to have some sort of container to transfer the tokens as they have alot of info to pass around.
And for worlds with multiple builders/DMs, there would need to be very good communication, which may be difficult.
(btw, congratz to ZipNAb)
[ Edited By drako_wolfheart: Tuesday, 18 June 01:11AM (GMT) ]
_________________
- City of Tanjee PW ( Click Here )
- PennaTavern Prefab World ( Click Here )
- PWUM Persistence System | |
|
Phyrndyl
Game Owner
NWN
NWN: HotU
Lié: 01 jun 2002 |
Posté: mardi, 18 juin 2002 01:05 |
<hisses at ZipNaB>
Who knew? Israel. Geez.
Seriously, it was nice to see somebody be first who seemed to appreciate it.
_________________
Phyrndyl
Phyrndyl@msn.com | |
|
drako_wolfheart
Game Owner
NWN
NWN: SoU
NWN: HotU
NWN 2
Lié: 14 mai 2002 |
Posté: mardi, 18 juin 2002 01:59 |
----------------------
-********************-
-* *-
-* NWN HAS ARRIVED! *-
-* *-
-********************-
----------------------
Now we shall answer our own "Can we do this?" questions, bwa ha ha ha ha 
_________________
- City of Tanjee PW ( Click Here )
- PennaTavern Prefab World ( Click Here )
- PWUM Persistence System | |
|
|
| Go to Page ( 1 , 2 , 3 , 4 , 5 , 6 , 7 , 8 ) |
Recherche dans les forums |
FAQ des forums |
Archives Forum
|
