We wrote an plugin many years back to manage profile comments. We ended up removing it when we upgraded our forum software (to MyBB 1.8, a pretty major upgrade), which broke the plugin. It was never finished and was always a little buggy, so we were happy to see it go at the time. It also was never released publicly, so there was little incentive to really fix it.

I rediscovered it today and realized that there was not much that needed to be changed in order to port this to the current version of our forum software. As such, I've brought it back, and it has some features that integrate pretty well with the current version of MyBB. It's still a work in progress, so I'm well aware of a few bugs that are pretty hard to miss. I'm working hard to get it working again!  

Anyway, you can see a status feed in the forum's footer. Try adding a new status. Watch it appear on your profile, in the footer, and under your avatar on your posts. If you reply to another user's status, they will get a notification!

Edit: The more I use it, the more I realize that it's hilariously buggy right now. I'll have it working better within about a week!

This is counting thread, revisited. 

The banner will attempt to keep along with the count in this thread. However, posting wrong numbers, numbers out of order, or otherwise doing confusing things will cause the banner to get completely lost. 

Game rules:

• You must post a number, similar to the counting thread. 
  
• You must post the banner's current count in your post.
  
• The banner's counter must be posted AFTER your count. Until I fix a bug in the banner, it won't work properly if you post the banner's number first. 
  
• If we discover that the banner's count completely changes, the next person will post "Banner Broken"
  
• You'll get a usergroup tag for this game from an admin until the next person breaks the banner.  
  

Please make your selection for the 2019 Makestation Project of the Year.

The poll is anonymous, and no one will see your vote.

Project of the Year candidates:

Lain's Cracking Hashes with Arduino
brian51's Transit Mania CJ
pierreh's United Cities of Talaran

Please make your selection for the 2019 Makestation Newcomer of the Year.

The poll is anonymous, and no one will see your vote.

Newcomer of the Year candidates:
Altair
Lain

Please make your selection for the 2019 Makestation Member of the Year.

The poll is anonymous, and no one will see your vote.

Member of the year candidates:
brian51
Thomas

This project is a series of around 4 books. They focus on Nuru Caldwel, a young man who was cursed from birth to be able to see curses. Being the only one known in the world to be able to detect a curse, Nuru and his sister run an occult detective agency for Nuru to use this skill to help people. And, through all this, he hopes to find someday the one who cursed him with this power.

That's just the basics, but the rest of this thread will be little notes about how certain things work, snippets as I write the books, etc. I'd love to hear your thoughts sometime.

Looking for some graphics, i.e. 88x31 button and a 468x60 banner.

Image and color scheme:


Text: Aeowulf or Aeowulf Forums


I got some Station Cash to burn, so name your price.

Tampa is starting to play quite well again

Our win streak is now up to 7 games and we play again tonight

I'm a bit confused after looking at the Makestation Awards. How do we create a project to be even thought of for this award/in general?

I play around with Project Euler from time to time. These are programming problems that are designed to be difficult to solve, but not unsolvable with a modest computer hardware and a good algorithm. The trick is to come up with a good algorithm to do the job. Therein lies the problem. Algorithms are hard to design, especially if they are highly efficient.  

I usually do these in Python. I also do very easy problems, and try to optimize them as much as possible. Python, unfortunately, is an interpreted language. It does not compile to machine code. As a result, average Python code is at least 10x slower than equivalent C code, and often slower. 

That being said, my challenge to myself was to make this problem run as quickly as possible, and to make it run with relatively large numbers. This problem is based on Problem 4, but I've expanded it somewhat. Instead of using two three digit numbers to find a palindrome, it uses two numbers of arbitrary length. I've tested it with as many as 10 digits, and found that it runs in fairly reasonable time constraints. 

My python code: https://www.dropbox.com/s/hoekt73ioovwq0...me.py?dl=0

This is technically an O (10^n)^n algorithm, so it is, quite literally, doubly exponential in runtime. As the number of digits increases, the runtime increases quite severely. I have yet to find a better algorithm to do the job, so I tried to optimize the one I had as best I could. I've asked as many math majors as I could. I've looked all over the internet for better ways of approaching it. I have yet to crack the problem. It seems like trial and error is the only way to really attack it, as least as of so far. 

What this does to run faster: 

• I multithreaded this. The trick to doing this is to use processes instead of threads. This gets around the GIL lock that ordinarily prevents this, and allowed Python to properly use all available cores. 
  
• The algorithm starts by checking the largest numbers first, as it only wants the largest palindrome possible. Generally, the factors of the largest possible palindrome are very easy to find at the top of the possible number range. By starting at the top, runtime is improved significantly. 
  
• As it turns out, every single even-digit palindrome has a factor of 11. This algorithm only ever needs to check every 11th number, making it run ~11 times faster. 
  
• It runs as a loop within a loop (hence the doubly exponential time). However, it assumes that the first factor will always be the larger of the two factors, since 997 x 993 == 993 x 997. Thus, if it checks a combination of numbers, it doesn't check the reverse of this combination, which would have the same result. 
  
• If it finds a palindrome at 993 x 990, it cannot necessarily stop evaluating lower numbers. If, for example, 992 x 995 was a palindrome, it would be a higher palindrome than the first one would be. However, it has a heuristic to detect if there is possibly any higher palindrome than the highest one it has found yet, using only numbers it hasn't checked. As soon as it detects that no higher palindrome could be possible, it stops evaluating. This massively improved performance compared to the unoptimized code. 
  
• It "guesses" on possible values to find the first palindrome. The highest palindrome is almost always made up of two factors that are very near the top of the number range that is given. As a result, it does not attempt to calculate 999 * (any number from 999 to 1). It stops at 999 * (some number around 900-990, depending on settings), and then moves on to 998 * (similar range as previous iteration). 
  
• By "guessing" in the most likely range first, it almost always finds palindromes much more quickly. If "guessing" fails to find palindromes, it falls back to checking the full range. It rarely does this. There's almost always a palindrome near the top of the range. 
  
• Once it's finds the first palindrome, it can check a smaller range of numbers, since it only needs to check combinations that, when multiplied, are higher than the previous highest palindrome. As a result, this algorithm goes much faster once the first palindrome was found. (This is the reason that "cheating" and guessing on palindromes increases performance so drastically. )