Dabomstew

There are definitely automated methods of breaking most image captchas out there - text recognition has come pretty far. It's unlikely that anyone would go to the bother of implementing one of these to cheat on a MCCodes/ other similar game, though you never know I guess.

Response to feedback Ignoring the few immature posts, there's some nice feedback here that I will respond to. Regarding deletion of mail/events: This is not a bug, simply a visual oddity. Events/mails that are not yours are not actually deleted, even though the page says they are. This has been the case since the first v2 release, as far as I'm aware. We will probably patch the visual side of this regardless. Staff panel while not a staff member: As you said, not a big deal. May be altered slightly regardless. Traveling to your own location: Will be patched. Deleting non-existent stuff: Not really a huge deal, but we may look into it, if not for this version then for a future patch. Mantis bug tracker: We do have this setup but haven't really integrated it well into development yet, or provided a way for the public to submit bugs. Expect an improvement in this regard in the near future. Mailing yourself: Can actually be useful (another way of storing notes), we don't consider it a bug. Black list input: Not sure about this, not specifically an exploit but will check it out. Admin banned (by himself): This demo hasn't really been locked off like the v1/v2 current demos. We will sort it out before making the official final demo. ID 3 has no name: Not sure about this. Further constructive feedback is welcomed - further flaming isn't. Don't cross the line! I have also restored access to the 2 advertised accounts for now.

We apologise for the recent server crash. Everything should be operational now, but if there are any errors you see, report them to us at [email protected] Technical details: One of the tables in the MWG database grew so big that the partition with MySQL data on it reached capacity. This caused the server crash as MySQL couldn't write any more data. We have now fixed that, and as of just now, repaired the appropriate table that caused the issue on MWG.

This has already been answered to an extent in the "what you'd like to see" topic, but here's a slightly more in depth answer than what I gave there. Basically, while we do intend to provide some means of compatibility simplification, how easy your mods are to port will hugely depend on how standalone they are. Examples: A poker mod - this mainly stands apart from the rest of the game apart from links to it, so would be easy to upgrade relative to the time taken to originally code it. A mod to give users profile signatures - this mod mainly modifies tables/files in the core of MCCodes, so would be harder to upgrade relative to the time taken to code it. It is possible that the poker mod would still take longer overall to port, but that's why I said relative above. Regarding people's games and potential upgrades: For features that were mods in v2 and become core in v3, we do hope to have some kind of facility in the game upgrader to preserve the mod data if we have info about its structure. We also might potentially work with a few mod developers to have new versions of their mods available upon release that can be upgraded in a similar way.

On our game MonoDistrict we have an admin panel with tabs representing the different categories of admin functions (Users, Logs, Content Management etc). MCCodes v3 will probably ship with something similar.

We made this in MCCodes v2 already, although I'm not sure if it's in the version we distribute. Might've been in one of the test versions now that I think of it. Either way, it'll definitely be present.

If the database connection can't be made, the user's custom error page definition might not be accessible - they might not have caching to disk of skins enabled. We'll still have something slightly more attractive than die() in place though.

I'll reply to the ideas which aren't just straightforward/obvious - if I don't reply to something, it should definitely be in.   This will probably done with customizable levels of logging. However, note that for big games a system like this would get very big very fast in terms of storage usage, as said logs would have to be stored in text due to the number of different actions that users can perform.   This really comes down to the skinning system we have behind it. We do aim to release the code with a mobile-friendly skin included if possible.   Customized error pages will be in where possible. Note that at certain stages in the code they won't be able to be shown (eg. if database connection can't be made) and so a more generic die() page will be shown.   This is possible with clearly defined mod standards. We'll be considering this one, it has a lot of potential to go wrong but also a lot of positive aspects.   This one should definitely be in. Are you referring to customized HTML pages, or closing/opening game functions? We intend to have both though.   This will be possible to an extent. Mods that mostly stand on their own (like for example a Poker game) will be able to be emulated, but ones that modify core files will obviously not be viable. There are also quite a few badly-made mods out there, and we're not 100% sure if we want to support their use in future versions of the codes! But the well-made mods will probably cause this feature to be in anyway.   Will be in, allowing coding the features and coding the look/feel to be seperated. This should help out many teams.   Some more specific insight into what you want to see here would be nice, but we do aim to have the admin interface be user friendly.   This comes down to the skinning engine again - we intend to, with the use of skin bits, allow users to format the data on the page how they want. We will try to ensure that the default style has a smart look to it.   We hadn't thought of that - it does sound like a good idea. This should make its way in, although not every page would have its own styles due to simplicity.   Skinning system as above. There will be some issues with mods however - skins may not have defined skinbits for the mods you install, and then what?   This one is difficult for sure. We can attempt to provide facilities for finding users that log in/out in a sequence, but it is very easy for cheaters to switch up their tactics and much harder for us to detect new ones.   These two are definitely an integral part of the new codes - no point releasing them without these.   Will be done as is appropriate. We are trying to move away from people having to make huge modifications to the core codes of the engine though.   We will attempt to implement some anti-bot measures beyond CAPTCHA, but using CAPTCHAs is important also as it filters would-be attackers down to those who have the skill or connections to automate their cracking.   Defining suspicious activity down to individual game actions is difficult. But we will probably log some of the more obvious ones, such as users trying to enter negative numbers into the "send currency" section. More suggestions and/or replies to my feedback would be much appreciated. All of this helps us release a better engine in the long run.

Glad to hear that the lag situation is a bit better than it was before. We'll continue to monitor it. The new mccodes site that was mentioned earlier should be up tomorrow our time, barring any last minute complications.

Yes, the SMF login/register code is more complex than that of MCCodes v1/v2 so at this stage the easiest way of integrating them is to integrate MCCodes into SMF. We might address this more officially in v3.

Fair enough. But maintaining a server where I live in New Zealand would be many times more expensive than renting/leasing one, the international bandwidth costs here are very high. The server should (theoretically) perform very well but it's possible there are problems we haven't found yet slowing it down.

If it were the provider's network I would expect reports from other sites on the server of similar problems (which I will try to check out further to make sure no other site is having the same problem). The others are definitely still possibilities, and server load has been unusually high as of late so we'll look into it.

As a followup to something you said earlier, if this game is really based off MCCodes Lite then you should have no licensing issues whatsoever and can simply ignore the people saying it's unlegit.

As the links are dead and the TC is inactive, I'll close this topic. If ishmell comes back and wants to continue offering these templates, PM me.

That wording really wasn't called for, but I'll answer anyways. We do have a pretty powerful dedicated server that we rent/lease (I forget which term it technically is) from a company in the US, so it should be able to handle hosting this forum. The traffic isn't of a degree that I would expect it to cause lag.

Yeah, seeing as we don't even really have 2D graphics in the engine (besides layout) I don't think 3D is a possibility any time soon. =P Progress on the v3 engine has been extremely slow over the last few months (since my last post in this topic) but we should have something to show (be it feature presentations/screenshots/whatever) in the next couple of months.

We host the site ourselves and haven't (to our knowledge) had any similar issues with any of our other sites, so that shouldn't be the problem. We did recently optimize the database and repair a couple of tables that had crashed, which might help things a little. The search for the underlying cause shall continue, although we might be moving servers in the near future anyway.

1:00 am EST makes sense as I think the backup cycle has started by then, but I'm not sure about the others. I haven't managed to find and be on during a time where it's lagging yet personally, but once I can I should be able to find the cause.

We'll look into this. It would be great if when someone experiences slowness they note down / post the time it happens. We don't live in the same timezone as most of you so some information as to what times it's being slow for you guys along with your timezone will help things along. It's very possible that this is being caused by something like the server's backup routine.

A 2011 release date is far from stupid, as there are plenty of steps that need to be gone through thoroughly in order to make sure we deliver a quality product and not simply an extension to v1/v2. These include: The development (which itself will probably take ~6 months as this is far from a full-time job) Having a skin made and integrating it properly while still allowing for maximum customization. A first go-over for bugs & security issues before beta testing. Beta testing, first private and then possibly public, with associated updates / fix releases as appropriate. Final quality check. After all of those have been completed [and possibly more I'm forgetting at this time] the product can be released. Seeing as we aren't anywhere near finishing the first one yet, 2011 is our goal. With regards to moderator/admin inactivity, ColdBlooded and myself are the only new staff at this time. While I will admit to personally being quite inactive, ColdBlooded has made quite a few posts since the purchase and attempts to keep in touch with our community on a regular basis. If there is any other feedback relating to the way the forum is run, please take it elsewhere as it's growing a bit off topic here. Further discussion and inquiries regarding MCCode v3 are welcomed. EDIT: Offtopic posts r/e management inactivity have been moved to the "Feedback and Site Support" forum. Please keep those posts in the correct area.

The rand(1,100) bit is there to make the "chance" work like a percentage chance of success. What the formula does is it takes the user's crime XP, and divides it by the person they are trying to bust's level squared. This will give a number which could be anywhere from just over 0 to a very large number. This is then multiplied by 50 to give the percentage chance of them getting a successful bust. The +1 is there to ensure that your chance of busting someone is never 0%. If the formula above gave a number less than 1, then you would never be able to bust someone without the +1. The min(95, chance) bit ensures that your chance of busting someone can never be greater than 95%, to make sure people with bucketloads of crime experience can't just bust hundreds of people successfully. Let's take an example here. Say a person with 100 crime XP tries to bust a level 11 player. Their chance of busting them would be (100/(11*11))*50 + 1, which is 42.3, to 1 decimal place. So 42 times out of 100 they would succeed in busting the person, as 42 out of the possible numbers 1-100 are less than 42.3. As to how to make this easier? The way you have done it, changing (1,100) to (1,50), is one possible way, but is flawed in that there will eventually be some players that can bust everyone every time [as people can have a "chance" higher than 50]. This isn't the best idea, as in this situation no-one would stay in jail for any length of time at all. What you can do is change the *50 to something bigger like *75 or even *100 if you're so inclined. This would just straight up increase people's busting capabilities, while retaining the 95% chance cap to leave some room for failure in there.

This forum is mainly here as a placeholder for when more information is revealed about v3. For now, it can be used for any queries you may have at this time - keep in mind there are a lot of queries which we will not be able to answer, or be unable to answer completely. The price is yet to be considered, the ETA being sometime in 2011.

Your code is bugged and is including both the mainmenu.php and smenu.php. The stock MCCodes doesn't have this bug, so it must be a modification you've made. Check header.php and/or sglobals.php to look for the possibility that both are being included/called by mistake.

This happens because "in" has special meaning in MySQL, so using it as a table alias like that will cause errors. To stop this error occurring, enclose "in" in `` quotes. As such: $bombexists = "SELECT `in`.inv_itemid,`in`.inv_userid,i.itmid,i.itmname,u.userid FROM inventory `in` LEFT JOIN items i ON `in`.inv_itemid=i.itmid LEFT JOIN users u ON `in`.inv_userid=u.userid WHERE `in`.inv_itemid=3"; $bombboom = $db->query($bombexists);

OK, that's very strange... Pass this script a GET variable ("input") with a string and you'll see what I mean...   Running this script as script.php?input=SOMETHING MALICIOUS HERE gives the output: Therefore something very odd must have been happening with your security at the top of the page, as it clearly works. Although securing it again in the individual functions doesn't hurt anything, it still isn't needed and I don't have an explanation as to why it wouldn't have worked for you, as by all the rules of PHP I know it should definitely work.