I was doing some detective work today and I think I found the oldest (public) post on the boards. Whoaaaa!

I think it's worth mentioning the PS boards are older than this but they were hosted somewhere else before. So this is the rebirth I'd say. January 4th, 2002

Sometimes the solutions given to a petition are done when the player is not online, which is perfectly acceptable if he/she doesn't need to be there.

But sometimes things don't go as planned and the player may have additional information pertaining to the petition, so I would like to request the ability for reopening as long as it has not been deleted from his petition list.

PS is a pretty capable engine right now. It still has a long way to go before being considered a finished project, but I for one like the current supported features and integration with Crystalspace.

Now, considering that some folks may like to give it a shot and create a game based on PS engine, they also need documentation about a lot of things. There are plenty of resources scattered all over the forum, I know I've tried to herd a few and put them in one place but it's nowhere near perfect.

So, what am I suggesting?

Creating a new section in the PS wiki where players, testers, devs alike can ask questions and share knowledge. When I saw ask questions, I don't mean that as a discussion forum, this is what this one right here is for. I mean more on the topic, like a to the point Q&A.

Assuming someone comes upon this game engine and wants to use it, he'll learn from the PS license what is allowed or not.
Next, they will build the server and add content with server console, or in the DB itself.

But there are a lot, and when I say a lot I mean A LOT of things undocumented. I understand that is wasn't the case because of secrecy or any other conspiracy theory, just that it was hard to do and keep up to date. But the wiki is specifically built for one such purpose and even it the information gets outdated, sooner or later, someone will be able to update.


Examples or things that may be unclear to a lot of folks:

Quest script syntax
Specifying game rules

I know most of this stuff can be deduced from the code and the DB, but not everything. And even so, it's a very difficult things to do. I for one feel the need to learn more about how everything works, and I really do appreciate the efforts put in by the devs in  the PS Devcast but that's just a  snapshot in time, not a living document. And for very good reasons, it has to be generic as well.

Comments, opinions?

Having gone hunting a lot lately, I also happened to get whacked a lot, which in turn made me get Dakkru's curse one too many times. However, I do believe the punishment is fair so this is not a complaint against that but rather an implementation decision criticism.

I disagree with the fact that Health, Stamina, Mana,  Mental Stamina and Dakkru's curse time should be saved on logoff and resumed after login, no matter when that happens. Let me explain...

If you get hit by a monster, or get very tired during a long run, then logoff and return the next day to play (in realtime), you will resume with the same low health or the same low fatigue. If you happen to have Dakkru's curse, it will also be resumed. But in game time does not stop... so in fact after 24 hrs I should be healed, and I should not have the curse anymore either. It just doesn't make sense.

In case you didn't know, this can be generated with the help of psdoxyconf file from the docs directory in the cvs. Basically it provides a tree of the planeshift code, easy to read & navigate. In the following I will post a coversation with Bereror (Enar) who provided his additions/tweaks to the psdoxyconf file and helped me generate one for myself. Thanks Enar!

If you're on linux, just use your favorite package manager and install the doxygen package and its dependencies (if any.)

And...

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

I'd like to generate the API documentation with doxygen like you did but I can't seem to "tune" it correctly. Could you please tell me (if you got the time) in a 1-2-3 sequence what to change and where to run the command so that I get a result like your page?

You modify the psdoxyconf file in the docs directory. There seems to be not too many differences between the one that I used and the one from the CVS repository:
119c119
< STRIP_FROM_PATH        =
---
> STRIP_FROM_PATH        = /home/enar/ps/planeshift/
177c177
< TAB_SIZE               = 8
---
> TAB_SIZE               = 4
571c571
< COLS_IN_ALPHA_INDEX    = 5
---
> COLS_IN_ALPHA_INDEX    = 3
578c578
< IGNORE_PREFIX          =
---
> IGNORE_PREFIX          = ps paws
605c605
< HTML_HEADER            = psdoxyheader.html
---
> HTML_HEADER            =
684c684
< GENERATE_TREEVIEW      = NO
---
> GENERATE_TREEVIEW      = YES
1167c1167
< SEARCHENGINE           = NO
---
> SEARCHENGINE           = YES

I guess you know that Doxygen online help is available here.

STRIP_FROM_PATH removes parts of the path from linked source files so that they don't show up in the documentation.

TAB_SIZE, well, sets the tab size

COLS_IN_ALPHA_INDEX specifies the number of columns on the index page. 5 seems to be working better than the original 3.

IGNORE_PREFIX ignores ps and paws when adding classes to the index. This way psItem is shown under "I" and not "P". It probably makes sense to add "gem" and "gui" to that list of prefixes too.

HTML_HEADER specifies an HTML file for the header. I removed the header completely.

GENERATE_TREE_VIEW generates the tree view on the left side.

SEARCHENGINE adds the search box (warning, it will consume quite a lot of CPU time on the server if you have many people using it).


To run the doxygen command, just go to the docs directory and run
doxygen psdoxyconf
I hope this helps.

Regards,
Enar (Bereror)

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

Here's what I had in mind.

As it stands right now, from what I know, there's a lot of caching involved. Changing data on the fly is simply not possible. For example, if one changes data related to NPC's or quests etc., the changes do not apply until a server restart. Of course, this is not desirable at all sometimes.

However, I can see something in the server code which states that through some server console commands some data might be reloaded.

   15464 -- NPC commands        ------------------------------------------------.
   15464 exportdialogs  Loads NPC dialogs from the DB and stores them in a XML file.
   15464 exportnpc      Loads NPC data from the DB and stores it in a XML file.
   15464 importdialogs  Loads NPC dialogs from a XML file or a directory and inserts them into the DB.
   15464 importnpc      Loads NPC data from a XML file or a directory and inserts it into the DB.
   15464 loadnpc                Loads/Reloads an NPC from the DB into the world.
   15464 loadquest      Loads/Reloads a quest from the DB into the world.

So, I am not sure whether these are broken or I haven't managed to use them yet, but is it possible to do some things like that via scripting?

Supposing I would survey some custom logs, for the sake of the example -  how much an item has been sold/bought from NPC's, I'd then change in MySQL the base price (randomizing the economy a little bit). Of course, to be seamless to the users that data would have to become available in game without a restart, perhaps simulating what the servercommand loadquest does.

Technically speaking, again from what I understand although this may not be entirely true, the cache would have to be flushed and reupdated with the new data. Is it possible at this stage or is it possible to implement such a feature?

This was in-game not long ago, but removed due to some problems.

I'd rather not go into that discussion again, but the feature it provided was very interesting and I feel it would deserve a resurrection.

Why?

It would help with immersiveness as well as improve the way we "speak" to the NPC's. Basically, it feels more natural.

---

How?

* "Hello NPC_name" (full or short) triggers discussion with an NPC if in his/her range. Does not necessarily require facing the NPC. Does not get triggered when using the name of the NPC out of context.

* "/greet [NPC]" also triggers a discussion

* "Goodbye NPC_name" (full or short) triggers the end of the dialogue. It can also end if the discussion has been idle for more than a reasonable time (1, 2 minutes?). End of discussion can also be triggered by shift of focus from the chat tab of course, just as it happens now.

* The old way of talking to an NPC, via the select & talk way should still be valid as an alternative.

I was baffled by this story when I first read it, although I considered my experience and gaming and roleplaying abilities moderately good.

How wrong I was! A big thank you to Aurea and Michael for opening my eyes... and I hope yours as well.

Realtime Art Manifesto

Ideas my dearest fellows who have NO idea what roleplay is? Ideas from those who thought they knew?

I'm pretty sure that except a blessed few, we're all in the same puddle of mud this time.