• 0

    posted a message on Can I migrate old unpaid minecraft username when i buy minecraft?
    I discovered Minecraft in 2010 during the early alpha days, registered my username on minecraft.net, quickly lost interest & didn't buy it.

    I'm interested in the game again & i want to buy minecraft now. However, I'm not seeing any clear migration path for my old unpaid minecraft.net username to a modern paid mojain account. My old username is awesomely short (indicative of a very early player squating on a good name) & i must have it.

    I can still log into my unpaid minecraft.net account, but purchasing the game now requires a mojang account. The last thing i want to happen is $30 waisted on a new username.

    Should I just register a new mojang account, buy the game on the new mojang portal, and pray for a successful transfer of the old unpaid username?

    Thank you for your feedback in this sub-forum. Tech support is underappreciated.
    Posted in: Mojang Account / Minecraft.net Support
  • 0

    posted a message on 1.3.1 ServerChunkCashe grows without bounds, never seen anything like it
    We are running on a relatively weak AMD 3250e 1.5GHz Dual core machine from the 2009 era. We have been comfortable on this machine since Minecraft Alpha; Retail 1.3.1 is the very VERY first time we've exhausted its CPU resources when 0 players are in the server! 1.2.5 with 0 players loaded the CPU a mere 10-20%.

    Anyone else experiencing this? We can't be the only ones having trouble with an unbounded ServerChunkCashe problem. Let me reiterate that even my Core i5 machine cannot run 1.3.1's server software with 1 player without lagging.

    There has got to be a way to force 1.3.1 to unload these extra chunks.

    How are the really big public servers handling this extra loading?
    Posted in: Legacy Support
  • 0

    posted a message on 1.3.1 ServerChunkCashe grows without bounds, never seen anything like it
    I've got a problem on our minecraft 1.3.1 server i've never encountered. Our world has been running since Alpha 1.2.0 on an dual core AMD 3250e machine with 3GB ram. We have lived comfortably on this hardware supporting 5+ concurrent players (62 registered users) for 1.5 years. Even with 10 players and the CPU pegged, we've never had lag and resource usage even close to what i'm about to describe:

    In 1.3.1 ServerChunkCashe grows without bounds, RAM usage grows to levels never seen before, and the CPU gets pegged even with no players logged in. I've watched 1.3.1's cashe grow to 8500+ with 700MB of RAM committed and the tick north of 400ms with a single player. This has never happened prior to 1.3.1; the cashe always unloaded when players left and/or moved to different areas in game (chunks unloaded). The CPU would peg on busy days, but the tick never EVER got higher than 100ms.

    If i let the server sit with no players, the ServerChunkCashe stay around 700 (typical of loading the spawn area). However, if I log in and traverse our realm, the ServerChunkCashe climbs and never declines. A consequence is that the tick climbs to unplayable levels (100+ ms) after about 5000 chunks have been loaded (this happens in minutes). I then leave the server, none of the chunks unload from cashe, no RAM is released, and the tick remains a catastrophe.

    This problem with 1.3.1 happens on different hardware too. Tried it on a E6400 Core 2 Duo, Core i5 2400, and Athlon XP 2500+ based machines. The ChunkCashe grows without bounds and their CPUs quickly become pegged (even the i5). On the i5 it takes about 20 minutes of exploring to peg the CPU (20000+ chunks in cashe).

    I've rolled the server back to 1.2.5 and life is good again. ChunkCashe doesn't grow without bounds, RAM usage doesn't grow without bounds (typical consumption is less than 300MB), and the tick is reasonable even on the old Athlon XP test machine.

    I don't know how to tackle this problem. Is anyone else experiencing this? Have you found a resolution?

    Thank you for your input.
    Posted in: Legacy Support
  • To post a comment, please .