That is HUGE. Try stripping the file internally. You probably have redundant textures or excessive detailing in pieces of the image that are alpha'd out anyway. You can massively reduce many image sizes by simply eliminating the portion of the image that has been alpha'ed out anyway, as there is no reason for that piece of image to be highly detailed because it will never display.

PHP will barf if you attempt to upload an absolutely ginormous file to it. It is not entirely clear whether allowing this is actually a good idea. And seriously, 20 freaking megs? What the hell, man? Use Clean Installer to clean up, don't upload lots infested with tons of crap that will end up dumped as gibberish filenames!

We are closing this issue as it now been resolved. See the user's profile tab for the new option.

Apparently, the roleplayers migrated, according to the staff, so they deleted that board.

Certainly, that one PM could be the significant one. But if that one message blocks the user's inbox, he will be forced to delete it soon enough. It will no longer be a bomb we are holding. Any decision about security is a tradeoff against usability: The most secure computer is the one that you reduce to component subatomic particles. But it is not very usable in such a state. The PM limit is chosen as a balance between usability and reduction of security threat: A 10 PM limit for standard members should be adequate enough for any NORMAL purpose that doesn't involve hoarding tons of pointless nattering interpersed with dangerous information. By forcing the user to be concious of the limits, he becomes concious of exactly what he is keeping. Call waffle all you like, but let's not forget that I KNOW security exploits. Security is my life.

Certainly: Some of the behaviors are simply artifacts created by the importation of the forum code. There is no specific reason they are retained, other than the lack of replacement, and the fact that using the same codebase makes it easier to maintain. Others are strictly technical and security concerns, like the PM limits, and do not specifically pertain to the codebase. The staff are already working on different themes, anyway: I myself have no involvement in this because I do not really comprehend aesthetics. Suffice it to say if you don't like the look, someone else will probably make a different one soon enough. It just won't be me, because to me, everything looks the same.

*4000*?!? Are you mad? What POSSIBLE reason could you have to retain 4000 messages?

No, I didn't. YOU said it wasn't true. I expressed some guarded skepticism at this view, as it most certainly DOES have a perceptible effect on how long it takes to dump the DB, but you have more experience in the specific MySQL implementations. I WILL, however, point out that your claim has NOT been historically true in regards to how excessive PM accumulation affects database efficiency.

So you claim. I argue that the "mailserver" functionality is simply a subset of the functionality involved in a site with additional functionality, and if users retaining 9000 messages was enough to significantly impact the performance of the mailserver back then, it will similarly continue to impact performance now. Perhaps not to same degree, given that computers 20 years ago were significantly less powerful, but this does not matter. Just as a only fool increases his spending merely because he has managed to acquire more money, what represents a good personal expenditure policy for a beggar is as solid an expenditure policy for a billionaire.

The fact remains that if we were to allow users to retain, say, 1000 messages, the amount of DB space devoted to storing useless PM garbage would exceed the amount of DB space used for the actual USEFUL forum by an order of magnitude! You can't possibly be denying that this has NO effect, and the effect on dump time will NOT be insignificant.

The fact remains that you can argue that the impact may be negligible, and I am willing to believe you, but it is entirely immaterial. The impact woul most certainly NOT be negligible if every user behaved as you did. And, as I pointed out, there are clear security ramifications on a global level to encouraging this sort of irresponsible mail behavior. I'd know. You want to know how I managed to even get this in the first place? A SIGNIFICANT part of this can be blamed specifically on IRRESPONSIBLE MAIL RETENTION. Irresponsible mail retention is perhaps the second-largest security threat to a site, second only to "morons for admins". Of course, the two tend to go hand-in-hand...

No, you said that. What I WILL point out is that if the PM inbox is bloated, the site will take that much longer to dump and transfer during routine backups and maintenance. And, in fact, large PM counts DEFINITELY impact the time it takes to run the SMF DB maintenance, and that sufficient volumes of DB bloat will turn it from an operation that is atomic to an operation that takes several seconds to complete. THAT part is clear empirical fact.

Suffice it to say that I believe there are plenty of technical reasons for clamping down on mailbox bloat policies, and I *KNOW* from direct, personal experience in exploiting such that allowing and encouraging mail retention is a massive security threat. You wouldn't believe the stuff people conveniently leave in their bloated Gmail inboxes. An anti-PM-hoarding policy has historically been technically sound and remains EXTREMELY sound from a security perspective.

Okay, yeah, the news is a bit old now. Admittedly, not everyone has gotten the message.

This isn't a debate. I already said I would look for a way to add it.

Oh, there's definitely an impact. When the typical user is hoarding up 9000 PMs and it takes 5 minutes just to dump the entire PM table, YOU DEFINITELY NOTICE. Plus, I've operated mailbox limits before MySQL ever existed. Just because your fancy schmancy new methods allow you to generate more bloat without dragging the server to a crawl doesn't mean you SHOULD. This kind of slovenly attitude is exactly why half the TS2 datafiles consists of dead weight that could be purged with no loss of functionality.

The creators have a larger inbox for that reason.

That's just a side effect of the fact that the MATY source code was imported to get this place running. Removing it would make it harder to keep the code synchronized, though.

As far as I know, we still do. I don't tell people how to behave, so if the "attitude is the same", it represents an actual shift in thinking, and not anything *I* did. After all, MATY and PMBD have factions which hate each other, despite that I run both sites, and I certainly didn't create THAT. Since I have not changed any of the admins here, if people are becoming nasty, that's something that's up to them to deal with. I just run the code. And while Delphy believes that the PM bloat has no effect, and he may even be mostly right, it hasn't ALWAYS been that way. Just as you don't go spending more money on junk merely because you got a pay raise, you don't increase the level of bloatware just because you can.

Is there a point to this other than to try to cause trouble? Do you WANT to go back to Walt? Not that you CAN, since Walt ineptly blew up his site, but still. The fact of the matter is that the inept technical management is NOT part of what is being carried over, and if sensible numbers are inputted into the entry blanks by people who know what they're doing makes it "look like MATY", well, then, too bad: These numbers are used because the same technical constraints exist everywhere, not because of a specific desire to make the sites the same. The limitations exist because if none were set, users would retain EVERY SINGLE PIECE OF JUNKMAIL EVER RECEIVED. Believe me, this happens. It's a massive mess. On other sites where I've seen the DBs, some users have retained OVER 9000 PMs, nearly all of it utterly meaningless blather with absolutely no value. Half the DB was this crap. This is what we're aiming to prevent.

While your proposal for additional junk management features, such as the removal of dead PMs from dead users, is good, such features supplement, not replace, the existing policy on mailbox bloat.

SMF does not appear to natively include this feature for reasons not immediately apparent. I will look into adding it.

Why, indeed? If you can find a mod for purging crap specifically from dead users, let me know. Otherwise, they'll probably be purged when the users themselves are purged.

The Creator group has a somewhat larger inbox for that reason. Still, who the hell gets that many PMs at once unless they are soliciting spam in some way?

SMF does not include such a mod that I am aware of, and also, blind admin-purging of PMs might wipe out the one thing you're actually keeping because it's useful or relevant to some long-running project. The fact of the matter, however, is that 99% of user PM content is utterly vapid and there is no reason a normal user should retain that many, and indeed, allowing them to retain it will simply teach really bad habits. Do not retain old messages. Read them, respond to them, delete them. PMs stored in DB add weight to the DB and slow down all DB operations. If you MUST retain the old messages, save them to flatfile on your personal hard drive.

We did.

The inbox space isn't gonna get much larger. The previous Kathy regime devoted a massive amount of space JUST to the junk-storage of a kajillion useless PMs. And there is simply no reason why anyone would ever get that many PMs! Seriously, what are you people *DOING* with all that inbox space? Receiving THAT many PMs within the span of a single visit is kind of absurd, don't you think? I have never gotten more than 3 or 4 between visits, and that is when something is on fire!

As for another server, at the moment, the site is already on its own server, so moving it to a different server at this point in time would simply result in pointless downtime and be a waste of resources. I could always use another server, but there is simply no point in racking up an additional bill that no one needs when present resources are adequate for the task.

Funny characters are no longer allowed because the source code to get this place jumpstarted was imported from MATY, as the base SMF has horrible security and usability issues, like asking too many annoying questions when I need to perform acts of mass destruction.

As a result, funny-characters are no longer permitted in new usernames, as it is EXTREMELY annoying when people punch in binary gibberish as a username, not to mention a potential security hazard if someone uses executable code for a username. As a side benefit, the readability and clarity of the site will improve when people aren't named "*********FUNKY**********".