MathewTombs

What’s up, MaxCheaters? We’ve all seen it. You open a new x100 Craft-PvP server, you have 400 "players" online according to the dashboard, but Giran looks like a ghost town and the farm zones are empty. Why? Because three "pro" players are running 50 boxes each using cheap SOCKS5 proxies or VPNs to bypass your AllowMultiBox=2 setting in l2j.properties. Standard IP limiting is useless in 2026. If you want a healthy economy and competitive Olympiad, you need to move beyond simple IP checking. Today, I’m sharing some logic and a code snippet concept to help you harden your login gate. 1. The Problem with base_ip Checking Most L2J cores (aCis, L2Scripts, Mobius) check the SecondaryPassword or HardwareID (if you have a protection like Strix or Guard). However, smart players use "Proxy Chaining." They mask their HWID or use virtual machines. If your server only checks if IP_A == IP_B, you are losing the battle. 2. Implementing a "Connection Threshold" via IPTables Before the traffic even hits your Java GameServer, you should filter it at the Linux level. A common "Zerg" tactic is to flood the LoginServer to lag out other players during a Castle Siege. Use this rule to limit new connections per second per IP: Bash iptables -A INPUT -p tcp --dport 2106 -i eth0 -m state --state NEW -m recent --set iptables -A INPUT -p tcp --dport 2106 -i eth0 -m state --state NEW -m recent --update --seconds 60 --hitcount 10 -j DROP This stops someone from spamming 20 login attempts in a few seconds. 3. Advanced Java-Side Proxy Detection If you want to get serious, you need to check if the connecting IP belongs to a known Data Center (OVH, DigitalOcean, AWS). Real players use ISP ranges (Comcast, Orange, Telefonica). You can integrate a simple REST API check in your L2GameClient.java (or your login handler). When a connection is initialized, verify the IP against a provider like IP-API or ProxyCheck. Logic: If proxy == true AND player_count_on_this_hwid > 1, kick the connection. 4. The "Ping Variance" Method (No-Guard Solution) If you don't have a paid protection like SmartGuard, you can use "Latency Fingerprinting." Players on the same local network (multi-boxing) usually have nearly identical latency ($<1ms$ difference). Players using a Proxy will have a significantly higher "Jitter" than a direct connection. By logging the last_ping packet in a small Map, you can flag accounts that move with synchronized packet intervals—a dead giveaway for botting software like Adrenaline. Conclusion Don't let your server die in the first week because 5 people hoarded all the Boss Jewels using 100 characters. Tighten your LoginServer, use IPTables for the heavy lifting, and don't be afraid to manually ban IP ranges from known VPN providers. What are you guys using for protection these days? Still sticking with Strix, or has someone found a solid open-source HWID solution for the newer Interlude remasters? Let me know in the comments! If you need the specific Java imports for the Proxy-check method, ask below and I'll post the ClientThread.java modifications

Hello MaxCheaters community! We’ve all been there: you spend months customizing your NPCs, balancing classes, and setting up the perfect farm zones. You launch your server, the hype is real, and suddenly you hit 200 players—and the "delay" starts. The mobs stop reacting, the Olympiad matches stutter, and your players start complaining on Discord. Many "newbie" admins think the solution is just throwing more RAM at the VPS. While hardware matters, Java is a finicky beast. If you don't tune your JVM (Java Virtual Machine) and your core code, you’ll lag even on a NASA supercomputer. Today, I’m sharing a deep dive into optimizing your L2 server for maximum performance. 1. The Myth of "More RAM" The biggest mistake people make is assigning 32GB of RAM to a server that only needs 8GB. In Java, if your Heap size is too large, the "Garbage Collector" (GC) has to work much harder. When the GC runs a "Full GC" cycle on a massive heap, it performs a "Stop-the-World" event. This literally freezes your server threads for 1–3 seconds to clear memory. Recommendation: For a mid-rate server with 500 players, 6GB to 8GB of Xmx (Max Heap) is usually the sweet spot. Use G1GC (Garbage First Garbage Collector) instead of the old ParallelGC. It handles large heaps much more gracefully by breaking memory into regions. 2. JVM Startup Flags (The Secret Sauce) Don't just run java -jar l2jserver.jar. You need specific flags to ensure the CPU prioritizes the right tasks. Try adding these to your start.sh or start.bat: Bash -Xms6G -Xmx6G -XX:+UseG1GC -XX:MaxGCPauseMillis=50 -XX:+OptimizeStringConcat -XX:+UseStringDeduplication -XX:+ParallelRefProcEnabled -XX:+TieredCompilation MaxGCPauseMillis=50: This tells Java, "Try not to freeze the server for more than 50ms at a time." It makes the gameplay feel much smoother for the end-user. 3. Geodata and Pathfinding Optimization Geodata is the biggest CPU killer in Lineage 2. Every time a mob moves or a player clicks, the server calculates "Can I see this target?" and "Is there a wall in the way?". The Fix: Use a "Pathfinding Cache." If 100 players are running from the Giran Gate to the Luxury Shop, the server shouldn't calculate that path 100 times. Check your Geodata format: Ensure you are using the .l2j or .dat formats optimized for your specific core. If your console is flooded with "Pathfind node limit reached," increase your node limit in the geo.properties file, but be prepared for higher RAM usage. 4. Database Pooling (HikariCP vs. C3P0) If your server freezes for a split second every time someone saves their character or buys an item, your Database Connection Pool is the bottleneck. Most old L2J cores use C3P0, which is outdated and slow. Switch to HikariCP: It is significantly faster and handles "dead" connections much better. Also, ensure your characters and items tables are indexed correctly in MySQL. Running a VACUUM or OPTIMIZE TABLE once a week can prevent those annoying "saving player data" spikes. 5. Network Threading In your server settings, look for "Network" or "Thread" configurations. Usually, you’ll see SelectorThreads and WorkerThreads. Selector Threads: Should be equal to the number of physical CPU cores. Worker Threads: This is where the logic happens (skills, movement). If this is too low, actions will "queue up," creating a delay even if your ping is low. 6. Community Board (BBS) Optimization On MaxCheaters, we love fancy Community Boards. However, if your Buffer or Shop script is poorly coded, it might be reloading the entire HTML from the hard drive every time a player clicks a button. The Fix: Ensure your scripts cache the HTML in the RAM. Reading from an SSD is fast, but reading from RAM is thousands of times faster. Conclusion Optimization isn't a "one-click" fix; it’s about finding the balance between your hardware and your software. Start with your JVM flags, clean up your Geodata settings, and make sure your Database isn't choking on old logs. If you found this helpful, leave a comment or a "Thank You" below! If you have specific lag issues with a certain core (aCis, L2Emu, etc.), post your server.properties and I’ll try to help you tune it.