First of thanks to both of you for responding to me on this.Nobody has an issue with you creating a game that tries to achieve the same thing as StarMade. No one has a problem with people creating new games. Where there is an issue, is, if you reverse engineered StarMade, slightly altered a few things and started selling/offering it off as your own. Go ahead and make a StarMade clone if you wish, just don't use our assets to do it. There are games very similar to StarMade out there right now, if I were to start a new game, personally I wouldn't choose to do a StarMade clone, there are already so many games in development that are trying to achieve the same thing or variations of it.
You could do it with any game, if you wanted to create a game like Elder Scrolls but open source, you could. As long as you didn't go using their assets to do so.
If you do use our assets, like any other company, we'd take issue with it.
I'll give you some examples:
Modding StarMade and offering that content for free: Good.
Creating your own game that tries to achieve the same things as StarMade, but does not use any of our assets: Good.
Reverse engineering StarMade, using all our hard work and owned materials, passing it off as another game/making public: Bad.
Advertising your own game as a StarMade 2 or open source StarMade: Bad.
[doublepost=1491709612,1491707734][/doublepost]
The simple answer to all of your questions and points is that sometimes we remove/modify things that are intended, at times we remove/modify things that are unintended. Whether they are intended or not is irrelevant here and plays no part in the decision making process. We might mention that it was unintended and here are the reasons why we don't think it should stay, but we don't remove things simply because we didn't think it would happen.
The two big reasons we remove "features" (intended or not) are performance and balance.
Here's a simple process of how this happens.
Does it cause performance issues? Yes > Can it be fixed easily? No. > Is it integral to StarMade gameplay? > No. > Removed/Modified.
Does it negatively impact other or all aspects of gameplay? Yes > Can it be balanced to work with current and future plans > No. > Removed/Modified.
Intention/expectation takes no part here.
Sure, we don't always catch things, that's why we're in open alpha, our players are always going to catch the things we miss. We take their reports, suggestions and feedback seriously. The truth is StarMade is not balanced, we're very experimental, we're willing to take risks with adding and removing systems. We've done a lot of it since the very beginning, and you're going to keep seeing that until beta.
Not true at all. When docked reactors were first found (a very, very long time ago), we liked the creativity and the design expansion there. It wasn't intended as far as I remember. Docked reactors stayed for a long time; we didn't address them specifically because they seemed to add onto our system. Unfortunately, they were not performance friendly, there are a few things we could (and will still do) to address some of that, but there was always going to be a performance impact. Secondly, they were an illusion of choice and smart design. At a certain size, they were a necessity, we don't want an inelegant, performance heavy "feature" to stay in the game, so they were removed. Their existence was one of the bigger complaints about the game we receieved.
So, initially we did think docked reactors were a good thing. After seeing them being used and evaluated their impact, it was found that they were not adding as much to the game as they were taking away.
Oversights, exploits, bad features, all the same. You can call it whatever you want, what we're not saying is that the users are "bad" for making use of it. Some server owners might think that (fair enough), we're glad that people are showing what they can do with the game and what the consequences for that are. If you were to utilise performance killing "features" with the knowledge that they will negatively affect everyone's experience (like is true for so many of the things we remove/modify), then yes, that is quite bad.
The performance effects of docked beam reactors was much different than that of the upstream chained reactors. Yet, you all killed chained power supplies. I assumed chained reactors had more to do with lagg when breaking free. I didn't see any negative performance on my system from them and my keyboard literally displays each CPUs performance at the top.
Assuming that had more to do with the reactors breaking loose in combat. But that would have been nicer to say than tell me in the past its an exploit. That said there is a simple fix to them. Stop using directories to store stuff in use a virtual directory or file list to keep track of connects. Doing that and you can have multiple connects. Even simpler add a bit to the docked system that can be set to make it simply follow along with the ship such as designating it as hull vs ship vs turret. Then you never have to worry about such issues.
None of those are massively hard to change. The file system instead right now you search through directories and build a list of connections. I know this from testing and that stuff over about 100 directories or so gets cut off. You could simply pull the connection list in from a file and have all the connected entities stored in a single directory. That would save when loading not having to change directories to load each one.
Adding a single check flag to the entire docked structure is probably the easiest solution of them all. As long as the flag is set it continues the docked system in the same location to the entity it is docked to you already do that simply because you have a docked system. so 99.9% of the code already exists.
I think that is 3 simple solution I just came up with to prevent. lagg do to undocking.
But then again maybe it really was power because I tend to think easy stuff like that you guys in the development team are actually capable of coming up with and I am not probably any smarter than you guys. I might have more time programming but smart probably not.
Also if you do fix the file system as I suggest then you could have more than one connection between objects.