shadowsrising-devtalk — Primary list for "in-depth development discussions"

[Shadowsrising-devtalk] Q-Site - Don't take it as Gospel...

[Pádraic B. <mau...@ho...>]

Hi Matt,

This is long, so I'll get stuck in - don't expect an immediate response, so 
take all the time you need.

At the moment it looks like QS/SR and BSW (another game I'm sort of 
consulting on, rather than heading) will each have 4 components: a PHP Game 
Framework, the Game, Q-CMS Frontend, and Q-LIB backend library. In short 
we're at a point (especially with Q-Site) where things are getting really 
really re-usable - I'm a bit worked up now I've looked at Q-LIB for the 
first time in months ;). I was still thinking server problems (seem to be 
solved), and complex common/core files (solved), etc. Take a holiday, put a 
smug smile on...

I have however been planning some changes (largely to remove some 
dependency, and try to decouple from the CMS). I'm also going to be adding 
some new classes which I will need in the future. Just to point out some of 
the changes to structure are turning a few things inside out - but I think 
they're workable with any future plans you have. For example Q_Perms may 
need some refactoring to split out CMS/Application/Forum permissions - I'm 
thinking a common parent and three extending children. I'm also going to 
take advantage of Q_System to centralise some logic tasks. Another 
possibilty - down the line a few weeks - may be a Facade to present a 
unified API covering most of the custom classes, and various thirdparty 
extensions.



The structural changes:

1. It may change again, who can tell, but I have switched from the multiple 
core model. One of its problems is that it restricts how some areas in QS 
operate, its consuming the base directory, and it's placing an unnecessary 
dependency on Q-CMS. I don't think it will change after - and I hope it 
isn't screwing up your plans too much... If its any comfort inter-core 
communication should be possible - and indeed that idea of yours is looking 
very attractive.

2. Q-Site is probably going to get split as two distinct projects - Q-Lib 
and Q-CMS, the reason is that merging both will break a number of 
fundamental rules in how Q-CMS is going to operate. In most cases this would 
matter little - but in an design framework it breaks what may be considered 
some basic OOP standards. I also think a split will define responsibility 
between both a lot better. Also I'd like to avoid coupling and 
over-dependence - will make the entire thing more re-usable.

3. Some classes e.g. User.php will get revised. I want to separate unrelated 
tasks, make the library independent of the database structure (excluding 
required database tables for Challenge records and DB Sessions), and sort of 
create a two tier approach where aggregate classes like User.php would make 
calls to Q_Authentication, Q_Permissions rather than take over some tasks 
completely - I think will be put off, its sort of linked to creating a 
Facade API.

4. Smarty-Lite is to be added (if not already - must check) - should bring 
RAM downwards even more. I'm also seeing significant speed increases in 
processing - if this continues QS/SR will be way faster than any other PHP I 
can think of. Last I checked it was wiping the floor with Blacknova Traders, 
The Kabal Invasion and Legend of the Green Dragon.

5. Configuration - there are some values may need adding, but then again 
maybe not. I'll need to check the database surrounding the area. Sounds like 
a required table. Also sounds like maybe some could be made manual flags in 
any application setup files. Again, need to check...

6. Output buffering - may be changed, one issue is that QS uses a 
FrontController and InteceptingFilter to use init/close processes. Output 
buffering fits that, so any output buffer support should lend itself to 
inclusion in a pre and post process filter...

7. I love the idea of inter-core communications. Not sure if anything was 
committed in that regard, but I'm having thoughts of using XML-RPC to 
communicate with another core. This has a few benefits being XML based (it 
would not be core specific for example). And QS would really love to see 
that functionality - for example I really don't want the CMS making direct 
calls to the QS database - better they use some protocol instead that QS 
will respond to. SOAP is another option - but I think XML-RPC is a better 
fit - something for me to research.

8. Permissions - I really need to learn the system ;) Its your baby. I'm not 
commenting on it except that I make it database table independent. It may 
also need refactoring to separate various permission families. Hopefully not 
a huge job. I also really need to start using it! QS is moving ahead and 
will soon need permissions to work properly and securely.

9. Forum - will need to look - any work done here? I think a Forum library 
will be made within Q-LIB - letting the CMS and QS/SR implement it.

10. All references to Q-Site and Q-CMS will either removed, made external 
parameters, or reverted to Q-Lib where relevant. Really think we need more 
Q-less names for these. We have too many Q's floating around...;)

11. Should also reexamine redirects to use Location: headers if possible. JS 
is not a necessity - so maybe a JS fallback only if we can detect whether a 
header would not work. Last I tested Location: was over a year ago - I'm 
hoping its more successful at this stage.

12. echo(); die()/exit(); sequences are syptomatic of a Fatal Error - should 
pass off to an error handler using trigger_error('some message', 
E_USER_ERROR); You actually have a handler, and I may trust it (my libarary 
designs are advanced enough to show a custom error class for fatal errors 
isn't really required). I'll add any extra functionality I needed to it 
maybe.




Other thoughts on my mind:

a. Should we make session key names more specific - I've never bothered to 
check but what happens if two widely different applications use a 
$_SESSION['authenticated'] value on the same system - user may be forced to 
logout of one to use another, etc. I'm thinking of allowing application to 
specify a unique id, e.g.

define('APPKEY', 'quantumstar');
define('SESSION_AUTHENTICATED', APPKEY . 'authenticated');

$_SESSION[SESSION_AUTHENTICATED] = true;
$_SESSION[SESSION_EXPIRY] = time() + 3600;
$_SESSION[SESSION_USERNAME] = 'Maugrim';


b. Also thinking we could make Q_System include an Object Registry - it 
might centralise all those common class instances, i.e. would use $db = 
Q_System::getInstance('Q_DB'); This is not a necessity but would allow some 
central control over what's instantiated, when, and whether reserved as a 
static instance. By the the Q_System class is great...

c. It was mentioned Q_DB has some problem - I'll try find it but I'm not 
actually using the class yet, since I'm not yet testing code from QS.

d. Is there any reason why we shouldn't migrate all procedural code to 
Classes? Just wondering...

e. How much does the above screw about with your permission class, and other 
plans? I'm hoping that separating CMS from Forum from Application in 
permissions would be possible - maybe by creating three separate classes 
which extend a common parent class. i.e. CMS/Forum/Application would be 
specific child classes (hopefully with an identical interface) extending one 
parent which contains any common code. Again, I need to look under Perms 
hood...;)

f. I think some the logging tools should be added to Q-LIB - esp. the 
FilterLogger, SecurityLog, etc. I also think the old Menu Nav system should 
be ported - its not specific to a game, or the QS game framework.

g. Can we shave some processing off Q_DB by referencing the ADODB API more 
exactly (we don't seem to mirror $adodb::GetOne(), etc.). The whole file 
seems a little bloated, though I don't think its avoidable given its 
usefulness...



Other observations (mainly for me):


common.inc.php adds a forward slash to end of URLROOT (will need to amend 
templates!)
Need to set APPKEY prior to requiring common.inc.php
Need to add Q_Authentication class and use with Filter_UserValidation.php
Need to check setup of output buffering (will be implementing a separate 
gzip buffer external to Smarty). Buffering inside Q-LIB may effect that...to 
check.
Need to add XML-RPC, XML Parser, InputFilter, etc.


Lastly:

Overall Q-Site is looking really good - think you solved stuff that's 
plagued QS2 for a long time...lol. Hopefully these changes aren't messing 
you about too much - but we can discuss that when you have more time. As it 
stands QS3 will use the current version once my changes go though - I'll add 
them to a new repository to maintain the current working files. I will also 
need to look into setting a new project for Q-CMS and Q-LIB (migrating from 
Q-SITE). Might be time to consider colourful names for this collection of 
misfits ;). I may also shift defined config options to a config class - 
basically I'm trying to keep defines out of QS unless they are generated 
internally (i.e. stuff like URLROOT, etc.). Objects also make it almost as 
easy as defines to pass around a system - we'll see how it works out anyway.

If you have some spare time, and want to see how QS is being set up - 
checkout the CVS quantumstar_phpsource repository. It has many of the base 
files, in the new game framework. Some of this can be ported to QLIB I think 
- especially stuff like InputFilter class, etc. Even more is portable to SR 
since its not actually game specific. At this stage creating any sort of PHP 
game is beginning to look simple...;)

And you still have improvements to make?

-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-
Pádraic Brady

aka Maugrim The Reaper
http://www.quantum-star.com/
http://www.shadowsrising.net/
-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-

[Shadowsrising-devtalk] The Basic Game Structure :: MVC/FrontController

[Pádraic B. <mau...@ho...>]

This is relevent to both SR and BSW (hence you're reading it - maybe ;) ).

As many know, both SR and BSW are based on the structure and code utilised 
in creating Quantum Star SE (a space strategy game). The relevant pieces are 
not specific to a game and are therefore highly portable (re-using them 
saves a lot of time believe me). The below text is yet another summary of 
the upcoming MVC model - but includes reference to the newer Front 
Controller being added. Not mentioned here is the complete makeover in QS 
directory layout to accomodate the new model - the layout is again game 
independent so it will make SR and BSW relatively unscathed.

A lot of this is theoretical - but I do suggest that PHP developers be aware 
of what MVC is. A Source Code Guide is being drawn up to run through this of 
course - but any general reading would help. I also note that with this 
model 99% of the games will be Object-Oriented. I do however think that the 
new model will help developers code things easier - ;)

Any q's - let me know.

-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-
Pádraic Brady

aka Maugrim The Reaper
http://www.quantum-star.com/
http://www.shadowsrising.net/
-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-

Quantum Star SE 3.0.0 - the tenth revision

During the next 2-3 weeks, QS3 will hit its first major milestone (set way 
back in January 2005). The tenth revision (v3-0.10) brings together numerous 
ideas, plans and test code which have been hanging in limbo for months. In 
short it shows the future face of v3.0.0 - and what sort of mutated beast it 
will be ;).

The primary idea to keep in mind is that QS does a fair job at separating 
data, business logic, client code, and presentation. The original pre-alpha 
back in April was not quite so clean - it integrated everything into a 
ad-hoc hodge podge. v0.10 however handles things quite different.

The primary "structure" being used is one based on the Model-View-Controller 
design pattern. For those not familiar with the concept - MVC describes an 
object oriented class structure which separates certain broad tasks - 
typically Controller, Views, Business Logic and Data Access.

The advantages of the above is that it maximises code reuse, and minimises 
code duplication (the major banes of QS2). In doing so it breaks down many 
aggregate tasks into their individual tasks - and sets each as a object 
method. Doing so allows far simpler maintenance and debugging. There are 
other advantages (but I'm trying to limit this entry!).

For QS3 the MVC implements a Business Logic Layer, a Data Access Layer, a 
Presentation Layer, and a Controller (the Controller is yet to be added - 
since all layers are independent, changes to one do NOT effect another - 
basically its made of a Front Controller, which makes calls on various Page 
Controllers). The Data Access Layer handles all SQL queries, and their 
results. The Presentation Layer (simple Smarty-Lite) prints parsed templates 
to the browser. The Business Logic (or Model) layer handles any internal 
logic operations - e.g. deducting credits, adding turns, checking if a ship 
belongs to a fleets, etc. The Front Controller handles incoming requests, 
and based on those requests accesses the Model Layer to perform the 
requested action.

As an example:

Player A wishes to Warp to SS#2 from SS#1. He clicks a url of the form 
(http://www.example.com/index.php?action=location.navigate&starid=2. The 
Front Controller will immediately parse the action value - in this case it 
refers to the Navigate command of the Location module. On this basis, it 
will search for the relevant Page Controller 
(/Modules/Location/NavigateCommand.php). The Navigate Class will contain the 
simple methods (common to all Commands) of execute() and render(). execute() 
will make calls to the Business Logic Layer to update locations of User and 
Fleet (in QS3 a Ship's location is taken from it's parent Fleet) while 
render() will parse the relevant Smarty Template and output the result to 
browser.

Its worth noting that the Business Layer contains delegating functions to 
the Data Access Layer (in effect, a Command class developer would only need 
to know the BL API - as the BL will pass off to the DAO layer methods, i.e. 
it handles any other related classes). I also note that data is passed 
between all layers as a Transfer Object (i.e. an object with properties 
populated from the data source with simple get/set methods for each property 
- TOs are passed to the Data Access layer for writing to the data source is 
needed).

Now to all reading, this may seem horribly complex (and it can be!), but one 
thing that should be noted is that all this separation and complex 
contortions results in very fine grained separation of tasks - leaving (of 
course) many more discrete files, but which are organised by task and 
module, and are open to editing without disrupting any other code. It comes 
at the price of intuitive understanding - but I think its a solid step 
forward.

So what about the game!!!

The impact on QS3 play is not a huge one (at least compared to the 3-0.6 
pre-alpha). The game still does the same things - but it does them faster 
and more efficiently. There's been added a certain openess which will allow 
complex plugins and game modules. Single entry points into the game allow 
centralised controls over input data, url validation, etc - adding security, 
and removing any alternate entry paths. It also allows a neater method of 
developer's authorising valid url's in response to any request - i.e. 
restricting pageflow.

You thoughts are welcome.

[Shadowsrising-devtalk] Back to work...;)

[Pádraic B. <mau...@ho...>]

Point by Point through your email of 4 Sept (just getting to it).

>Ok, going to deal with your email as best as I can :)
>
>Zero, good to have you back!

Glad to be back after a 3.5 month break...;)

>First, please send future email to mib...@gm.... I will stop checking
>email at this address in about 2 weeks (maybe once a month to see if
>anything important didn't get notified).

Copying this there in case the mailing list is not updated.

>Second, I use php5 on my testing machine so it is all fine and dandy, but i
>think it important to remain 4.3 supportive.

I actually use PHP4 (just to certain). PHP5 is setup also, but I usually 
test back on PHP4 to avoid any issues. Though its a bit of a pain, I've 
grown a large preference for PHP5 since I started using OOP.

>Next, we need to hash out some kind of Coding Guidelines, it will stop
>inconsistancies in programming style, I am thinking a wiki would be good 
>for
>that or something. Things like naming conventions need to be sorted out. 
>All
>I know is that we need one, especially for any future developers. (and 
>don't
>think I didn't notice your much better PHPdocumentor documentation ;) )

Coding Guidelines were requested for another project too...lol. I'll bash 
out a draft at some point based on an existing set. A few principles would 
be ensuring PHP4 code is updateable to PHP5 (i.e. that it should be possible 
to bring it up to PHP5 level without significant editing, or structure 
changes. I'm also starting a campaign to use design patterns (e.g. the 
singleton getInstance method) in code - at the end of the day a working 
knowledge of those patterns is pretty useful. Other than that - simple API 
structure with simple method names, specific classes vs generic classes, 
etc. I'll get to it.

>Everything here-on-out will be sparadic attempts to respond to points in
>your message and attached items.
>
>One thing I noticed in db2.class.php is the insertion of references to
>'game' and 'module'. I am currently attempting to remove all such 
>references
>and trying to come up with a good way to impliment them independent of the
>backend or within the backend but more generic. I want to limit them in 
>this
>way to give as much flexability as possible in any other core modules that
>may be developed. Hard-coding things not everyone will use just seems like 
>a
>bad idea. Also, weren't we changing 'game' to 'app'? I thought you said 
>that
>somewhere, but if not, I really don't care.

See previous email - suggested a new interface API. Removed the abbreviated 
method names (bit pointless since they don't really make things readable). 
Thinking of setting up an in-game preferences class to handle similar 
preference data, i.e. $prefs::getInstance()->getGameInstance(). Still need 
to look at Q-Site about config data - I still have a feeling that I'll need 
to pull that data into an object (probably at runtime if your method looks 
fine), simply because of the OO model I'm using.

And yes, refs to game should be switched to app or application.

>I kinda want to stick with the $query = $db->query(__FILE__,__LINE__,sql).
>The reason being is that it allows limitless queries to be passed without
>worrying about overwriting a previous query result. I have no problem if 
>you
>want to return the query result _and_ store it internally and allow the
>result functions to take optional parameters, that if not specified, will
>use internal result.

It is retained - my own methods simply use a different behaviour, yours work 
same as designed.

>  $db = Q_DB::getInstance();
>
>
>THAT IS AWESOME. Is that just php5? You see, I needed a system class which
>would handle all the other classes to limit use of the global keyword and
>make things nicer to the external crowd. What I got was an evil mess on the
>interior code. Every one (except the db one, which didn't respond well when
>I tried to do it) of my classes now get a reference to the Q_System class
>passed to them as an initialization var and they store it in $this->p (p
>stands for parent). So, if Q_User needs a Q_Perm (to be re-written (again)
>with the new model in mind) function it would go: $this->p->perm->can().
>Which makes everything pretty outside, but the interior of the classes have
>become horribly delicate. There are nice implications to $var =
>Q_CLASS:getInstance();

Works in PHP4 also - though the code differs:

PHP5:

private static $thisInstance;

public function getInstance() {
    if(self::thisInstance == null) {
        self::thisInstance = new Q_Class();
    }
    return self::thisInstance;
}

$new = Q_Class::getInstance();

PHP4:

function &getInstance() {
    static $thisInstance;
    if($thisInstance == null) {
        $thisInstance = new Q_Class();
    }
    return $thisInstance;
}

$new =& Q_Class::getInstance(); // not sure if the extra ref & is needed, 
maybe.

>I also noted something about an Object Registry, and have something of the
>sort implemented with my horrible parenting method, and look forward to
>anything you have to say more about this.

Will look. But basically instantiation should be delegated as far as 
possible from the client code, thus it should be handled within the lowest 
child class or a suitable parallel Factory Class. Stuff like Q_DB are going 
to get instantiated by client code, stuff like Q_Log/Q_Error only when such 
a task is needed (which by design would only be in client code, if client 
needed to make a custom vs automated log entry).

Seeing the mess in the last paragraph :), that probably sounded giberish. My 
thinking is every class that can benefit from a singleton, should have a 
singleton (usually if only one instance is ever required). In that case, 
instantiation should be done only when required (not just 'in case' its 
needed). An Object Registry allows classes (usually an array of referenced 
objects) to be centrally located - but I'm not sure that's the best method - 
it imposes an additional layer (probably not required), is complicated to do 
in PHP4, and it usually means that every registered class can be directly 
instantiated.

Direct instantiation may be too loose a system. Sometimes tying a class to a 
single instance will prevent multiple copies (especially if enforced by 
private constructor, or an error in constructor for PHP4) Q_DB for example - 
you could do

with OR:

$register = Q_ObjectRegister::getInstance(); (assuming the object is NOT 
global...bad karma)
$db = new Q_DB();
$register->setEntry('Q_DB', $db);
$db =& $register->getEntry('Q_DB');

... later in another class ...

$register = Q_ObjectRegister::getInstance();
$db = $register->getEntry('Q_DB');

without OR:

$db =& Q_DB::getInstance(); // simple...

Why bother with a registry?

>From your notes about $config. Already out of the global space (or should
>be... evil little bugger). I have been feverishly trying to update the code
>to an object model with what little time I have these days. $config is an
>array of all configuration from the DB, and should now be stored in
>Q_System::config. Be sure to keep current with qsite, as it changes often
>these days. I am trying to adapt new ideas as fast as I can.

At present, QS only accepts three globals (two are being removed this week), 
and config will be last one left to sort out. Reason I suggested an object 
(well, technically you could compose a Transfer Object from the data source) 
  is that it's easier to pass around inside my MVC model for the game. 
(which SR will share). Also I'm moving towards a lot of de-integration. 
Config is one set of data, therefore it belongs to one Data or Transfer 
object (QS divorces data from logic, as well as logic from presentation, and 
more - data is passed around the system as objects, unless a collective 
array of course).

>One of these days the qlib system will be set and I can update qcms with 
>the
>new model in mind. For now I am not touching that anymore until the backend
>is more mature. Which reminds me that I haven't even started planning
>interfaces to the core module, as I hope to allow more than one to be
>installed per qsite, which would allow same users to access many cores
>without making new accounts for each one on a seperate qsite, can still do
>it, but don't have to.

One area I'll be looking at - I'd like to offer that potential, but also 
allow some consideration of Q-Lib of an independent library source (i.e. 
just as easily stored within an application directory, as without). One of 
those reasons is that Q-CMS is technically a second application - hence it 
could be considered a second core, with a game/app as the first. Not a lot 
of thought from me on that topic - just a general thought for now.

>Just noticed this, but I am allowing the folders to do the catagorizing 
>now,
>so the 'class' in db.class.php is no longer, I believe the current filename
>to be DB.php

Doing the same here sort of - I'd still like to make sure all classes are 
prefixed with Q_ (avoid conflicts with a users custom classes), and files 
organised by directories related to TaskName/Thirdparty/Includes/etc. in the 
base directory. The last qsite sort of jumbled things together. At the 
moment I'd like to see the include files switched over to classes where 
possible. e.g. Q_Smarty should extend Smarty, and overload common methods 
like display() where additional steps need to be added - therefore from 
users perspective they are instantiating and using Smarty without much 
change to API. (It's the opposite for ADODB/Q_DB where API does change - but 
that's an exception).

QS largely arranges classes by class purpose and related classes - e.g.

BaseDirectory
|
Plugins
System ------> GameLog, HelpParser, GamePlugin, GameModule
Modules
Settings
Help
Maps
Includes
Defines
Themes
Language
GameEngine
|   |   |   |
|   |   |   |
|   |   |   |
|   |   |   |
|   |   |   GameMaintenance-------> MaintenanceLog, MaintenanceProcess
|   |   |
|   |   GameData-------> TransferObjects, UserPreferences, GameSettings
|   |
|   GameLogic-------> BusinessObjects, BaseAPI
|
GameDataAccess--------> DataAccessObjects, DataAccessGatewayObjects

These directories may contain several classes, usually sets of related 
classes, e.g. GameLog will contain a common GameLog parent, alternative 
LogDB and LogXML implementations, and probably a Factory class to decide 
whether to implement the DB or XML interface. DataAccessObjects as another, 
will contain any classes related to database interaction for base data (e.g. 
a character, ship or fleet record.

>There is somewhat of a backtracing 3rd party library for error reporting
>which does a good job and I have been considering dropping the
>__FILE__,__LINE__ myself, but what you have seems nicer because it will
>allow the sql query logger to maintain file/line after dumping in function
>support for it. Logging is being built into Q_System.

The logging functions discussed are a little different maybe (possibly could 
be merged, or factored into the current class). I'm adding the ability to 
log through XML as an alternative to DB. Hopefully the FatalError class can 
be configured to allow access from trigger_error (thereby catching PHP 
errors, as well as custom errors). Idea is to allow monitoring of such 
conditions and link to a log analysis and notification toolset. There's also 
a variety of logging conditions - not just errors, e.g. input invalidation, 
user activity, audit trail to get added.

>As far as the core module is changed, some critical things may have to
>change minorly, but I don't see a huge problem. Interfaces will be written
>allowing communication between cores/other cores/qcms. This will completely
>remove dependence of one on the other and allow plug-and-play for a broad
>range of applications. For example, If i want to know if a user exists in
>another game I would use a function in the interface instead of directly
>querying it myself. This makes it so all cores don't need identical user
>tables as each core handles the request set to it..

Sounds cool. I think is sort of related to segregating and removing 
dependence between Q-Lib vs Q-Site. Makes a lot of sense. At the moment it's 
pretty much laid out that Q_CMS interfaces with QS/SR to add characters to a 
game so an interface would be welcome.

>As much as possible, I am trying to provide as much functionality while
>keeping it generic in qsite to the cores. For example, Modules and Hooks
>will have a backend library so that cores don't have to rewrite them, and
>qcms can use it.

Has a Module/Hook class been written? (outside my initial version). It's 
actually due for an overhaul since the original class was largely based on a 
procedural process - it was also pretty generic.

>The hardest part so far is writing the installer in a generic way so that 
>it
>can handle the installations of multiple cores and qcms, including removal
>and maintenance. Lookout is better now I went to a OO based approach. 
>Though
>tedious work.

Is it necessary to use one generic installer? For example, each installation 
is bound to have some specific needs. It may be possible to simply write a 
generic parent class (Q_Install) which does the typical setup tasks (e.g. 
which cores to install, how many, specific needs), defines a list of 
standard methods that any child should implement (an absract). You could 
then add a Factory class which based on some limited detection data will 
make calls to a CORE's child install class. Not sure if that made sense...

e.g.

Release has two cores. CoreA and CoreB. Each contains a CoreInstall class 
which does a few CORE specific processes (maybe QS needs Install to pass 
control to a GameCreator class, or something, when finished, maybe it needs 
to setup some specific directories as writeable internally). At the end of 
day the User should dictate Installation.

The Install Utility (from Q_Site/Q_Lib) will start by calling a base class, 
say Q_NewInstall.

Q_NewInstall detects any COREs that are not installed (tracked somehow?), it 
then checks for the presence of an Installation Class. Say 
/base/install/Install.php. It also sets up a queue of each CORE's install 
classes.

In the installation process (if cycling through COREs), Q_NewInstall can be 
used to instantiate each CORE's class in turn for processing. Typically each 
CORE class, would extend a common parent (perhaps BaseInstall - to avoid 
duplicating methods).

NewInstall is therefore acting as a Factory.
BaseInstall is acting as a common parent (maybe an abstract under PHP5 - 
forces each child implementation to overload certain defined methods, and 
maintain an identical interface of some description.
CoreInstallA - CoreInstallB (the children) would each have identical methods 
(as enforced by the abstract parent) - but their implementation of those 
methods may differ depending on specific needs

>Sorry about the short reply, but it is 1:17 AM here, and contray to popular
>belief, my best thinking does not occur in the wee hours of the morning!
>(nor coding)
>
>Thanx
>Matt
>
>PS. I think we should set up channels on IRC for SR/QSite/QS, probably at
>freenode.

Will look into it...

>PPS. I have no idea where my time is going these days... It must be all
>those evil RSS feeds I have, it takes hours to make it through all of them!
>(NOT kidding)


Long email...;) Hope it made some sense


-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-
Pádraic Brady

aka Maugrim The Reaper
http://www.quantum-star.com/
http://www.shadowsrising.net/
-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-

[Shadowsrising-devtalk] Q_DB Draft API

[Pádraic B. <mau...@ho...>]

Matt,

How's things - about two days from getting Q-Site downloaded and reviewed. 
Still catching up on some things, planning a few classes, and planning for 
two games. Busy...;)

Copied this to your new email in case you've not updated the mailing list 
(if not, might check for yesterdays mailing list post - a new class I'm 
working on for Input Filtering).

Going to revisit Q_DB again. This time I am doing a few different things:

1. removing abbreviations
2. forcing use of a singleton instance (maybe leave this optional for 
backdated code)
3. removing $game/module instance variables
4. Editing for file/line per new Q_Error class
5. few other things after I check on any later DB versions from CVS

I'll place the API below - basically it still retains my methods, but 
changes the names and abbreviated versions (which are probably too confusing 
to be usable).

Few things, should we set up a different devtalk list for Q-Site? Also I am 
having thoughts of a name change for the project (Q-Site is not a unique 
name). You might see a few posts about Q-Site now I'm back on the 
development trail...;)

Few other things I am looking at are config (be checking Q-Site cvs soon). 
Just need to see how I'm going to get these into the SR game classes (and 
QS) without using globals, and without passing by parameter.

The interface would look similar to (leaving out the code for sake of 
clarity)

<?php

interface Q_DB {

	// $r refers to a method which works exclusively with the last internally 
set $result property
	// Other methods may pass $result as parameter, or not require $result to 
be stored internally
	// Included are data escaping functions

	private function Q_DB() {} // cannot be directly instantiated

	public function getInstance() {} // singleton pattern (instantiate or 
reference)
	public function getADODB() {} // singleton pattern (return current ADODB 
instance)
	public function connect() {}
	public function select() {} // $r internal behaviour (QS2)
	public function selectLimit() {} // $r internal behaviour (QS2)
	public function query() {}
	public function queryLimit() {}
	public function read() {} // $r internal behaviour (QS2)
	public function readAll() {} // $r internal behaviour (QS2)
	public function getOne() {}
	public function getAll() {}
	public function execute() {} // $r internal behaviour (QS2)
	public function where() {}
	public function replace() {}
	public function autoexec() {}

	public function affected_rows() {}
	public function record_count() {}
	public function insert_id() {}
	public function recordCount() {} // $r internal behaviour (QS2)

	private function flush() {}
	private function timer() {}
	private function incrementNumQueries() {}
	private function setConf() {}
	private function makeTag() {}
	private function logQuery() {}

	public function qt() {} // escaping variable
	public function qta() {} // escaping array

}

?>

Let me know what you think? I have kept the original behaviour for some 
methods (your preferred behaviour is retained in query(), where(), 
autoexec(), queryLimit(), replace()...

-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-
Pádraic Brady

aka Maugrim The Reaper
http://www.quantum-star.com/
http://www.shadowsrising.net/
-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-

[Shadowsrising-devtalk] PHP Input Filtering (to be used in all game projects)

[Pádraic B. <mau...@ho...>]

All,

Another set of documentation for yet another class. Posting this to both 
projects since it concerns use within PHP game code. Any queries, comments, 
or suggestions - send them my way ;). In short this describes an InputFilter 
class, for use in pre-processing POST/GET/COOKIE data. Should make some 
people feel a little safer. This now brings to two the number of security 
levels in place to prevent/discourage cheating (the other being the URL 
Authorisation, i.e. the Navigation Class).

Paidi


Input Filtering Class
=====================

Author: Padraic Brady
Date: 8 Sept 2005
Revision: 1.0
Type: Documentation

Contents
--------

1. Introduction
2. Duties of an Input Filter
3. Operation of Input Filter
4. Source Code (v0.1)
5. Future Considerations


1. Introduction
---------------

One of the major shortfalls in all SR/QS code to date (perhaps not Q-Site) 
is that they continually ignore implementing a clear specific method of 
filtering input, and escaping data. It's one of the shortfalls identified in 
my May review of QS (along with the interlinked OO design, memory usage, and 
global objects - there are others).

The basis of Input Filtering is simply that you cannot under any 
circumstances trust any data sourced by any user. This extends to GET, POST, 
COOKIE and some elements of the SERVER superglobals. At present all input 
data is subject to testing on the data we expect to receive - this ignores 
any possible other data which applications may not expect. Even the testing 
is largely ad-hoc, and may or may not check on data type.

To resolve this problem, the Q_InputFilter class has been written (this is 
not complete as yet, but it gives some idea of how it works.


2. Duties of an Input Filter
----------------------------

Full complete input filtering at the end of the day, is going to done by 
client code. However the primary steps can be retained in the Q_InputFilter 
class. These duties include:

- Deletion of unexpected data
- Checking of data type/content
- Overwriting of Superglobal arrays


3. Operation of an Input Filter
-------------------------------

Simply put, we start comparing input data to a template of what any one 
particular part of our application expects. This typically involves a 
whitelist approach (since attempting to blacklist potential problems would 
be a hugely unreliable approach). The developer basically writes their code, 
then adds a template (a class) which specifies exactly the keys and value 
type/content of the input data the script expects. What should happen, is 
that any input data which breaks these pre-defined rules will immediately 
result in two outcomes:

	a. The data is deleted
	b. The data (and user) get logged

In summary:

	1. Create a template of all expected input data (a whitelist)
	2. Search the Superglobals for unexpected data
	3. Delete the unexpected data
	4. Log any unexpected data, and the origin of that data


4. Source Code (v0.1)
---------------------

As the class is still in writing, don't view this as a final version. I also 
don't claim credit for the process, which is based on a set of articles by 
Ben Ramsey.

The example below uses the QS3 location.php base file in showing a template.


The InputFilterData Class (for location.php):

<?php

/*
* @copyright &copy; 2005 Padraic Brady
*/

class Location_InputFilterData {

	var $post;
	var $get;

	function Location_InputFilterData() {
		$this->post = array(
			'ss_op'=>'string'
		);
		$this->get = array(
			'toloc'=>'integer',
			'fid'=>'integer'
		);
	}

	function getPost() {
		return $this->post;
	}

	function getGet() {
		return $this->get;
	}

}

?>

Typically (under php5) the properties of this class would be type 'private'. 
Hence the use of getters.

The above shows a simple definition of expected input data, it includes the 
expected key names, the format of the data, and differentiates between 
POST/GET/COOKIE. It does not include $_REQUEST (I prefer not using it). If 
any user were to pass a GET value of $_GET['admin'], this would be found by 
the InputFilter class (below) and since it does not match the whitelist of 
expected GET keys, it would be deleted. Similarly, if a GET value for 
('fid') of 'gohome' were sent, it too would be deleted, since as above our 
template file indicates that $_GET['fid'] should be an number. (ed: use of 
integer above is not entirely accurate.)

In this way, if we don't expect a value, it will not survive passage through 
the filter.

The Q_InputFilter Class looks like (for the moment):

<?php

/*
* @copyright &copy; 2005 Padraic Brady
*/

class Q_InputFilter {

	// constructor (not to be instantiated directly)
	function Q_InputFilter() {
		$error = new Q_FatalError(debug_backtrace());
		$error->reportError('The Q_InputFilter() Class cannot be directly 
instantiated.');
	}

	// static function
	function filter(&$input, $allowed) {
		$filtered = array();
		foreach ($input as $key => $value) {
			if (array_key_exists($key, $allowed))
			{
				$keyset = (isset($allowed[$key]) && !empty($allowed[$key])) ? true : 
false;
				switch ($allowed[$key]) {
					case 'string':
						$value = (ctype_print($value)) ? $value : null;
						break;
					case 'integer':
						$value = (ctype_digit($value)) ? $value : null;
						break;
					case 'alphanumeric':
						$value = (ctype_alnum($value)) ? $value : null;
						break;
					case 'alphabetic':
						$value = (ctype_alpha($value)) ? $value : null;
						break;
					case 'lowercase':
						$value = (ctype_lower($value)) ? $value : null;
						break;
					case 'uppercase':
						$value = (ctype_upper($value)) ? $value : null;
						break;
					case 'nospaces':
						$value = (ctype_graph($value)) ? $value : null;
						break;
					default:
						$error = new Q_FatalError(debug_backtrace());
						$error->reportError('Invalid option set for the value type of a 
$allowed array parameter value. The type of any expected input data key must 
be one of: string, integer, alphanumeric, alphabetic, lowercase, uppercase 
or nospaces.');

				}
				$filtered[$key] = $value;
				if($keyset === true && $value == '')
				{
					// in this case, a non-empty value existed for a key, but was blanked 
by the filter
					// this may indicate user intentionally passed own data - should be 
logged to Audit Trail
				}
			}
		}
		unset($input);
		return $filtered;
	}

}

The above class contains a simple static method for searching a superglobal 
array. It should be noted that the InputFilter is the first item to be 
called prior to including any other code, e.g. the initiation file for QS3, 
core.inc.php. It's use for say location.php would be as folows:

<?php

require_once('inputfilters/Location.php');

$filterdata = new Location_InputFilterData();

// this section would typically be included in core.inc.php (done without 
specifying in client code)
require_once('../qlib/classes/inputfilter/InputFilter.php');
$_GET = Q_InputFilter::filter($_GET, $filterdata->getGet());
$_POST = Q_InputFilter::filter($_POST, $filterdata->getPost());

require_once('core.inc.php');

// ... other file code ...

?>


5. Future Considerations
------------------------

At present the class is limited to applying logic on key names, and value 
types. It is being planned to add certain specialised cases, e.g. email, 
username, url, publictext, etc.

It is also expected that the class will at least partially integrate with 
the htmlSafe library to enable checking of certain data input for XSS and 
other vulnerabilies. The final version will also integrate with the Q_Error, 
and Q_Log classes, which will enable the above error reporting, and the 
logging of unexpected input data (makes sense to keep track of potential 
cheaters or scriptkiddies).

Also, another objective is to expand on the data checking to include string 
lengths, integer max/min value, etc. Although these will still largely be 
checked by the client code. The class is meant as a set of standard 
pre-processing tasks - further input checking will obviously be necessary 
that is specific to the code at hand.

-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-
Pádraic Brady

aka Maugrim The Reaper
http://www.quantum-star.com/
http://www.shadowsrising.net/
-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-

[Shadowsrising-devtalk] Update to PHP 4.4.0 - Issues

[Pádraic B. <mau...@ho...>]

Just a short note on some issues with the latest PHP 4.4.0 release (in 
July). I noted and later confirmed that it handles returning an object from 
a function or method differently. To be exact you can no longer return an 
object directly using:

return new SomeClass();

and must now use:

$class = new SomeClass();
return $class;

This may not seem like much, but an update to PHP 4.4.0 will also 
necessitate updates to at least ADODB (not sure about Lite). It may also 
effect code which to date utilises references - notably issuing of a error 
notice in some cases. Generally this part is not a serious issue - it's only 
a notice afterall.

Just thought to mention it since I had to fix some QS code after it started 
bugging out on PHP 4.4.0.

-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-
Pádraic Brady

aka Maugrim The Reaper
http://www.quantum-star.com/
http://www.shadowsrising.net/
-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-

[Shadowsrising-devtalk] Re: [Shadowsrising-cvs] shadowsrising/install/themes/Default/templates config_fo

[Pádraic B. <mau...@ho...>]

For those remaining in the config file - I have a few rambled entries 
somewhere (I have a library of notes and stuff somewhere) about pushing the 
config file into an class. Basically the idea talks about getting config 
values into a game's object model. It suggests composing the config file as 
a class - typically an object with properties, and various 'getter' methods. 
It is only a suggestion - I think my thinking at the time was to remove any 
non-essential variable setting that occured, and use an object to store 
config data instead. Therefore avoid passing config data around using 
globals or constants that might be open to interference. As a class, config 
data can be completely secured from outside influence short of someone 
actually editing the file.

For the sake of illustration, such a class would be similar to:

<?php

// php4 version

class ConfigurationData {

   var $root = '/path/to/basedir'; // list of all config vars written by 
install process

   function ConfigurationData() {}

   // singleton instantiation method (only one class ever instantiated, 
regardless of number of calls
   function &getInstance() {
      static $thisInstance;
      if($thisInstance == null) {
         $thisInstance = new ConfigurationData();
      }
      return $thisInstance;
   }

   // getter method for ConfigurationData::root
   function getRoot() {
      return $this->root;
   }

}

?>

Usage:

$config = ConfigurationData::getInstance();
require_once($config->getRoot() . '/core/classes/example.class.php');

It looks nicer in PHP5...without the reference &'s littering the singleton, 
being able to declare static properties, etc. To be honest the past few 
months PHP4 has been pushing back what I can do in QS. I'm looking forward 
to more widespread PHP5 adoption.

Just thought I'd throw this out as a FYI. In QS3, and the next SR version, I 
expect pretty much all data to be encapsulated in objects per the MVC model. 
It's also looking like both games will start arriving in both PHP4 and PHP5 
variants for future compatibility (PHP4 versions will be 'dumbed' down 
enough to work - the PHP5 version will be more secure and less error prone. 
Another FYI, eh?

In PHP5, each property would be private (cannot be set outside a class 
method - and there will be no setter methods).

In either version, you would include config data using the usage example 
from within any class requiring access to the data. Therefore, no globals, 
or constants, etc. that may be insecure.

Another MtR copyrighted ramble ;)

-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-
Pádraic Brady

aka Maugrim The Reaper
http://www.quantum-star.com/
http://www.shadowsrising.net/
-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-




>From: ProgrammerMatt <pro...@gm...>
>To: Pádraic Brady <mau...@ho...>
>Subject: Re: [Shadowsrising-cvs] 
>shadowsrising/install/themes/Default/templates config_fo
>Date: Fri, 2 Sep 2005 16:13:55 -0500
>
>Well, you see the problem is I cannot decide if I want to rewrite the
>installer or modify the current one. A lot of options have been moved out 
>of
>the config.inc.php file and into the database and I want to add
>Update|Uninstall|etc functionality.
>
>But right now it is more important that I get qcms back up and running. It
>isn't going excellent. Good news, my new, fully class based approach has
>somehow cut 600 Kb of memory overhead, so common.inc.php now only has 1.6 
>Mb
>memory used when it is done, much better than 3 weeks ago @ 2.2 Mb and 6
>weeks ago @ 3.1 Mb
>
>
>On 9/2/05, Pádraic Brady <mau...@ho...> wrote:
> >
> > A little evil is good...;)
> >
> > -|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-
> > Pádraic Brady
> >
> > aka Maugrim The Reaper
> > http://www.quantum-star.com/
> > http://www.shadowsrising.net/
> > -|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-
> >
> >
> >
> >
> > >From: Matt Mix <pro...@us...>
> > >To: sha...@li...
> > >Subject: [Shadowsrising-cvs]
> > shadowsrising/install/themes/Default/templates
> > >config_form_finish.tpl.html,1.1,NONE config_form.tpl.html,1.8,NONE
> > >location.tpl.html,1.1,NONE passwd_form.tpl.html,1.1,NONE
> > >server_install_bottom.tpl.html,1.1,NONE
> > >server_install_top.tpl.html,1.1,NONE 
>server_option_form.tpl.html,1.1,NONE
> > >system_message2.tpl.html,1.1,NONE
> > >Date: Fri, 02 Sep 2005 01:07:29 +0000
> > >
> > >Update of
> > >/cvsroot/shadowsrising/shadowsrising/install/themes/Default/templates
> > >In directory
> > >
> > 
>sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv26042/install/themes/Default/templates
> > >
> > >Removed Files:
> > > config_form_finish.tpl.html config_form.tpl.html
> > > location.tpl.html passwd_form.tpl.html
> > > server_install_bottom.tpl.html server_install_top.tpl.html
> > > server_option_form.tpl.html system_message2.tpl.html
> > >Log Message:
> > >this installer buisness is just evil, just evil
> > >
> > >
> > >--- system_message2.tpl.html DELETED ---
> > >
> > >--- config_form_finish.tpl.html DELETED ---
> > >
> > >--- location.tpl.html DELETED ---
> > >
> > >--- passwd_form.tpl.html DELETED ---
> > >
> > >--- server_option_form.tpl.html DELETED ---
> > >
> > >--- config_form.tpl.html DELETED ---
> > >
> > >--- server_install_top.tpl.html DELETED ---
> > >
> > >--- server_install_bottom.tpl.html DELETED ---
> > >
> > >
> > >
> > >-------------------------------------------------------
> > >SF.Net email is Sponsored by the Better Software Conference & EXPO
> > >September 19-22, 2005 * San Francisco, CA * Development Lifecycle
> > Practices
> > >Agile & Plan-Driven Development * Managing Projects & Teams * Testing &
> > QA
> > >Security * Process Improvement & Measurement * 
>http://www.sqe.com/bsce5sf
> > >_______________________________________________
> > >Shadowsrising-cvs mailing list
> > >Sha...@li...
> > >https://lists.sourceforge.net/lists/listinfo/shadowsrising-cvs
> >
> >
> >

Re: [Shadowsrising-devtalk] Catching up

[ProgrammerMatt <pro...@gm...>]

I will have a look at that article, looks interesting.

I new you would like my new class-based aproach to development, and from=20
what I understand from your description of the article, the article is righ=
t=20
up with what I am attempting to do. I knew I was commiting the qcms portion=
=20
of qsite too early, and now I pay for it :(. I have had a major programming=
=20
model change idea and a lot more of qsite is moving to classes. I am keepin=
g=20
most of it in qlib, so that core writers can, if they want, take advantage=
=20
of what I am writing. It is proving difficult though... A new qLib class=20
will be surfacing soon and the interfaces to the (multiple) cores will be=
=20
shownig up too. I finally figured out what was wrong with my session saved=
=20
classes!=20

More randomness:
I am currently looking into what is described as a revolutionary new=20
translation system using some sort of hashing function... I don't really=20
understand it, but it is supposed to be faster than other forms of=20
translation, most noteably the one that I am using right now :).=20
Blocks/Modules/Hacks/etc will now no longer be seperate, in compliance with=
=20
my 'new' approach, but class-based. If you are interested, it will take the=
=20
model of the modules in the bitweaver project.=20

That is all I can think of right now :).

Oh yeah, I will get the installer working soon... hopefully...

On 8/20/05, P=E1draic Brady <mau...@ho...> wrote:
>=20
> Hi all,
>=20
> Checking in to see how all goes in Q-Site and SR country.
>=20
> Few things:
>=20
> 1) I've started planning changes to the Shadows Rising game
> 2) I'm implementing similar changes in Quantum Star SE
> 3) I've had odd correspondance from two game developers (I think they are
> more "copyright" challengers - I swear they come out of the woodwork twic=
e=20
> a
> year).
>=20
> For 1 and 2 - I've made some simple but far reaching changes for the=20
> games.
> Basically I'm re-organising the classes into an Model-View-Controller
> pattern. So far it's worked really well for QS, and required relatively=
=20
> few
> changes (mainly its an exercise in cut and paste - with some editing). I'=
m
> going to use the same system for SR which should simplify development a=
=20
> fair
> bit.
>=20
> Ignore the copyright challenging ref - basically it was a note about some
> code in the CORE of SR. And a complaint about using a third-party library=
=20
> in
> QS. For reference neither was valid - one referred to similar but not
> identical code (basically we use two processes another person used - but=
=20
> the
> code is just completely different - so no issue. Another questioned
> compatibility of AGPL with LGPL - yet another misinformed question).
>=20
> A slightly more serious email was valid - I think I left some LOGD code i=
n
> SR somewhere along the way. It's not actually used but some of the code i=
s
> still present - so I'll be removing it soon just to be certain.
>=20
> I'm still studying for exams :(
>=20
> But I should get to SR during September after I make a quick release of a
> playable QS game. Looking forward to it.
>=20
>=20
> Matt if you get a chance let me know on how DB class is going. I'll check
> out the CVS version is its recent. Looks like it was a better idea than I
> thought after doing some work on QS in MVC.
>=20
> For those interested I have dropped to
> http://www.quantum-star.com/phpArchitect.zip a copy of all PHP Architect
> magazine issues from about December 05 to June 05 (July and Aug to=20
> follow).
> They're in PDF format. Password to access is 'certegra' (some earlier=20
> copies
> may use 'Certegra2819061' - an older password). There's a nice MVC Patter=
n
> article in the June issue which will explain a lot of what the OO Model i=
n
> SR and QS will be like soon. Hope they're of some interest ;)
>=20
>=20
> Keep in touch
>=20
> Later,
>=20
> Padraic
>=20
> -|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-
> P=E1draic Brady
>=20
> aka Maugrim The Reaper
> http://www.quantum-star.com/
> http://www.shadowsrising.net/
> -|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-
>=20
>=20
>=20
>=20
> -------------------------------------------------------
> SF.Net email is Sponsored by the Better Software Conference & EXPO
> September 19-22, 2005 * San Francisco, CA * Development Lifecycle=20
> Practices
> Agile & Plan-Driven Development * Managing Projects & Teams * Testing & Q=
A
> Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
> _______________________________________________
> Shadowsrising-devtalk mailing list
> Sha...@li...
> https://lists.sourceforge.net/lists/listinfo/shadowsrising-devtalk
>

[Shadowsrising-devtalk] Catching up

[Pádraic B. <mau...@ho...>]

Hi all,

Checking in to see how all goes in Q-Site and SR country.

Few things:

1) I've started planning changes to the Shadows Rising game
2) I'm implementing similar changes in Quantum Star SE
3) I've had odd correspondance from two game developers (I think they are 
more "copyright" challengers - I swear they come out of the woodwork twice a 
year).

For 1 and 2 - I've made some simple but far reaching changes for the games. 
Basically I'm re-organising the classes into an Model-View-Controller 
pattern. So far it's worked really well for QS, and required relatively few 
changes (mainly its an exercise in cut and paste - with some editing). I'm 
going to use the same system for SR which should simplify development a fair 
bit.

Ignore the copyright challenging ref - basically it was a note about some 
code in the CORE of SR. And a complaint about using a third-party library in 
QS. For reference neither was valid - one referred to similar but not 
identical code (basically we use two processes another person used - but the 
code is just completely different - so no issue. Another questioned 
compatibility of AGPL with LGPL - yet another misinformed question).

A slightly more serious email was valid - I think I left some LOGD code in 
SR somewhere along the way. It's not actually used but some of the code is 
still present - so I'll be removing it soon just to be certain.

I'm still studying for exams :(

But I should get to SR during September after I make a quick release of a 
playable QS game. Looking forward to it.


Matt if you get a chance let me know on how DB class is going. I'll check 
out the CVS version is its recent. Looks like it was a better idea than I 
thought after doing some work on QS in MVC.

For those interested I have dropped to 
http://www.quantum-star.com/phpArchitect.zip a copy of all PHP Architect 
magazine issues from about December 05 to June 05 (July and Aug to follow). 
They're in PDF format. Password to access is 'certegra' (some earlier copies 
may use 'Certegra2819061' - an older password). There's a nice MVC Pattern 
article in the June issue which will explain a lot of what the OO Model in 
SR and QS will be like soon. Hope they're of some interest ;)


Keep in touch

Later,

Padraic

-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-
Pádraic Brady

aka Maugrim The Reaper
http://www.quantum-star.com/
http://www.shadowsrising.net/
-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-

RE: [Shadowsrising-devtalk] Multiple Cores?

[Pádraic B. <mau...@ho...>]

Hi Matt,

First up, if you think multiple cores are workable then fire ahead. On a 
slightly context basis, I'm wondering whether we should shift references to 
'game' to 'app', e.g. gameID to appID. Basically the backend will be general 
enough not to be completely game specific (hopefully anyway). That last is a 
niggling little point anyways...

On the last - after actually going and trying out some AJAX integration, I'm 
back to requiring Javascript. Maybe I'll go through a JS optional phase 
again soon...;) My earlier point wasn't to move away from javascript but to 
enable the game to run without it as an absolute requirement (in that case 
those with JS would get more UI benefits, those without would get a lite 
version). Sorry if I gave the impression I was going to remove all 
javascript.

Currently in QS, I have two areas using AJAX (spec. xajax since you seem to 
be using that library). I'm still experimenting to an extent to set 
conditions in the source code so AJAX is only loaded when required 
(otherwise we'll take a processing hit even when not required - it's too 
heavy to be a basic include). I'll be testing JSpan soon for comparison.

I'm also experimenting with overLib and AJAX to allow dynamic popups - could 
be a useful element, e.g. to see a fleet's info, simply pass mouse over 
Fleet Name and a popup with the info would appear after an AJAX transaction. 
OverLib would be pre-loaded through Smarty.

As for IE and AJAX - IE from v6 should include ActiveX for the 
xmlhttprequest feature. Oddly, it was Microsoft who released its specs, so 
they certainly support it. It's one MS technology that you can't help but 
like...;). I doubt there's much trouble in that respect. Older v5 browsers 
would be a problem - but as I may have mentioned on my Blog some time ago, I 
have no intention on supporting older browsers - too much trouble and effort 
for little gain. The only concern in this respect is to ensure the AJAX in 
use is actually using xmlhttprequest since technically it's not the only 
option for enabling AJAX. I seriously doubt that's an issue, xmlhttprequest 
is the obvious choice for AJAX since it's supported by all the main 
browsers.

Later,

Padraic

-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-
Pádraic Brady

aka Maugrim The Reaper
http://www.quantum-star.com/
http://www.shadowsrising.net/
-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-

>From: ProgrammerMatt <pro...@gm...>
>Reply-To: ProgrammerMatt <pro...@gm...>
>To: sha...@li...
>Subject: [Shadowsrising-devtalk] Multiple Cores?
>Date: Fri, 22 Jul 2005 11:15:58 -0500
>
>Hey, I think this concept was wrapped up as a minor one I had in an email 
>or
>forum post a while ago (hard to seperate them these days), but anyway...
>
>Have you considered allowing that one backend qSite could host multiple
>cores? While I haven't worked out the technical details, I only see the 
>need
>to (as fit into my plans for qSite already) write an interface to determine
>what core a certain gameID is and then run interference for the core and
>qsite. This has a most immediate benifit of being able to host SR and QS at
>the same time if one desires. I don't think it would be too hard to set up
>and since I am already seperating the core from qsite in the most extensive
>way possible by providing interfaces that will allow communication between
>the core and qsite but no direct communication takes place other than
>inheritance of 'common.inc.php'. Cores would still be in the 'core' folder
>but inside folders (example /core/qs and /core/sr).
>
>Not deserving of a additional email...
>
>I know that you have expressed disinterest in using AJAX as people may not
>have javascript enabled and you were planning on eliminating all 
>javascript,
>including the login authentication and I was wondering why this highly
>secure feature was being earsed, as I will soon be rewriting the
>authentication class for optimizations and that interface to the core I
>mentioned earlier). The greater concern with AJAX is also with wether IE
>users have the ActiveX control needed (I still haven't figured out if it
>comes with IE). Anyway, I have been working out a way of client-side
>detection of javascript and output based on that or such. Anyway, assuming
>that it doesn't pan out and you have no other ideas of how to do that and 
>we
>decide to either go with AJAX or not I was wondering of the case of no if 
>we
>would still do the admin interface in AJAX even if the standard user 
>doesn't
>have AJAX support.
>
>Thanx,
>PM
>
>--
><a 
>href="http://www.spreadfirefox.com/?q=affiliates&amp;id=67508&amp;t=72"><img
>border="0" alt="Get Firefox!" title="Get Firefox!" src="
>http://sfx-images.mozilla.org/affiliates/Buttons/88x31/rediscover.gif"/></a>

[Shadowsrising-devtalk] Multiple Cores?

[ProgrammerMatt <pro...@gm...>]

Hey, I think this concept was wrapped up as a minor one I had in an email o=
r=20
forum post a while ago (hard to seperate them these days), but anyway...

Have you considered allowing that one backend qSite could host multiple=20
cores? While I haven't worked out the technical details, I only see the nee=
d=20
to (as fit into my plans for qSite already) write an interface to determine=
=20
what core a certain gameID is and then run interference for the core and=20
qsite. This has a most immediate benifit of being able to host SR and QS at=
=20
the same time if one desires. I don't think it would be too hard to set up=
=20
and since I am already seperating the core from qsite in the most extensive=
=20
way possible by providing interfaces that will allow communication between=
=20
the core and qsite but no direct communication takes place other than=20
inheritance of 'common.inc.php'. Cores would still be in the 'core' folder=
=20
but inside folders (example /core/qs and /core/sr).=20

Not deserving of a additional email...

I know that you have expressed disinterest in using AJAX as people may not=
=20
have javascript enabled and you were planning on eliminating all javascript=
,=20
including the login authentication and I was wondering why this highly=20
secure feature was being earsed, as I will soon be rewriting the=20
authentication class for optimizations and that interface to the core I=20
mentioned earlier). The greater concern with AJAX is also with wether IE=20
users have the ActiveX control needed (I still haven't figured out if it=20
comes with IE). Anyway, I have been working out a way of client-side=20
detection of javascript and output based on that or such. Anyway, assuming=
=20
that it doesn't pan out and you have no other ideas of how to do that and w=
e=20
decide to either go with AJAX or not I was wondering of the case of no if w=
e=20
would still do the admin interface in AJAX even if the standard user doesn'=
t=20
have AJAX support.

Thanx,
PM

--=20
<a href=3D"http://www.spreadfirefox.com/?q=3Daffiliates&amp;id=3D67508&amp;=
t=3D72"><img=20
border=3D"0" alt=3D"Get Firefox!" title=3D"Get Firefox!" src=3D"
http://sfx-images.mozilla.org/affiliates/Buttons/88x31/rediscover.gif"/></a=
>

Re: [Shadowsrising-devtalk] On AJAX

[ProgrammerMatt <pro...@gm...>]

Installer only so far, it was a test implementation and is not done yet.=20
Sure I will take those.

On 7/16/05, P=E1draic Brady <mau...@ho...> wrote:
>=20
> Hi Matt,
>=20
> Just looking for a quick overview on the AJAX implementation and where
> currently in use. I'm checking out QSite for a looksee - ;)
>=20
> I'll be back online about Sunday 10PM GMT.
>=20
> Also wondering if you're interested in reading the phpArchitect magazine?=
=20
> I
> have copies of the last year's issues (PDF) might be of some interest.
>=20
> -|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-
> P=E1draic Brady
>=20
> aka Maugrim The Reaper
> http://www.quantum-star.com/
> http://www.shadowsrising.net/
> -|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-
>=20
>=20
>=20
>=20
>

[Shadowsrising-devtalk] On AJAX

[Pádraic B. <mau...@ho...>]

Hi Matt,

Just looking for a quick overview on the AJAX implementation and where 
currently in use. I'm checking out QSite for a looksee - ;)

I'll be back online about Sunday 10PM GMT.

Also wondering if you're interested in reading the phpArchitect magazine? I 
have copies of the last year's issues (PDF) might be of some interest.

-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-
Pádraic Brady

aka Maugrim The Reaper
http://www.quantum-star.com/
http://www.shadowsrising.net/
-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-



>From: ProgrammerMatt <pro...@gm...>
>Reply-To: ProgrammerMatt <pro...@gm...>
>To: sha...@li...
>Subject: Re: [Shadowsrising-devtalk] Memory Footprints
>Date: Fri, 15 Jul 2005 15:33:35 -0500
>
>Memory footprinting is not a huge concern anymore, especially if ADODBlite
>and Smarty lite work out for us. I have, as you know, begun an extensive
>rewrite of portions of the codebase of Q-Site. Things have changed and
>anything not absolutely needed every time is no lonnger included. I will
>continue in optimization as long as I can. So far I have dropped average
>requirements for a page load from ~3.3 Mb to ~2.1 Mb (without ADODB lite or
>SMARTY lite) . Also, ADODB does not just take up 500 Kb, but with our
>functions it took up 1700 Kb. That was greatly decreased when I took a new
>approach to our DB, one that is overall, I think, more organized and
>definatly less memory consumption. The DB functions are no more, instead I
>have written a class that is still in the early stages, but has preformed
>better and at a lower memory cost than the old ones did. I believe I
>commited it to Q-Site last night, but note that Q-Site will not work out of
>CVS yet as qcms hasen't even been worked on to comply or take the
>optimizations I have planned for it.
>
>On 7/15/05, Pádraic Brady <mau...@ho...> wrote:
> >
> > Hey all,
> >
> > Sry for not being on the SR forums regular (exam study keeping me busy).
> > This is in response to a message from Matt on the Solar Empire Global
> > forum
> > (which Quantum Star SE is affiliated with - our sister project).
> >
> > Matt,
> >
> > I noted in one of your messages that you were concerned about memory use
> > of
> > an addition you were making to QSite. The fact is memory uptake can
> > severely
> > effect any web application on a shared host - even on most affordable
> > dedicated servers.
> >
> > I'm not recommending you cease and desist ;) I actually urge you to go
> > ahead
> > and we can view the results (me in Aug/Sep when I have the time) - but 
>do
> > reduce memory usage if possible, no need to go overboard to the point
> > where
> > the changes are impossible, memory is there to be used if its needed, so
> > blow it if its necessary to get it working.
> >
> > There were some changes I have in planning to reduce overall memory
> > footprint substantially. These are sourced in two projects, one
> > attributable
> > to the performance junkies of the Alien Assault Traders project. These 
>are
> > basically 'lite' versions of ADODB and Smarty.
> >
> > I have yet to look at Smarty Lite, but ADODB Lite has shown on 
>benchmarks
> > to
> > use about 18% of the memory of ADODB, with a resulting reduction in
> > response
> > lag - so do take a look at implementing it -
> > http://adodblite.sourceforge.net/
> >
> > I'll be doing so during this week for QS - so maybe I'll post the 
>updated
> > db_funcs library soon. I'm not sure whether it supports all our needed
> > ADODB
> > features, as a lite version it cuts out a lot of the less commonly used
> > features to reduce memory use. Maybe I'll even get the DB library 
>restated
> > and tidied up a little - though I'd prefer to that on your working copy
> > with
> > any changes you may have made more recently.
> >
> > Implementing Smarty Lite would see a similar performance improvement I'm
> > sure.
> >
> > Just letting know these are out there, and will keep our memory use as 
>low
> > as possible. I think ADODB by itself hits well over 500KB, getting that
> > down
> > below 200KB is quite an improvement in the scheme of things... Smarty is 
>a
> > similar memory hog.
> >
> > I'll be on ICQ about 22:00 GMT if about at that time.
> >
> > Later,
> >
> > Padraic
> >
> > -|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-
> > Pádraic Brady
> >
> > aka Maugrim The Reaper
> > http://www.quantum-star.com/
> > http://www.shadowsrising.net/
> > -|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-
> >
> >
> >
> >
> > -------------------------------------------------------
> > SF.Net <http://SF.Net> email is sponsored by: Discover Easy Linux
> > Migration Strategies
> > from IBM. Find simple to follow Roadmaps, straightforward articles,
> > informative Webcasts and more! Get everything you need to get up to
> > speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
> > _______________________________________________
> > Shadowsrising-devtalk mailing list
> > Sha...@li...
> > https://lists.sourceforge.net/lists/listinfo/shadowsrising-devtalk
> >
>
>
>
>--
><a 
>href="http://www.spreadfirefox.com/?q=affiliates&amp;id=67508&amp;t=72"><img
>border="0" alt="Get Firefox!" title="Get Firefox!" src="
>http://sfx-images.mozilla.org/affiliates/Buttons/88x31/rediscover.gif"/></a>

Re: [Shadowsrising-devtalk] Memory Footprints

[ProgrammerMatt <pro...@gm...>]

Looked at ADODB Lite, and I don't think it anywhere nearly suites our neads=
.=20
Unless you want to drop Perfmon and DB backed sessions and they added=20
$result->FetchRow for me.

Adodb with Perfmon Use ~1302Kb
Adodb uses ~977 Kb

Re: [Shadowsrising-devtalk] Memory Footprints

[ProgrammerMatt <pro...@gm...>]

Memory footprinting is not a huge concern anymore, especially if ADODBlite=
=20
and Smarty lite work out for us. I have, as you know, begun an extensive=20
rewrite of portions of the codebase of Q-Site. Things have changed and=20
anything not absolutely needed every time is no lonnger included. I will=20
continue in optimization as long as I can. So far I have dropped average=20
requirements for a page load from ~3.3 Mb to ~2.1 Mb (without ADODB lite or=
=20
SMARTY lite) . Also, ADODB does not just take up 500 Kb, but with our=20
functions it took up 1700 Kb. That was greatly decreased when I took a new=
=20
approach to our DB, one that is overall, I think, more organized and=20
definatly less memory consumption. The DB functions are no more, instead I=
=20
have written a class that is still in the early stages, but has preformed=
=20
better and at a lower memory cost than the old ones did. I believe I=20
commited it to Q-Site last night, but note that Q-Site will not work out of=
=20
CVS yet as qcms hasen't even been worked on to comply or take the=20
optimizations I have planned for it.=20

On 7/15/05, P=E1draic Brady <mau...@ho...> wrote:
>=20
> Hey all,
>=20
> Sry for not being on the SR forums regular (exam study keeping me busy).
> This is in response to a message from Matt on the Solar Empire Global=20
> forum
> (which Quantum Star SE is affiliated with - our sister project).
>=20
> Matt,
>=20
> I noted in one of your messages that you were concerned about memory use=
=20
> of
> an addition you were making to QSite. The fact is memory uptake can=20
> severely
> effect any web application on a shared host - even on most affordable
> dedicated servers.
>=20
> I'm not recommending you cease and desist ;) I actually urge you to go=20
> ahead
> and we can view the results (me in Aug/Sep when I have the time) - but do
> reduce memory usage if possible, no need to go overboard to the point=20
> where
> the changes are impossible, memory is there to be used if its needed, so
> blow it if its necessary to get it working.
>=20
> There were some changes I have in planning to reduce overall memory
> footprint substantially. These are sourced in two projects, one=20
> attributable
> to the performance junkies of the Alien Assault Traders project. These ar=
e
> basically 'lite' versions of ADODB and Smarty.
>=20
> I have yet to look at Smarty Lite, but ADODB Lite has shown on benchmarks=
=20
> to
> use about 18% of the memory of ADODB, with a resulting reduction in=20
> response
> lag - so do take a look at implementing it -
> http://adodblite.sourceforge.net/
>=20
> I'll be doing so during this week for QS - so maybe I'll post the updated
> db_funcs library soon. I'm not sure whether it supports all our needed=20
> ADODB
> features, as a lite version it cuts out a lot of the less commonly used
> features to reduce memory use. Maybe I'll even get the DB library restate=
d
> and tidied up a little - though I'd prefer to that on your working copy=
=20
> with
> any changes you may have made more recently.
>=20
> Implementing Smarty Lite would see a similar performance improvement I'm
> sure.
>=20
> Just letting know these are out there, and will keep our memory use as lo=
w
> as possible. I think ADODB by itself hits well over 500KB, getting that=
=20
> down
> below 200KB is quite an improvement in the scheme of things... Smarty is =
a
> similar memory hog.
>=20
> I'll be on ICQ about 22:00 GMT if about at that time.
>=20
> Later,
>=20
> Padraic
>=20
> -|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-
> P=E1draic Brady
>=20
> aka Maugrim The Reaper
> http://www.quantum-star.com/
> http://www.shadowsrising.net/
> -|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-
>=20
>=20
>=20
>=20
> -------------------------------------------------------
> SF.Net <http://SF.Net> email is sponsored by: Discover Easy Linux=20
> Migration Strategies
> from IBM. Find simple to follow Roadmaps, straightforward articles,
> informative Webcasts and more! Get everything you need to get up to
> speed, fast. http://ads.osdn.com/?ad_id=3D7477&alloc_id=3D16492&op=3Dclic=
k
> _______________________________________________
> Shadowsrising-devtalk mailing list
> Sha...@li...
> https://lists.sourceforge.net/lists/listinfo/shadowsrising-devtalk
>=20



--=20
<a href=3D"http://www.spreadfirefox.com/?q=3Daffiliates&amp;id=3D67508&amp;=
t=3D72"><img=20
border=3D"0" alt=3D"Get Firefox!" title=3D"Get Firefox!" src=3D"
http://sfx-images.mozilla.org/affiliates/Buttons/88x31/rediscover.gif"/></a=
>

[Shadowsrising-devtalk] Memory Footprints

[Pádraic B. <mau...@ho...>]

Hey all,

Sry for not being on the SR forums regular (exam study keeping me busy). 
This is in response to a message from Matt on the Solar Empire Global forum 
(which Quantum Star SE is affiliated with - our sister project).

Matt,

I noted in one of your messages that you were concerned about memory use of 
an addition you were making to QSite. The fact is memory uptake can severely 
effect any web application on a shared host - even on most affordable 
dedicated servers.

I'm not recommending you cease and desist ;) I actually urge you to go ahead 
and we can view the results (me in Aug/Sep when I have the time) - but do 
reduce memory usage if possible, no need to go overboard to the point where 
the changes are impossible, memory is there to be used if its needed, so 
blow it if its necessary to get it working.

There were some changes I have in planning to reduce overall memory 
footprint substantially. These are sourced in two projects, one attributable 
to the performance junkies of the Alien Assault Traders project. These are 
basically 'lite' versions of ADODB and Smarty.

I have yet to look at Smarty Lite, but ADODB Lite has shown on benchmarks to 
use about 18% of the memory of ADODB, with a resulting reduction in response 
lag - so do take a look at implementing it - 
http://adodblite.sourceforge.net/

I'll be doing so during this week for QS - so maybe I'll post the updated 
db_funcs library soon. I'm not sure whether it supports all our needed ADODB 
features, as a lite version it cuts out a lot of the less commonly used 
features to reduce memory use. Maybe I'll even get the DB library restated 
and tidied up a little - though I'd prefer to that on your working copy with 
any changes you may have made more recently.

Implementing Smarty Lite would see a similar performance improvement I'm 
sure.

Just letting know these are out there, and will keep our memory use as low 
as possible. I think ADODB by itself hits well over 500KB, getting that down 
below 200KB is quite an improvement in the scheme of things... Smarty is a 
similar memory hog.

I'll be on ICQ about 22:00 GMT if about at that time.

Later,

Padraic

-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-
Pádraic Brady

aka Maugrim The Reaper
http://www.quantum-star.com/
http://www.shadowsrising.net/
-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-

RE: [Shadowsrising-devtalk] phpDocumentor

[Pádraic B. <mau...@ho...>]

Whew,

Been so busy I haven't even checked this email in a few weeks (on study 
leave for exams until August).

Yeah I'm aware of it. If you want to use the application and markup in the 
files work away - I've actually done a few of the newer files in Quantum 
Star SE using the phpDoc syntax (see the class files - some of which were 
done in the pre-alpha). So yeah, I do plan on eventually using it more 
widely - makes the code more readable overall, and then simple to pull 
together a quick API document for distribution.

The other side of documentation (the more textual focused tracts) will rely 
on the DocBook XML schema (a very simple format), and similar to 
phpDocumentor can allow the documentation to be exported to CHM, HTML etc. 
DocBook also supports PDF exports which is a nice benefit.

Tiem for me to run now and jump headfirst into more study - mock 
examinations are starting tomorrow to warm us up for the real thing in 
August..:)

later,

Padraic

-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-
Pádraic Brady

aka Maugrim The Reaper
http://www.quantum-star.com/
http://www.shadowsrising.net/
-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-



>From: ProgrammerMatt <pro...@gm...>
>Reply-To: ProgrammerMatt <pro...@gm...>
>To: sha...@li...
>Subject: [Shadowsrising-devtalk] phpDocumentor
>Date: Tue, 21 Jun 2005 18:32:33 -0500
>
>Have you considered using phpDocumentor to document our code, it seems
>highly versatile and worthwhile.
>
>Here is a link to the documentation methods
>http://manual.phpdoc.org/HTMLSmartyConverter/HandS/phpDocumentor/tutorial_phpDocumentor.howto.pkg.html
>
>--
><a 
>href="http://www.spreadfirefox.com/?q=affiliates&amp;id=67508&amp;t=72"><img
>border="0" alt="Get Firefox!" title="Get Firefox!" src="
>http://sfx-images.mozilla.org/affiliates/Buttons/88x31/rediscover.gif"/></a>

Re: [Shadowsrising-devtalk] What have I done?!?

[ProgrammerMatt <pro...@gm...>]

Okay, new update.

First off, where have you been? Kinda fallen out of contact.

Second, I have started implementing phpDocumentor functions for two reasons=
.=20
1: It doesn't hurt 2: If we decide to use phpDocumentor they will be in=20
place. They are overall good descriptors of what a function can do with an=
=20
'autodoc' air to them.=20

Finally, I was thinking more on the whole modular game thing. This is what =
I=20
am thinking:

You said that we couldn't name the tables generically because fields might=
=20
change and such. It hit me the other day that those tables would still=20
remain extremely static. So, I think it might be advisable to start thinkin=
g=20
about putting them in something similar to 'ini' files (php has a built-in=
=20
function for reading them, and they aren't very hard to make them) and have=
=20
the module makers make their own dirs or similar with the ini files they=20
need in them. This just hit me a moment ago and I am in the middle of=20
programming so this idea isn't very developed nor thought out, but the=20
greates benifit would be a global `characters` table, which is what would b=
e=20
somewhat helpful. Any thoughts on this idea?

[Shadowsrising-devtalk] phpDocumentor

[ProgrammerMatt <pro...@gm...>]

Have you considered using phpDocumentor to document our code, it seems=20
highly versatile and worthwhile.

Here is a link to the documentation methods
http://manual.phpdoc.org/HTMLSmartyConverter/HandS/phpDocumentor/tutorial_p=
hpDocumentor.howto.pkg.html

--=20
<a href=3D"http://www.spreadfirefox.com/?q=3Daffiliates&amp;id=3D67508&amp;=
t=3D72"><img=20
border=3D"0" alt=3D"Get Firefox!" title=3D"Get Firefox!" src=3D"
http://sfx-images.mozilla.org/affiliates/Buttons/88x31/rediscover.gif"/></a=
>

Re: [Shadowsrising-devtalk] What have I done?!?

[Pádraic B. <mau...@ho...>]

Matt,

Thanks for the update - currently hip deep in a 2000 page reference volume 
on "International Financial Reporting Standards". It's painful...very 
painful...;)

On translations - the core segment (ie the game) was going to utilise a 
sub-template directory. So you would have templates_en, templates_fr, etc. I 
want to avoid the extra-processing imposed by line for line parsing to 
replace lines with translated versions.

The game engine already uses a fairly standard set of Constants to hold 
language values for text in the PHP.

Sole exception would be database content, which would have to be parsed. The 
good side, is that parsing would be performed only on the Smarty variable 
which holds all template variable values. It would not be performed over a 
long file of HTML and text. Should be pretty fast with a simple function. 
This and the template sub-divisions have not been set up yet (it was one of 
those low priority gigs while the game was pre-alpha). Probably I'll set it 
up for QS soon-ish. So may port it at that time.

Something similar might work for the backend/frontend. But I don't mind 
experimenting with something different - I don't have a monopoly on good 
ideas...:) My main concern in the game was speed - so I sacrificed 
simplicity and will be adding a more complex system that should be a lot 
faster (since only needs to parse tempate variables for database content).

I agree Flash is of limited use. It might be useable somewhere but there 
would to be a strong case for it. I can't see it being used to wrap any 
functional elements - that would add a dependency on Flash and I have this 
habit of surfing the web from a remote server using Lynx (much faster when 
you want text, not images and other "extras" - my main connection is too far 
from my local exchange to enable broadband).

Even the current dependency on javascript is but a temporary 
situation...shouldn't need more than the minimum to play the game with JS 
being a bonus for users etc.

AJAX work in any case is largely Theme dependent - the PHP side can be 
handled by a separate class.

On languages - any settings should lead us at some stage to the standard en, 
fr, es references (in turn used in directory and file names). One thing I 
really need to look at in the future is internationalising. I know most 
files specify UTF-8 as the character type - but in reality most are an ISO 
set. This could be a real pain for anyone using a non-roman character set. 
It may be a simple process, but I've never had to delve into this before...

Some maybe good news is that I have started creating clan functionality for 
QS. It's being designed as a "Shared Clan Module" (a fancy name for a new 
directory ;)) but the overall effect should be that it will be easily 
portable to Shadows Rising. It's going to be a lot different than the usual 
QS implementation - doing this from scratch lets me add in a lot more useful 
features. It will require access to a clan forum - so I might package with a 
flat forum until you get to look into that at some stage.

I think our learning curve on these PHP games is starting to level off ;)

Later,

Padraic


-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-
Pádraic Brady

aka Maugrim The Reaper
http://www.quantum-star.com/
http://www.shadowsrising.net/
-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-



>From: ProgrammerMatt <pro...@gm...>
>Reply-To: ProgrammerMatt <pro...@gm...>
>To: sha...@li...
>Subject: Re: [Shadowsrising-devtalk] What have I done?!?
>Date: Fri, 17 Jun 2005 15:30:34 -0500
>
>Okay, new updates. I am feeling up for a good, long post here.
>
>First, I have 2 prospective devs that I am actively engaged in talking to.
>One is a flash/PHP coder, but at this time we have (I believe) little need
>for any flash in our game. With AJAX and our current 'roadmap' I do not see
>any need for flash, but I think him to be competent in PHP so we shall see.
>The other is a German (from Munich). His English isn't great, but he is
>easily able to communicate. The biggest benefit that I can see coming from
>him is a German translation (started adding something more complicated for
>languages, similar to phpBB's method. changes coming here as I took a step
>back to look at long-term plans for SR while being forced to paint my house
>:().
>
>I have, as you probably have noticed, another developer by whose name
>currently escapes me and I am just too lazy to look it up. He has dropped
>out of contact for awhile so I sent an email checking up with him. I hope 
>to
>see contributions coming from him soon. UPDATE: His mother was admitted to
>the hospital and he has been looking after her.
>
>I was wondering again at the many other devs that are assigned to this
>project and was hoping for some form of a status on them. I have no
>intention of cutting them out as I know they were very active in early
>theory and design and much of what we have comes from them, but I was just
>wondering why they seemed to have dropped out.
>
>As for a nice status update, today I plan to move some files around, change
>a core concept of the permission system, and change how forums will be
>handled completely. The old, independent file method, as I see it now, was 
>a
>bad choice. Instead, new files will be added to the back end with functions
>like 'draw_forum' and 'draw_forum_at'. Then, for displaying the forums,
>files with names like 'viewtopic' and 'viewforum' will be put into 'core/'
>and 'qcms/' and will serve as wrappers for those functions. A moderator
>control panel and user control panel will be handled similarly.
>
>As to the core concept change of the permission system. First, as opposed 
>to
>being read from a file, the permissions will be instead read from the DB.
>Permissions will switch to lower case with prefixes 'f_' (forum perms) 'g_'
>(game perms) 'c_' (cms perms) 'u_' (user perms) 'a_' (admin perms). Each
>category will also have a 'hidden' permission written as the prefix (for
>example, 'a_' will be its own permission). This 'hidden' permission will be
>a toggle if any of the 'child' permissions are 'yes', then the toggle will
>be 'yes'. This way we can easier deduce control panel stuff.
>
>In addition, the *_can functions of the permission system will no longer
>return the permissions, but the $simple flag is being enforced so that it
>only returns true/false. This is because I have yet to see any application
>of receiving the permission back. If it is needed later, a new function
>*_get() will be added that will serve the same purpose as the *_can
>functions serves right now without the $simple flag. Don't see it needed
>though.
>
>The multi-lingual functionality is still being hotly debated in my head as
>to determine the best way of going about this. I want it to be accessible 
>to
>the templates so that every single string that is displayed to the user can
>be translated. These 'words' will be saved in language files, that to save
>on memory I think will be dynamically loaded as needed.
>
>If it hasn't been noticed by now, there is now a Q_user class. This will
>handle things like user data and user preferences. It was a possible host 
>of
>the language system (code is there still), but as I already said I am still
>trying to decide the best way to do this.
>
>As an addend to our potential flash/php programmer. If we wanted later on 
>we
>could instate 'actual' 'realtime' player vs player battles. I don't think
>flash is a good idea for most fighting, but p vs p might be worthwhile
>looking into. Of course with AJAX, we could probably work it out to. Though
>this stuff is far from where I am dedicated to working on so no decisions
>are coming from me concerning this.

Re: [Shadowsrising-devtalk] What have I done?!?

[ProgrammerMatt <pro...@gm...>]

Okay, new updates. I am feeling up for a good, long post here.

First, I have 2 prospective devs that I am actively engaged in talking to.=
=20
One is a flash/PHP coder, but at this time we have (I believe) little need=
=20
for any flash in our game. With AJAX and our current 'roadmap' I do not see=
=20
any need for flash, but I think him to be competent in PHP so we shall see.=
=20
The other is a German (from Munich). His English isn't great, but he is=20
easily able to communicate. The biggest benefit that I can see coming from=
=20
him is a German translation (started adding something more complicated for=
=20
languages, similar to phpBB's method. changes coming here as I took a step=
=20
back to look at long-term plans for SR while being forced to paint my house=
=20
:().

I have, as you probably have noticed, another developer by whose name=20
currently escapes me and I am just too lazy to look it up. He has dropped=
=20
out of contact for awhile so I sent an email checking up with him. I hope t=
o=20
see contributions coming from him soon. UPDATE: His mother was admitted to=
=20
the hospital and he has been looking after her.=20

I was wondering again at the many other devs that are assigned to this=20
project and was hoping for some form of a status on them. I have no=20
intention of cutting them out as I know they were very active in early=20
theory and design and much of what we have comes from them, but I was just=
=20
wondering why they seemed to have dropped out.

As for a nice status update, today I plan to move some files around, change=
=20
a core concept of the permission system, and change how forums will be=20
handled completely. The old, independent file method, as I see it now, was =
a=20
bad choice. Instead, new files will be added to the back end with functions=
=20
like 'draw_forum' and 'draw_forum_at'. Then, for displaying the forums,=20
files with names like 'viewtopic' and 'viewforum' will be put into 'core/'=
=20
and 'qcms/' and will serve as wrappers for those functions. A moderator=20
control panel and user control panel will be handled similarly.

As to the core concept change of the permission system. First, as opposed t=
o=20
being read from a file, the permissions will be instead read from the DB.=
=20
Permissions will switch to lower case with prefixes 'f_' (forum perms) 'g_'=
=20
(game perms) 'c_' (cms perms) 'u_' (user perms) 'a_' (admin perms). Each=20
category will also have a 'hidden' permission written as the prefix (for=20
example, 'a_' will be its own permission). This 'hidden' permission will be=
=20
a toggle if any of the 'child' permissions are 'yes', then the toggle will=
=20
be 'yes'. This way we can easier deduce control panel stuff.

In addition, the *_can functions of the permission system will no longer=20
return the permissions, but the $simple flag is being enforced so that it=
=20
only returns true/false. This is because I have yet to see any application=
=20
of receiving the permission back. If it is needed later, a new function=20
*_get() will be added that will serve the same purpose as the *_can=20
functions serves right now without the $simple flag. Don't see it needed=20
though.=20

The multi-lingual functionality is still being hotly debated in my head as=
=20
to determine the best way of going about this. I want it to be accessible t=
o=20
the templates so that every single string that is displayed to the user can=
=20
be translated. These 'words' will be saved in language files, that to save=
=20
on memory I think will be dynamically loaded as needed.

If it hasn't been noticed by now, there is now a Q_user class. This will=20
handle things like user data and user preferences. It was a possible host o=
f=20
the language system (code is there still), but as I already said I am still=
=20
trying to decide the best way to do this.=20

As an addend to our potential flash/php programmer. If we wanted later on w=
e=20
could instate 'actual' 'realtime' player vs player battles. I don't think=
=20
flash is a good idea for most fighting, but p vs p might be worthwhile=20
looking into. Of course with AJAX, we could probably work it out to. Though=
=20
this stuff is far from where I am dedicated to working on so no decisions=
=20
are coming from me concerning this.

[Shadowsrising-devtalk] Ranting about Modules and Instances

[ProgrammerMatt <pro...@gm...>]

Wow, I always thought I would just leave this subject and make workarounds=
=20
for it, but in recent coding that is being made especially difficult.=20
Anyway; first the reason behind this rant: the module and instance tables=
=20
all a have their separate names and each complete module will add more=20
tables to the DB because of the current structure and the instance is hard=
=20
to search through.

Here is an example (cause I have been pretty non-coherent so far): In my=20
'Find User' Module (coming soon to function!) in the aPannel, it is very=20
easy for it to search through users_accounts because, well there is only on=
e=20
concerned table. If I want to search through a specific game, I first must=
=20
find the instance/module that the game is to be able to search through its=
=20
table. This seems to add an additional query to the whole mix that could be=
=20
relatively avoided. There are other places where the=20
{modulename}_{instancename}_characters comes to be an annoyance, just can't=
=20
remember them because my best coding occurs at night and I tend to be too=
=20
drowsy in the morning to do this kind of thing.

My proposal up for consideration: add links similiar to my groups/users/etc=
=20
methods so far. For example, have one table `items_keys` (made up), and hav=
e=20
its structure like this:
`id` int(11) NOT NULL default auto_increment,
`key_name` varchar(15) NOT NULL default '',
`modifier` varchar(15 NOT NULL default '',
`module_id` int(11) or `module` varchar(30)

This allows the modules to be stored in one `items_keys` instead of a bunch=
=20
of {modulename}_item_keys that would be relatively difficult to sort out,=
=20
especially from an administrative prespective. This will also drastically=
=20
cut down on the ammount of tables we have.

The characters would be modified with only one additional field:
`instance_id` int(11)
As the module can easily be linked by the instance_id in a sql query becaus=
e=20
these will all be indexed in another table (all modules and instances).=20

I hope you get what I am saying.

--=20
<a href=3D"http://www.spreadfirefox.com/?q=3Daffiliates&amp;id=3D67508&amp;=
t=3D72"<http://www.spreadfirefox.com/?q=3Daffiliates&amp;id=3D67508&amp;t=
=3D72%22>><img
border=3D"0" alt=3D"Get Firefox!" title=3D"Get Firefox!" src=3D"
http://sfx-images.mozilla.org/affiliates/Buttons/88x31/rediscover.gif"/<htt=
p://sfx-images.mozilla.org/affiliates/Buttons/88x31/rediscover.gif%22/>
></a>

Re: [Shadowsrising-devtalk] Shadows Rising 0.0.6

[Pádraic B. <mau...@ho...>]

Hope you find one...;)

On AJAX - the term was coined earlier this year. Since the concept brings 
together for the first time in a "cohesive" framework the Javascript, 
xmlhttprequest, and DHTML fields, and since we're in a period where 
javascript and xmlhttprequest are now implemented in a near standard way 
across almost all browsers (IE's xmlhttprequest requires ActiveX - so 
disabled in some cases), and since there are now a lot of professionals 
working out the kinks in AJAX since March - seems like a good time to start 
working with it.

There are not a lot of tutorials out there - given AJAX is very young as a 
framework. There are a few toolkits for it. My current favourite is JPSpan 
(they have examples - and see http://www.ajaxblog.com ) which I think will 
make Q-Site - primarily because the developer is one the few thus far to 
actually go and solve two of AJAX's primary problems - 1) that the delay 
between request and response can be from a few seconds to a minute depending 
on server load (and the user may think of doing something else during that 
delay - causing all sorts of havok), 2) that two requests can be issued, and 
the response may return in any order (so some sort of queuing or 
single-request-only rule needed to be implemented).

Using CSS starts as very unintuitive. It's also very difficult *if* you 
insist on using IE. I think this is still one of its major blocks. For 
example, QS will need to be reviewed when IE7 goes mainstream - because of 
several IE cheats it uses to force IE to display properly.

But it does make sense after the first tutorial or too - especially when you 
start seeing how to replace tables with "positioned" DIV sections. I would 
suggest grabbing the QS3 pre-alpha and looking at the location page template 
(location.tpl2.html - not tpl ) and CSS file. The design uses minimal tables 
for data - the overall page is composed of multiple standard IDed DIV 
elements.

As a result the page has stuff like:

<div id="pagedata_sub_container">

	<div class="universemap_block">
		// uni map
	</div>

	<div class="data_block">
		// some data
	</div>

</div>

No tables for basic structure.

CSS:

# indicates a unique id - only one per page (because of absolute positioning 
- two would createoverlapping layers - one beneath the other)
. indicated a class - can be many instances per page

div#pagedata_sub_container {
	position: absolute;	// absolute position
	right: 0px;		   // position 0px from right margin
	margin-right: 0px;	// right margin is 0px
	width: 200px;		// div element is 200px in width extending from right margin
}

div.data_block {
	position: relative;			// relative, each new instance
	width: auto;				// like giving no width to table cell - uses full width
	margin: 0px 0px 20px 0px;	// margin of 20px to bottom (spacing between new 
data_blocks)
	background-color: #08253b;
	border: solid 1px #777777;
	padding: 10px;
	z-index: 3;				// z-index of 3 - if elements overlap, set order of 
overlapping
}


Thought I'd throw that in since it will be ported to SR eventually - loads 
faster than a tables only layout. Full style has 7 "block" styles, 8 
"containers" styles, etc.

Rambling again...;)

Later,

Paidi

-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-
Pádraic Brady

aka Maugrim The Reaper
http://www.quantum-star.com/
http://www.shadowsrising.net/
-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-



>From: ProgrammerMatt <pro...@gm...>
>Reply-To: ProgrammerMatt <pro...@gm...>
>To: sha...@li...
>Subject: Re: [Shadowsrising-devtalk] Shadows Rising 0.0.6
>Date: Sun, 5 Jun 2005 11:47:14 -0500
>
>Alright, I am going to take a stab at getting another dev on the team, but
>if history is any indication they are most likely never to work on the
>project except for maybe the first week they are on the team. Story of
>getting active developers on sourceforge :). I am not going to touch the
>developers already on the project because I joined rather late and have had
>little interaction with them so have no idea what you want to do with them.
>
>I think I am going to take a new approach to recruitment by requiring them
>to submit a 20+ line or so patch or code addon with their development
>application. It could be anything they want it to be or maybe 20 one line
>bug-fixes. This cuts out the non-serious programmers and requires them to
>actually know a bit about the code before applying. Also, you can tell a 
>lot
>about a developer by looking at his code and how they submit the patch: 
>will
>the use the diff utility or include the code as the whole revised file or
>will they show the modified code with file/line number? I would prefer the
>diff. They of course will be allowed to submit their patch to cvs upon
>acceptance so that their name is attached to it.
>
>I can't wait to see your AJAX implementation, I have been trying to find a
>good, basic tutorial, but so far that has eluded me. A chat sounds like a
>good idea, much better than a shoutbox and will cut down on spamming in the
>forums :).
>
>After I posted that I didn't like HTML design and such I happened about a
>nice tutorial on CSS design and think I will take a stab at using <div> and
><span> as opposed to <table> because I hear <table> is becoming obsolete.
>Don't want to be behind the curve!

Re: [Shadowsrising-devtalk] Shadows Rising 0.0.6

[ProgrammerMatt <pro...@gm...>]

Alright, I am going to take a stab at getting another dev on the team, but=
=20
if history is any indication they are most likely never to work on the=20
project except for maybe the first week they are on the team. Story of=20
getting active developers on sourceforge :). I am not going to touch the=20
developers already on the project because I joined rather late and have had=
=20
little interaction with them so have no idea what you want to do with them.

I think I am going to take a new approach to recruitment by requiring them=
=20
to submit a 20+ line or so patch or code addon with their development=20
application. It could be anything they want it to be or maybe 20 one line=
=20
bug-fixes. This cuts out the non-serious programmers and requires them to=
=20
actually know a bit about the code before applying. Also, you can tell a lo=
t=20
about a developer by looking at his code and how they submit the patch: wil=
l=20
the use the diff utility or include the code as the whole revised file or=
=20
will they show the modified code with file/line number? I would prefer the=
=20
diff. They of course will be allowed to submit their patch to cvs upon=20
acceptance so that their name is attached to it.

I can't wait to see your AJAX implementation, I have been trying to find a=
=20
good, basic tutorial, but so far that has eluded me. A chat sounds like a=
=20
good idea, much better than a shoutbox and will cut down on spamming in the=
=20
forums :).

After I posted that I didn't like HTML design and such I happened about a=
=20
nice tutorial on CSS design and think I will take a stab at using <div> and=
=20
<span> as opposed to <table> because I hear <table> is becoming obsolete.=
=20
Don't want to be behind the curve!

RE: [Shadowsrising-devtalk] What have I done?!?

[Pádraic B. <mau...@ho...>]

Hi Matt,

Will have to look at some stage during the week - need a faster connection 
to grab the CVS at the moment. Even this is taking minutes at a time to load 
a hotmail page...:(

It's a wonder this PC even works anymore (it's circa 1994 - though Linux 
doesn't appear to mind thankfully). My usual station of operations is having 
second thoughts about its existence - I think the drive has probably gone 
tail up - either that or I need to install a bootloader. Once again a modern 
HD has (probably) failed - while my 512MB backup just keeps rolling. I love 
that hard disk. 11 years old and it has never once spat, hissed or failed. 
It makes a really loud clicking noise when working - but it does work...;)

Back on topic...

It's something to think about, you're right. I think at the moment 
everything in-game is handled through the usual checks, ending with a 
SystemMessage() - this is in the game engine. Probably in that generic print 
file (one of the few generic files in the game directory sets). But nothing 
for cms/backend

If it works, it works...;) You're doing most of the application side work 
for the backend at the moment - so I'm not arguing...

Paidi.

-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-
Pádraic Brady

aka Maugrim The Reaper
http://www.quantum-star.com/
http://www.shadowsrising.net/
-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-


>From: ProgrammerMatt <pro...@gm...>
>Reply-To: ProgrammerMatt <pro...@gm...>
>To: sha...@li...
>Subject: [Shadowsrising-devtalk] What have I done?!?
>Date: Sat, 4 Jun 2005 17:48:47 -0500
>
>Good thread title eh?
>
>Anyway, I did something that bears explanation today: error.inc.php and
>sysmessage.inc.php. I was getting annoyed a little bit at the lack of a
>standard error / system message system and there was a lack of themes for
>errors so these two file have respective functions error() and sysmessage()
>that function to erase the buffer and output a page using whatever smarty
>instance applies to where they are called from. Currently they are very
>simple functions that don't even display it nicely, but they add room for
>things like language settings and templated sysmessages and errrors. If you
>don't like them, or had other plans; let me know.
>
>--
><a 
>href="http://www.spreadfirefox.com/?q=affiliates&amp;id=67508&amp;t=72"><img
>border="0" alt="Get Firefox!" title="Get Firefox!" src="
>http://sfx-images.mozilla.org/affiliates/Buttons/88x31/rediscover.gif"/></a>