Crazy Frog

Yeah haha, I think there may have been a misunderstanding there. I was really just throwing out ideas and different ways the problem could potentially be handled — not saying Pure needs to implement any of this or that I have a perfect solution. I actually play on Scourge, so the Pure limitations don't really affect me personally anyway. I just enjoy discussing these kinds of things and throwing ideas around. If something from the discussion happens to be useful for Pure, great. If not, no big deal. I definitely agree that the modded servers already have a lot of these protections available, and Pure obviously has to work within a completely different set of limitations. So yeah, no hidden agenda here — just brainstorming. And thanks for the detailed response!

I agree that giving players access to player activity or access logs is probably not the right solution. That could easily turn into accusations, witch hunts and unnecessary conflicts. However, I think we can solve the underlying problem without giving players any investigative tools at all. The issue isn't really “players need better bases”. The issue is that the current protection model depends too heavily on an administrator being online. On a PvE server, that creates a very strange situation: if someone deliberately steals a Mini, Attack Helicopter or accesses property while nobody is available, the victim has no meaningful way to prevent it and the admin can only deal with the consequences afterwards. I would suggest exploring an automated TC-based Property Protection system instead. The concept would be: TC authorization determines who is allowed to interact with protected property. For example: • Containers and important deployables inside a protected TC area cannot be accessed by unauthorized players. • Deployables cannot be picked up or manipulated by unauthorized players. • Minis and other player-owned vehicles could be associated with the owner/TC authorization, preventing unauthorized players from simply taking them. • Protection could apply particularly when the owner is offline, which would directly address the situation where there is no administrator available. • Players would receive absolutely no information about who attempted to interact with their property. They simply get protection. • Administrators would retain whatever information is necessary to investigate reports internally. This is important because it separates protection from surveillance. We don't need to tell players: “Player X accessed your box.” We simply tell the server: “Player X is not authorized to access this property.” And the server prevents the interaction. That completely removes the witch-hunt issue while still protecting legitimate players. I would also avoid solving this by simply enabling shotgun traps, landmines or other PvP-capable defenses. That changes the nature of Pure and can create an entirely different set of problems. An automated protection layer would preserve the PvE philosophy much better. The helicopter issue is probably the clearest example. If I park my Mini at my base and log off, I shouldn't have to assume that the only thing protecting it is whether an admin happens to be online at that exact moment. The server already knows: who owns/controls the TC, who is authorized, where the property is located, and whether the owner is online. That information could potentially be used to enforce protection automatically rather than requiring an admin to react after the damage has already happened. I'm not suggesting that this should necessarily be implemented immediately, or that we should change Pure's vanilla philosophy without discussion. I'm suggesting that this is the technical direction I'd investigate: TC authorization → ownership → automated protection → no player surveillance. It addresses the actual weakness without introducing PvP, without creating witch hunts, and without requiring 24/7 administrator coverage. If it is technically feasible within the limitations of Pure, I think this would be a much more scalable solution than expecting players to continuously build around the possibility of another player exploiting an admin absence.

I understand that flowers used to have a larger stack size and that it was changed, but that doesn’t really address the point I’m making. The issue is that flowers are a farming resource, just like wood, sulfur and charcoal, and they take a significant amount of storage space when farmed in large quantities. Having to constantly sell them because the stack size is artificially low isn’t really a quality-of-life solution — it just creates unnecessary inventory and storage management. As for backpacks, not everyone wants to dedicate every clothing slot to carrying flowers, especially when those slots are useful for actual gear and protection. And having to repeatedly travel back and forth to sell flowers also takes time that could otherwise be spent playing the game. Increasing the stack size to 5k or 10k wouldn’t make flowers overpowered or give farmers an unfair advantage. It would simply make farming and storing them more convenient, while keeping the same economy and value. If wood, sulfur and charcoal can stack to 5k/10k, I don’t really see a strong gameplay reason why flowers should be treated differently. It’s a simple QoL improvement, especially on a server where a large part of the player base makes scrap by farming.

Hey, I have a suggestion that could make farming a lot easier and more efficient for players. Could you consider increasing the stack size of Orchids, Roses and Sunflowers to 5,000 or even 10,000, similar to Wood, Sulfur and Charcoal? A lot of players use flower farming to make scrap, and the current stack limits mean we have to constantly manage huge amounts of boxes and storage space. Increasing the stack size wouldn't really change the economy or give players an unfair advantage — it would simply make farming and storing resources much more convenient. Since a large part of the server's player base farms flowers to earn scrap, I think this would be a really useful quality-of-life improvement. Thanks for considering it!