Request for Webdeveloper

[acraig]

This is a request for a webdeveloper to help us on developing some web based tools to help add the required content to PlaneShift.  Right now we have a basic web console that is used to do everything from setup quests to configure NPCs.  However, at the moment the tool is not easy to use and has a difficult interface.   The entire system requires a complete overhaul and redesign.   As you can imagine this will be a complex system and one that will need a significant amount of work and time invested. 

This will be a fairly 'hands off' type project with just us providing requests for features and testings.  So will require a fair bit of proactive work to keep things moving along.   However, it will lead to close contact with the settings team as their demands for features will grow as new features are placed into the game. 

If you feel you are up to the task then this is what you will need:
1) your own webserver ( apache ) that you can host publically so we can see/test your design
2) your own mysql server

Skills required are:
1) Very good php
2) Good website layout/design
3) Some graphic skills
4) Mysql skills.

We can help with discussing about how the different database tables work and how they interact with each other. 

At some point if the design is good it will be used with the test server and eventually on laanx. 

Post here if you are interested and extra points to whoever can the serverconsole from CVS already setup.   

[Kaerli]

The big question is not "What kind of webconsole do we want?", it is "Do we want a webconsole at all?"  There are other ways to handle the problem of server remote adminstration...

[acraig]

The big question is not "What kind of webconsole do we want?", it is "Do we want a webconsole at all?"  There are other ways to handle the problem of server remote adminstration...

Yes, the idea of a seperate client or adding into the current client has been tossed around.  And for some things that might be a solution as well.  But also there are a fair number of people who don't have access to the client when they have some moments to work on PlaneShift.   Consider somebody on their lunch break that wants to update a few quests or update the damage specs on an item.  The webconsole gives them a quick and easy access.   The web pages can also be developed more quickly ( I hope ) than an in game interface or a seperate client.

[Aerig]

Hrm, I have not looked into PS source for quite a long time. Is the quest console as was when I compiled the dev docs stuff I put together at http://www.aerig.plus.com/planeshift/ps_dev_doc.zip ?

At that time I noticed that the console was not very easy to use, though it was clearly also WIP at that time so no criticism to the author who clearly put a great deal of effort into what was there.

Also at the time, I did offer to help flesh the console out a bit but suspect that, lacking proven reliability, the idea was considered a low priority.

For anyone who is considering taking this task on, you may find the link above to be useful since I did spend some time at that point investigating how the console worked and what the interaction between the various tables was like. The above link contains a zip file of documents some of which, at that time, were the only documentation on the quest console.

You would need to check with acraig, I think, to find out if the console guide documents I wrote are still relevant in any way.

If the actual PHP code for the console still conforms to the same basic structure as it had at that point in time then any competent PHP programmer will find it relatively easy to ammend the code to introduce new features and/or to improve on those that already exist.

Assuming that the code is roughly similar to what it was like back then, and that was a good couple of years ago, then my personal suggestion would be that a first priorities should be bug removal, data submission verification and clear documentation of the code and the console's functions.

• There were not too many bugs, but there definitely were a few that I noticed that were largely related to missing validation of submitted data.
• WRT to data verification, the table interactions are relatively complex and, at that time, the console allowed data to be submitted in too many areas which required inter-relationship with other data whose presence was not verified.
• Code documentation in the PS project at the time I was working on it was horrendous and, given that the devs work very hard on introducing new code, that is perhaps forgiveable. It was, however, also the reason that I collected the above documents together, in the hope that it would make it easier for new people to become involved.
• The quest console at the time was completely undocumented barring rough installation details and some cryptically brief inline advices. Perhaps the documantation I began has been maintained by whoever has continued working on it?

The result could then be that a player in the game could attempt to start a quest, get the quest lead in and then later, possibly in the course of the opening dialog, cause a query to be executed ingame that would result in zero hits, thus resulting in turn in some unpredictable ingame event wrt to the game code.

EG get_quest_details where no, inconsistent or incomplete details had been submitted might then result in the game code attempting to do something impossible -> possible crash or spurious game code execution resulting in unpredicable subsequent execution and/or memory allocation for data structures that did not exist (= possible ubiquitous memory leakage probs).

NOTE: my experience of the code is acknowledgedly dated and these comments may now be entirely redundant so I leave it to acraig to qualify their validity.

I might be able to spare some time on the console myself, however, I have to admit that I am fairly preoccuppied with other projects atm and that any time I could spend on it would be limited.

If access to the state of the console as it is atm could be provided then I would be able to say more clearly whether or not I could spend any appreciable amount of time working on it. I suspect the same would be true for anyone else considering offering their time to its development, as would some idea of what sort of things might be needed.

[Aerig]

The webconsole gives them a quick and easy access.   The web pages can also be developed more quickly ( I hope ) than an in game interface or a seperate client.

There is a possible misconception here I think. The webconsole is not for game admin. It is for quest data entry.

As last I saw it, the console was quite a far ranging and complex entity to use. There were more than a handful of data entry section and, as I mentioned above, there was little or no verification that interrelated entities, such as quests, quest givers and quest objectives actually existed in the game.

The reason I felt that it would be important to have that sort of data verification is because, unless you are running your own local server, which might mean going through all the hassle of downloading the source and installing a development environment (I was using MingW which was a pita to set up well), then you have the problem of not knowing if any quest development that you have been doing on the console is going to have integrity ingame.

IE you wont be able to check if any quest-data-submission verification code that you write is worth a damn and that sort of code was urgently required when I last saw the console.

Also, the console was at last sight a very complicated entity with several sections and subsections and not very easy to use for actually creating quests, though that was partly because it was incomplete and quite a few important database fields had to be filled in manually.

The result of that was that anyone using the quest console almost had to be a PHP programmer just to be able to understand what data to fill in, how to do that, and what table t hand edit so that submitted quest data woud have integrity wrt to those database fields that it did not allow the user to fill in. That may have changed.

Because of that, another important priority, should really be the reorganisation of how the console functions are presented. They were not, at that time, presented in a way that would be intuitive to the Quest Design team, who are responsible for actually populating the quest database with quest data.

What I mean by that is that the console used to be oriented toward data entry with the table structure more in mind that a quest designers perception of the fantasy world that they were populating. Thus, adding a quest involved navigating through several subsections within the console to populate the tables that each of those subsections were oriented toward.

What should really have been happening is that the console should have subdivided the world into areas that were logical from the perspective of someone populating the world with lgical entities.

EG define a Quest name, indicate the quest origins, indicate quest fulfillment targets. Then check the database to find out if the referred to entities exist and prompt the designer to define them as required. As was, the designer had to keep mental track of all the entities involved in their quests, which would inevitably result in quest design being a needlessly painstaking process.

The point I am making is that, when you take on the task of renovating the console (assuming it is roughly as was two years ago) then you should be someone who has insight into how someone populating a world will perceive that process as well as being able to follow how the table structures actually work.

One reason that I am wary of offering outright to work on the console is the fact that previously it took me two weeks to install MingW, CrystalSpace and the PlaneShift source code just so that I could compile a local server to check out the quest console.

For that reason I think it would be a good idea if anyone working on the console were given a private download address for a precompiled, preconfigured server so that they could test their work without going through all that hassle.

I hope my comments are useful and help whoever does this job pick up the background on it more rapidly. If I am provided with a logon to a dummy console, ie the code sitting on top of a defaultly populated set of tables, then I would be happy enough to spend some time taking a fresh look at it and make any constructive comments that seem relevant.

Subsequent to that I might also feel that I would be able to take some time to work on the code but that, as I say, is something that atm is subject to quite a heavy workload otherwise.

[Dihenis]

well i do know how to use LAMPs and i have set up some, but i don't know if i would be the right person for this. if no one else volunteers i guess i could do this, but somebody else would probably be better.

[Caarrie]

Aerig the dev web console is used by all devs and not just for adding quests to the database. I bet even more features could be added to the new one to make it easier for devs to see what is causing problems and be able to fix them without needing an admin with direct mysql access to fix minor problems.

[Aerig]

Aerig the dev web console is used by all devs and not just for adding quests to the database. I bet even more features could be added to the new one to make it easier for devs to see what is causing problems and be able to fix them without needing an admin with direct mysql access to fix minor problems.

As  said, I figured my post was a bit dated in my experience .. so fair do's. Even so I wa writing as you wrote so plaease take that into consideration ... I did spend a large amount of time thinking about a good post and not something trivial.

[Kaerli]

The big question is not "What kind of webconsole do we want?", it is "Do we want a webconsole at all?"  There are other ways to handle the problem of server remote adminstration...

Yes, the idea of a seperate client or adding into the current client has been tossed around.  And for some things that might be a solution as well.  But also there are a fair number of people who don't have access to the client when they have some moments to work on PlaneShift.   Consider somebody on their lunch break that wants to update a few quests or update the damage specs on an item.  The webconsole gives them a quick and easy access.   The web pages can also be developed more quickly ( I hope ) than an in game interface or a seperate client.

I was actually thinking of something more IRC-relay-bot-like that would allow not only for DB manipulations, but for near-RT game status and the ability to perform day-to-day admin work (like responding to petitions, renaming characters, or banning a foulmouthed n00b).  Such would be far more valuable to GMs than what I hear the current webconsole is like.

[eldoth_terevan]

Correct me if I am wrong, but it sounds like you guys need an interface with a large number of predefined SQL commands hooked into an interface of PHP (pages)? This is comparible to writing something like phpMyAdmin or a similar MySQL type of interface? So the first part of the work is rendering all of the possible command combinations and writing the tricky stuff that will make the interface more natural when it comes to making entries for non-SQL oriented people? Yeah, that's quite a job...

[Caarrie]

I was actually thinking of something more IRC-relay-bot-like that would allow not only for DB manipulations, but for near-RT game status and the ability to perform day-to-day admin work (like responding to petitions, renaming characters, or banning a foulmouthed n00b).  Such would be far more valuable to GMs than what I hear the current webconsole is like.

As far as i know Acraig is asking about a dev webconsole not a GM one and the GM webconsole is not public

[grumpytoad]

Hi, I've had a look at the console (the fact that you have an SC module in your CVS stumped me for a good while though) - I've setup the console on a private server, feel free to leave a private message if you want to see it.. I also have a mostly unused VPS server, where I could host a development setup - whether planeshift will compile is another matter.

My comments on the serverconsole: it's very buggy, or I may simply be missing some components. it's also rather user unfriendly. I can understand why someone administering this game would be fustrated by the interface.

Also, the database is suitably complex, that I think it would be difficult to make all the interrelated features work well without abstracting the php code a little more... generally a lot of it reads like spaghetti code I see often at work - some wrapper functions for spitting out HTML and, an entangled bush of SQL writing ad-hoc snippets into the database (of course, this can be done well, but that technique has some disadvantages). As the game gets bigger and more complex, the serverconsole is bound to become unwieldy and unmaintainable.

Personally I would use a framework to get everything together - you've already tried to integrate ADODB, in the previous version (at least the one that's in your CVS as SC which was last changed in 2005), why did you ditch it ? An ORM system can help to get a better grip on what is going on.

I hope I haven't insulted anyone too badly yet. I'm sure something can be salvaged - I'll need to have a closer look at what though.

[acraig]

Hi, I've had a look at the console (the fact that you have an SC module in your CVS stumped me for a good while though) - I've setup the console on a private server, feel free to leave a private message if you want to see it.. I also have a mostly unused VPS server, where I could host a development setup - whether planeshift will compile is another matter.

My comments on the serverconsole: it's very buggy, or I may simply be missing some components. it's also rather user unfriendly. I can understand why someone administering this game would be fustrated by the interface.

No, it's very buggy and unfriendly

Personally I would use a framework to get everything together - you've already tried to integrate ADODB, in the previous version (at least the one that's in your CVS as SC which was last changed in 2005), why did you ditch it ? An ORM system can help to get a better grip on what is going on.

I hope I haven't insulted anyone too badly yet. I'm sure something can be salvaged - I'll need to have a closer look at what though.

We tried with the SC module but the person that was working on it stopped and it was left.   Right now what we need is a concrete plan of action to develop a good user interface.

[grumpytoad]

well, I get the feeling there _is_ some useful functionality hidden away under several clicks (correct me if I am wrong) - the NPC pages seem to display plenty of information. It should be a good start to sift out the cruft, and work out what works, what is used most (if at all), and move some links around. It won't fix anything that is broken, but it won't look like quite such a half baked idea, and it seems to me, there is more desire for a productive tool, that is at least a little intuitive to work with.

for example to rework the quest section - instead of validating, you could fairly easily change input fields into dropdowns with only the available options. In the end though I would rather see a concrete Quest class, with methods for retrieving related npc entity data, which can then be double checked on posting the form after an update... it is quite a lot of work though doing this for every page

do you post bugs on the console in flyspray or is there an internal bug tracker for this ?

[acraig]

Since the webconsole is not really publicly used I don't think there is an option there for it.  I can add one though but I would do that after a redesign of the current one.  Since there are so many bugs and issues with the current one it would be a nightmare.