*points out a few bugfixes he posted that were never added to the list*

You need to prod there, not here. :P Prodding here makes me laugh at you. Prodding there makes me feel obligated to actually do something about it. (Not that I'd be able to do anything about it currently, neck deep in class conversions. >.<)

*blinks a few times, then walks off towards smaugmuds.org*

Discussing the revival of the SWR codebase is interesting and all. Thing is that there isn't really any such thing as a SWR 'community' in terms of any development efforts. Smaugmuds.org is the closest thing. In my years in SWR coding I've seen nothing but petty competition, spreading of false rumours about other MUDs, and the inability to appreciate eachother's innovations. But I'm going to do a tentative attempt at bringing this thread back on topic.

@Rojan
I think you should consider David's suggestion and do proper homework. It's a well known fact that optimizations based on gut feeling usually leads you to work in all the wrong places. Perhaps you should profile the code to aid you in finding the real bottlenecks. It will save you a lot of work in the long run.

@Zenn
I'm certainly not dead :wink: I just tend to go underground in periods.

Alright, thank you.

The issue here is that you're trying to fix something that just can't be "fixed". At the end of the day, SWR is still performing a gross number of unnecessary, inefficient operations. You have to step back and see the big picture. You have a massive linked list structure of ships that's proving to be a giant performance bottleneck - those loops are killing you! Creating a handful of specialized lists is still just sprinkling gold dust on a turd; if you hope to have a proper system that can handle any kind of load with finesse, you'll need to abandon the list concept, period.

What I would advise you to do is to gut the space system and opt to partition your "universe" with a tree structure instead - something much more practical for this application. I would imagine a 3D R-tree to work wonders for you. Take a peek on Wikipedia. Every kind of now lengthy operation you'll want to do in SWR will be trivial to update for such a system. To be abstract, it's time to stop saying "sequentially perform a comparison between my ship's position and that of every single object in the universe" and to start issuing more meaningful queries like "which objects lie within a certain proximity of my position?" Spatial indices will drastically improve your performance. Furthermore, for trivial queries that have you seeking a ship by name or ID, you're still free to opt for David's advice and build a hash table for quick reference.

Good luck and don't take a hackish route.

I would still suggest that you look at what kind of queries you are doing in the first place before delving into things like 3D R-trees. That won't help you at all if you're trying to identify all ships in flight vs. ships that are landed.

It can't be repeated enough: profile first to identify the bottlenecks, then decide how to optimize it.

A 3D R-tree will only help you for queries based on distance. It doesn't help you at all for queries based on other forms of state. If your performance hit is in searches based on state, name, etc., a 3d R-tree will be a big waste of time. If your performance hit is in figuring out which ships are nearby, the spatial tree data structure will work wonders.

Profile, profile, profile. Always do homework before spending lots of time working on an optimization – that might, incidentally, just make things worse…

I think what you really should look at;

Does it work? Yes. I know that much.

Is it THAT much of a resource drain that it has to be corrected? No clue.

Is changing it necessary? That's up to you.

Do you have more important systems/features to fix, rather than optimizing a system that DOES work? Again, not familiar with your bugs and such. But you really should consider these points too.

It's not a deadly bug, but if there's a space battle with too many ships (200+ I'd say), the mud will likely crash.

Leaving things alone because they are "just good enough for now" is one of the reasons why poor architecture choices are allowed to grow into very large systems built on top of flaky systems – and then those create just more problems later on, that become harder and harder to fix as the system grows larger and larger. A lot of these codebases would be in a much better position now if some basic software engineering had been applied much earlier on.

Of course, there is a balance to be struck between fixing things and adding new features. But fixing things that have been established as serious problem points (Rojan says he has already observed critical performance hits due to this) should not be dismissed too readily.

You just described how the Space system was designed! Woot! 10 points for you!

Err… you've just defined a deadly bug.
The server eating CPU and lagging because of too many ships is a performance problem.
Crashing or complete hanging is a deadly bug.

I think what he meant was that since it's only happening when 200+ ships are involved in a fight all at the same time it's not that big of a deal. I'm assuming that his mud doesn't often (if ever) have 200 ships in a single battle all at the same time. I could be mistaken on that and if so lemme know cause I would LOVE to be in a space battle that big.

I don't consider it deadly because we rarely have battles that big. But even with that many ships in space, the MUD is noticably laggy and if they engage in combat..boom. This happens every once in a blue moon, but it does reveal how inefficient the space system is.

What does the combat look like?

Screenshots/logs plz. thx.

-Crat
http://lpmuds.net

Very spammy. I don't really have any logs off-hand.

I play pilots on LotJ, and.. uh.. a battle with 200+ ships..


You would NOT want to be in that battle, trust me. Your client would likely disconnect you due to spam, and it'd be a bitch trying to control all those ships at once through the battlegroup.

And the MUD would probably crash :)

I just played in that capitalgame you hosted with the new Squadron system and the fixed battlegrouping.. quite a feat, indeed, because if I recall correctly, the Battlegroup system was bugged to hell with targeting
and whatnot.

The space system is still very inefficient :)