Octarine

Dam, now I have to install PHP somewhere...

Well whaddya know... :D

Stories were told many years ago of a legendary artefact that granted the possessor untold riches; though how was never made fully clear. As you disembark Her Majesty's Air Ship "Sea Eagle", you reflect back to those days and nights spent with your Grandfather and his delightful selection of stories. Could they really be true after all? Could this be the start of the journey that will restore your family's honour and more importantly its fortune which was so quickly squandered away by your father? Introduction ""Stonemont: The Lost Tales"" is an RPG designed around the Steam-punk era, taking a mix of Victorian values, Wild West bravado, Jules Verne styled adventures and adding little nostalgia back into gaming. Combining the latest visual techniques, together with a specially designed back-end, the aim is to provide a gaming experience that brings back memories of a gentler time where cooperation yields beneficial results over combative play. As you begin your adventures, you are lead carefully through the game's user-interface via a number of interactive NPCs. The basics of each element are quickly covered, though the subtle nuances will not become apparent for some time. Having graduated from the tutorial, you will be asked to join one of the three guilds each providing a different style of game-play. As the exact details of how these different guilds operate is known only to a select few, the player may allow a random selection or choose one based on what little (intentionally) information is present at this stage. Players are free to change at a later stage although restrictions are in place to prevent mass "jumping ship" or "frequent flyers". The core activities in the game include resource gathering, crafting and trading, each of which allow you to compete in the grand expositions held weekly. These are large activities involving as many users as possible and tie together the experiences of both individuals, teams and guilds alike. Fleshing things out Raw materials including base metals, timber, leather and fine sand along with specialist oils found only in rare locales are all important to every player, however each individual may elect to specialize in one form or another and trust their trading skills are sufficient to gain access to the others. Once you have gathered enough stock, you can start to learn the crafting skills in order to turn your raw materials into something worth a lot more. As with basic resource gathering, it is wise to specialize in certain types of crafting in order to profit from the considerable experience gains to be had. Training of certain key areas can improve your basic skills here, however each additional level of training costs considerably more than the last so care needs to be exercised to maintain the flow of funds. The weekly expositions involve the solving of puzzles, some easy, some complex; however they all essentially fit a pattern in that the players must strive to complete the puzzle by filling in the "blanks" with the raw materials and crafted products they amass during the week. These rounds serve to bolster players experiences and cement friendships. The puzzles are made of small Rube Goldberg / Heath Robinson / "Was passiert dann Maschine" styled machines where parts are provided by the players to complete their design. By providing the correct number and type of component parts, the puzzle can be fully complete and bonus experience awarded to all participants. Having a wide range of skills each with their own individual experience levels rather than a single overall "level" allows the players the ability to compete from every possible angle and from very early on in the game. With the rich diversity that Steam-punk itself provides and the ability to draw upon early classic science and fantasy fiction (a favourite of the design team) there is a great deal of scope for expansion to be found. Premium services are planned, however only after sufficient time has elapsed to rid the system of any lingering bugs or unexpected item side effects. Ideally, premium players would benefit from a wider range of activities, locations and items, given the wide-reaching genre this should not prove problematic. Dipping a toe in While there is no real need to get into specific details regarding the exact composition of every aspect of the game perhaps a few brief appetisers would prove favourable: The raw materials comprise roughly of: copper, zinc and iron, polished mahogany, walnut and teak, fine sand, soda and lime (for glass making). From those, players can make a range small goods including: brass fittings and bearings, wooden cases, cog-wheels, glass knobs and blown glass containers. With improved production facilities and crafting skills comes the ability to create gas lamps, pocket watches, large clocks, small arms including the famed duelling pistols the blunderbuss and the seriously over-powered though highly inaccurate punt-gun, telescopes, steam boilers, and even mechanical limbs. The very experienced players will have the chance to combine their resources to produce some very other items such as steam powered auto-mobiles, submersible and flying ships, calculating machines etc. During the game, players will meet and interact with a large number of NPCs including "Alvah Higgleshank" our talented though occasionally daffy seamstress, "Philip Steelvolt" the curator at the Museum of Iniquity and of course "Sir Bartram Jollywheel" the Master of Ceremonies who apart from being a dreadful old bore, is responsible for the maintaining some semblance or order at the duelling tourneys. Teaming up If guilds are a mechanism designed in part to provide differing types of game-play, then the teams build upon this idea but on a smaller scale. As teams are expensive and time consuming to build, players will hopefully become strongly attached to their own, and in turn specialize thus producing better experience gains. Contention is expected certainly between players individually which can be settled over a duel, while any contention arising between teams will be settled in the manner of gentlemen with a large contest to determine the winner. Prizes will be awarded for these tourneys making them an important part of your character's life. As hopefully, can be seen, throughout the game, cooperative play is rewarded and as players work together they will find that their experience gains for any task improves with both repetition and working with the same people. A self-levelling process, this system is designed to bring players together albeit with some friendly rivalry from time to time. Features and Differences Unlike many other text-based games, Stonemont: TLT does away with many small restrictions such as the requirement for unique display names and user ID # suffixes. Disassociating the display technology from the logic enables more client-side work and simpler server-side operations. While players can amass large experience and financial rewards, the game ensures that high inflation cannot take over in part by self-levelling systems, and through wise data-type choices. Having done away with CAPTCHAs a while back, there is some consideration being given to providing some form of automation API actively promoting the use of external player-driven “bot” players. The NPC actors themselves are in fact a form of bot written in a mix of compiled languages and interacting directly with the game via a specialized message queue. The design of these actors is such that altering their conversation is an easy task as is moving them from one location or indeed one game to another. The visual aspect of the game is, given the genre, very rich; with a warm colour scheme and simple controls. Externally every attempt is made to ensure that the game itself is playable from a variety of mediums and possibly embedded platforms (think smart-phones, Facebook etc.). Full templating with a well documented request and response structure gives the designers the ability to change the look and feel without necessarily involving the programming team. Server Side Internally, the game is split into a number of different sections, covering storyline design, play testing, event logging and reporting. The large number of relatively static design components (items, places, NPCs etc.) relies upon NoSQL solutions while the heavily dynamic data is RW split from the outset across multiple back-ends allowing for quick and easy scaling and more importantly automatic backups. Logging uses RRD technology to reduce the quantity of data held yet retain the ability to perform detailed analysis. The staffing system follows a more formal modal, in that staff are there to act as guides; they have no access to player data nor design data. If problems arise with spam or any form of verbal and/or textual abuse they can deal with it appropriately. The design team control the story line, the items, the NPCs etc. in reality, all the static data. Once the initial game is released, any changes they make will be based upon play-testers reactions and to an extent existing game logs to see how well something has gone down with the players in the past. Technologies used: HA proxy load balancer feeding NGinx which in turn serves static and user uploaded media and feeds other requests to the application servers running Apache and PHP. Dual headed MySQL node with hot swappable standby in read-only mode supplying replication facilities out the offline storage facilities. Redis and/or MemCache providing static data access, dynamic query caching and front end template caching. RRD server handling logging and tracking all requests. AMPQ stack dealing with message handling and processing the irregular timed jobs. Python (Tornado-based) back-end providing remote monitoring facilities, cooperating with the RRD to feed a suite of real-time monitoring facilities. All front-end systems run BSD while the development and support systems are all Slackware based. Finally... A couple of quick Q&As Yes, the game is feasible. Not only feasible but large parts are already tried and tested and running on production boxes as we speak. In fact, certain aspects have been in use for over 4 years. The NPC system was initially designed for an McCodes product though it has evolved somewhat. The self-levelling systems were designed more recently, and are remarkably simple to implement even though their basis resides with mathematicians. The server-side set-up does appear complex however it is designed with scalability in mind. It can degrade down to a single AMP stack, however to ensure the game is as responsive as possible and that both code and data are full protected against multiple forms of attack, the system is split into essentially several small self-healing elements; none of which are themselves a SPoF. Need more information ? PM me – Stonemont: The Lost Tales -- Preliminary Draft Document Copyright © 2012 Node86 Group All Rights Reserved.

PHP: The Right Way - its a moderately interesting read; though I feel, too little, too late, and in certain areas, I think they [the authors] have missed the plot totally. I'll leave others to draw their own conclusions.

But wasn't the last nuclear test in 2009?

too easy :D

... @op : It would probably be useful if you posted a little more about the services you offer; ie what environment(s) are installed Scripting language support? - Presumably PHP, but which version and are other scripted languages supported? Database support? - Presumably MySQL, again, which version and what other databases are supported? Caching system? Is Memcached/Redis installed? if so, what versions Web Servers? Presumably Apache, ... which version and are any others available FTP/Shell access? Provided? Operating system? Which ... etc etc

Seriously is that actually difficult? </rhetorical>

RFC2616 makes it pretty simple in suggesting that a GET operation should be considered ""safe"" in that it does not change data whereas a POST operation may change data. Bearing that in mind, the fix should be apparent without resorting to ugly-assed urls which are often difficult to bookmark and/or remember.

the temptation is almost overwhelming to say ... but but you're wrong! ... but since my partner in crime is not available to comment; all I'll say on the topic is find yourself a vps, doesn't matter who, and give them a try. You will almost always find somewhere better in due course, but personal experience counts far more in my opinion than the woffle spouted forth by the local residents (and yes, I can probably include myself :P) @the OP ... Since all you stated was "good vps hosting sites" without defining your experience/skills/requirements and what *you* consider to be good ... the rest of us can only hazard a guess. Hardly an ideal scenario. I can almost guarantee the any hosting I could provide would be excessive in processor/memory/contention terms, but terrible from your point of view in respect of OS and installed services, but I've no doubt a VPS can be found if you declare your requirements up front.

Nicely said.

The art of debugging is obviously a lost art... ... $r = $db->fetch_array($get); $einfo=unserialize($r['effect2']); ... Call to undefined method database::fetch_array() Look at the code; it's apparent that you need an associative array - as can be seen by the following line ($r['effect2']). Associate arrays from MySQL (in this context) are returned by one of two functions: mysql_fetch_assoc() or mysql_fetch_array() though the latter does need a second parameter to be one of MYSQL_ASSOC or MYSQL_BOTH. So you need to find something that calls one of these two functions ideally. Looking at the database class (class/class_db_mysql.php) a quick search in your editor will show you that the fetch_row() method does exactly that. ie: search and replace $db->fetch_array with $db->fetch_row in SNIKO's code. Simplez.

Possibly, but the advantage is you can select which mail server to use as a router ... ie; if you have a GMail account, use it as a smart host - saves a metric tonne of headaches. Sure with some fiddling you can kinda do that with the built-in smtp facilities, but its messy. At least this mechanism provides the extra ability of being able to debug the actual protocol itself - which can help considerably in debugging any number of problems. Hotmail, is certainly not alone in this, there are quite a few big mail providers that cause similar problems - apparently in an effort to reduce spam... though if I look in my spam folder, a large % seems to come from those domains... go figure ;) Its also dead simple to add html components, attachments, etc etc.

It's really very simple - perhaps a little example will help. Obv. that would need to be adjusted to suit your own environment, and ideally the last stage wrapped in a exception handler; but as a quick demo, it should give you an idea.

The dog ate mine :D

Assuming the not necessarily localhost MTU is correctly configured and hotmail is sending bounces, then your catch-all mail account may well contain those. Failing that it, may become necessary to move to something a little more sane than the sadly lacking mail() function - something like SwiftMailer as I alluded to earlier. Sockets() are fine, but tricky unless you are prepared to waste 6 months trying to understand a mail protocol that seldom adheres to RFC specs and is really best left to small wizened old men in dimly lit back-rooms wearing slippers and smoking fine pipe weed.

Not to mention, the code itself only allows for positive amounts making a signed field illogical.

No, I didn't test it on 58 servers; that's how they are configured.   Personally, I dislike pushing things up hills especially when I already know the outcome. Your 6 years experience not withstanding, if even one system were to reject your mail, then your statement would be at fault. And as RoZ seems to point out, I'm not the only who uses locked down systems. Is it really so hard to accept that mail servers may not accept random addresses? The big companies we know use sender policy frameworks to bypass this problem - you can even see that if you look at (certainly Google's) mail headers. Just looking at the source of any of the current crop of half-decent mail servers its pretty apparent that they are designed to handle a huge swathe of different problems; and reject mail with messages such as   550 mailbox rejected for policy reasons 551 User not local; please try <forward-path> 553 Requested action not taken: mailbox name not allowed If you've never had to deal these, lucky you. But of course you wouldn't actually see them with the mail() command itself, as it cannot differentiate between errors at all on Windows boxes (returning instead as I've already pointed out - a "malformed address" error internally equating to a False at your level), while on *nix boxes it simply doesn't even bother to parse the output of the MTA. It doesn't actually matter whether the servers I (or other people) use block unknown addresses intentionally, what matters is whether the OP can solve their specific problem; so can we concentrate on that rather than wasting time? If you won't accept what I've stated - so be it; I'm sure others can do their own research. *When* you run into problems, hopefully you will remember this and quickly see the solution. @OP : In the mean time; using something like SwiftMailer might actually reveal the problem right away - or go down to sockets level yourself - I'm sure somebody will be delighted to show you how they work.

6 servers? That many? I'll raise you 58. And I suppose all odd numbers > 1 are prime? Tested 3 : Yup, prime Tested 5 : Yup, prime Tested 7 : Yup, prime Looks good to me... Just because a few work does not mean they all will. Even if a fake address is accepted at the local end (a lot of hosts allow essentially <anything>@your.domain), that does not mean that the mail will reach its destination. The mail server itself may simply not permit unknown MAIL FROM: <random>@your.domain which is perfectly legitimate assuming you follow the RFCs (2821 I think it is). Sender Policy Frameworks may also reject the address for at least 3 different reasons. Any intermediary mail server can reject the address as it sees fit as long as it provides a response back to the originating server; though of course PHP will never see that response. On Windows servers, the internals of PHP will erroneously report a malformed address for ANY type of response other than a 250 (OK); so mail servers being restarted, or under heavy load make PHP assume something other than what is actually happening. On *nix equipment, a <random>@domain.com is as far I can make out, simply not tested for by the mail() command or the stream handlers so you actually cannot tell if the local MTA has accepted the mail or not.

s/DONT/sometimes/ s/WILL/might/ s/Form:/From:/

CREATE TABLE `tchance` ( `logID` INT UNSIGNED NOT NULL AUTO_INCREMENT, `userID` INT UNSIGNED NOT NULL, `amount` INT UNSIGNED NOT NULL, `active` TINYINT UNSIGNED NOT NULL, PRIMARY KEY (`logID`) ) ENGINE=MyISAM;   Changes: * Made fields unsigned (signed auto_inc is the spawn of the devil, and signed amount is illogical) * Removed defaults (unnecessary) * Removed CHARSET definition (unnecessary) * Removed number sizes (irrelevant) * Retained field widths (record should align nicely to 128 bit boundary) Notes: logID is a simple 32-bit number (in fact 2^32-1). userID is now an unsigned 32 bit number (though tbf, you will not hit 2^31 users) amount is again unsigned allowing up to 4,294,967,295 though in practice you'd probably limit this at PHP level active is an 8 bit number, but presumable acts like a boolean (0 or 1) defaults widths are 10 for (unsigned) INT and 3 for (unsigned) TINYINT which is ample default charset of the DB will be used, (though as it's all integers ... pretty much irrelevant)

logID - int(20) - seems rather wasteful userID - int(11) - expecting negative user ID's ? amount - int(10) - expecting negative values ? active - tinyint(1) - best idea so far

Sophos, however, is possibly not an ideal candidate .. Sophos antivirus classifies itself as a malware.

At that stage everything else becomes utterly irrelevant. It doesn't matter of your code does or not handle some odd aspect of your game code or not. The simple fact that somebody has managed to gain access means that all your code, and data must be treated as hostile. What's wrong with using the primary key in the WHERE clause? Anything else - especially something that can be changed by the players opens you up to race conditions again. Primary keys can be considered immutable in this context, whereas things like login name / username / email address / password etc are all highly liable to change whether under direct user control or not. Line #1 is performing a test - against the database, therefore, the correct row will have already been read into memory, and thus the primary key is available.

The are correct ways to indent in many languages. In PHP, both Pear and Zend to my knowledge have published lengthy guidelines on how to tackle the problem. COBOL compilers were extremely strict in this, Whitespace I assume is equally strict for obvious reasons, Python has PEP8, C has indent though which style (GNU, K&R, ANSI) seems to be author-dependant; certainly a good number of mid to large companies have if not a documented style, at least one which is adhered to. Lazy (left aligned) code has no place anywhere these days. #canofworms :D