Implement a REAL fix for bug #1178

[Valiant70]

Lets go back to where this started, because I think we're coming at this from different directions.

This started when it became clear that the OP's suggestion boiled down to "You already know this is a problem, but I don't think you're fixing it fast enough!" I responded with "Well it is an alpha, if the presence of bugs bothers you that much, might not wanna play alphas." Which went to "Well if everybody thought that bugs would never be reported and they wouldn't know anything was wrong until it went gold!" I responded with the idea that its more important to the devs to see duplicate threads by different new people than it is to see the same threads from the same people over and over again, because it reflects the playstyle of the majority better (and hence the importance of getting it fixed).

At which point you jumped on me for speaking on behalf of the majority for saying that the higher the percentage of people reporting the same issue indicated more people were running into it, and hence greater indication that it affected the majority of players instead of a very vocal minority.

That it is more important from a developer's standpoint that X% of the userbase is reporting it as being a significant issue than it is that the same dozen people have been saying it for months if no one else has ever reported it as being a problem.

Do you see where I am trying to come from with this? A majority of people reporting something as a problem is a better indicator of it actually being a problem than a small minority that just keeps bringing it up.

Non sequitur. It is highly likely that most people are assuming that explosive is simply badly designed and mostly useless, when in fact it is bugged. If more people realized that this IS a bug, more people would make noise about it. You ARE erroneously speaking for the majority in saying the majority don't care. Most appear to be too busy screaming about missiles being OP instead of trying to bring other things up to par. In fact though neither of us know for sure what the majority think. All we know is how much noise different topics make.

 

[Edymnion]

All we know is how much noise different topics make.

But again, that was the point I was trying to make.

10 people making noise is a better indicator than 1 person making an equal amount of noise.

You jumped on me for daring to speak for the majority, when that is exactly what I'm reading you as saying you are doing. That one person bringing the same topic up over and over again is speaking on behalf of the majority, and that that is more important than the actual majority speaking for itself.

Thats what I'm trying to get at. I'm saying to let the majority speak for itself, not a handful of people trying to speak for them.

The devs are aware of the problem. It doesn't do anyone any good if the same group of people just keep saying "You're not working fast enough!" as if they have the slightest clue what the actual behind the scenes priority list is. They're not going to work on it any faster just because the same people keep pestering them. They will work on it faster if a whole lot of people poke them about it though.

 

[Valiant70]

However, I think this problem is far more consequential than it's being made out to be.

 

[Ithirahad]

As a computer programmer by trade, I can perfectly understand the "Oh this is going to take more work to fix than I have time to give right now. Its not a showstopper, just document it and come back to it later."

I mean, we all have our personal wants, but there's always a side we don't see.

The problem isn't fixing it, the problem is that it was never put into the game in the first place; a placeholder system was put into the dev builds and it was never replaced. It would be rather like (to use the current update cycle as an example) putting Rail Rotators into the release, but having them not function as anything but static
"rails," putting a note in the shop saying they don't work, moving on to implementing shipyards, and not doing anything about the missing Rotator functionality for the next who-knows-how-long. "Oh, this is going to take more work to fix than I have time to give right now. Its not a showstopper, just document it and come back to it later" sounds more like the current status of the missile explosion damage issue or maybe the engine's transparency bugs, which both bug me but I understand that nothing can be done at the moment. Missile explosion damage is a little OP but config tinkering can mostly offset it, and the transparency bugs don't really affect gameplay too much at the moment and are damn near impossible to fix... If missiles already exist and work to some extent I see no reason why the Explosive effect is somehow impossible or too extremely hard to implement in some more reasonable form.

That it is more important from a developer's standpoint that X% of the userbase is reporting it as being a significant issue than it is that the same dozen people have been saying it for months if no one else has ever reported it as being a problem.

Do you see where I am trying to come from with this? A majority of people reporting something as a problem is a better indicator of it actually being a problem than a small minority that just keeps bringing it up.

Um, I don't know, but I'm willing to bet that many people are bothered by this issue, we're just not saying anything because we've gotten the sense that it's futile to even try as far as this issue goes at this point.

 

[Valiant70]

Um, I don't know, but I'm willing to bet that many people are bothered by this issue, we're just not saying anything because we've gotten the sense that it's futile to even try as far as this issue goes at this point.

Pretty much. I finally got so frustrated that I made this thread.

 

[Psy_commando]

It's not a bug, it's completely intended that it is for now capped at 1. Once the missile damage system is reworked and is more accurate, the same system can be used for cannons and beams, until then you'll have to wait.

Do you have a source/link/citation for that ?
Or you're just throwing hypotheses rudely around, passing them as fact, using underlined text ?
You gotta clarify.

Lets go back to where this started, because I think we're coming at this from different directions.

This started when it became clear that the OP's suggestion boiled down to "You already know this is a problem, but I don't think you're fixing it fast enough!" I responded with "Well it is an alpha, if the presence of bugs bothers you that much, might not wanna play alphas." Which went to "Well if everybody thought that bugs would never be reported and they wouldn't know anything was wrong until it went gold!" I responded with the idea that its more important to the devs to see duplicate threads by different new people than it is to see the same threads from the same people over and over again, because it reflects the playstyle of the majority better (and hence the importance of getting it fixed).

At which point you jumped on me for speaking on behalf of the majority for saying that the higher the percentage of people reporting the same issue indicated more people were running into it, and hence greater indication that it affected the majority of players instead of a very vocal minority.

That it is more important from a developer's standpoint that X% of the userbase is reporting it as being a significant issue than it is that the same dozen people have been saying it for months if no one else has ever reported it as being a problem.

Do you see where I am trying to come from with this? A majority of people reporting something as a problem is a better indicator of it actually being a problem than a small minority that just keeps bringing it up.

But, this isn't the bugfix sub-forum, this is the suggestion sub-forum. If their suggestion is to actually focus on this issue, when no apparent changes were made for a long time, that's a valid suggestion, wouldn't you agree ?

No matter how many times they repeat it, if it hasn't been changed, that's still valid. Of course its slightly rude, but that's part of the whole making a game in early access experience. If its not them, its going to be others.

Also, I think you somewhat come across as trying to appease for the sake of appeasing, when there isn't any actual harm being done. And I think it somewhat contributes to the tensions and confusion here.

And, appealing to the majority isn't a surefire indicator of something. It all depends on the case.
Not to mention StarMade offers singleplayer and multiplayer gameplay, and both are different in the way issues like this may affect players. Add to that the fact that the mutliplayer experience varies greatly from server to server, along with some server admins possibly mitigating the issues on their own initiative.

That would mean a lot of people possibly wouldn't really be affected enough by this to take the time to say anything. Perhaps they just decided that going along with all this was tolerable for them. Or maybe they just gave up on the game before expressing their feelings on this issue. We can't really know those things for sure.

Its the dev's call to judge if this might be important enough to prioritize it. But seeing as most of the game is basically about shooting stuff and building stuff that gets shot at (in its current state at least), its not unreasonable to believe that anything enhancing that part of the game might just be at least moderately popular with a significant part of the player base?

Additionally, a big part of every fan-bases and customer bases doesn't gets involved into the actual official community forums/ or even community forums at all.
And out of those that do get involved, its possible that a big group of like-minded people would gather around that community, and they still possibly wouldn't share the opinion of the silent majority.

 

[Lancake]

Do you have a source/link/citation for that ?
Or you're just throwing hypotheses rudely around, passing them as fact, using underlined text ?
You gotta clarify.

I'm the tester that processed that bug report. I did not mean to "hypothese rudely", I underlined to lay emphasis on those words. If I came over rude towards you then I apologize.

http://bugs.star-made.org/issues/1178 says it's not implemented for now. And I don't have a source/link/citation for the rest that I said, but it's known that the missile damage system is inaccurate (and old), I've seen in chat that there are plans to rework it and that also involves the explosive effect on the cannons/beams (since they use the same system).

 

[Valiant70]

I'm the tester that processed that bug report. I did not mean to "hypothese rudely", I underlined to lay emphasis on those words. If I came over rude towards you then I apologize.

http://bugs.star-made.org/issues/1178 says it's not implemented for now. And I don't have a source/link/citation for the rest that I said, but it's known that the missile damage system is inaccurate (and old), I've seen in chat that there are plans to rework it and that also involves the explosive effect on the cannons/beams (since they use the same system).

What puzzles me is the fact that Java is object oriented, so the explosion for both missiles and cannons could use or extend the same class or classes, requiring little change to anything but the explosion itself. Maybe there's some stuff that needs to be restructured on a larger scale that I can't even speculate about as I haven't seen any of the source code.

 

[Lancake]

What puzzles me is the fact that Java is object oriented, so the explosion for both missiles and cannons could use or extend the same class or classes, requiring little change to anything but the explosion itself. Maybe there's some stuff that needs to be restructured on a larger scale that I can't even speculate about as I haven't seen any of the source code.

Like I mentioned before, the same system could be used but it is not optimized for fast firing weapons. max fire rate per group is 10 shots per second. Also giving cannons and beams the same inaccurate system would make punch through and piercing obsolete.

 

[Valiant70]

it is not optimized for fast firing weapons.

Ah, that makes sense. Is this related to the fact that two missiles exploding near each other stack into a single explosion?

 

[Lancake]

Ah, that makes sense. Is this related to the fact that two missiles exploding near each other stack into a single explosion?

Don't think so, still, if you want to see the results of fast firing weapons, change your block behavior config, put the cool-down of a missile on 0.1 seconds and use 100 ish groups. Fire away at something really solid and you'll see how using that system on cannons/beams is not advised.

 

[NeonSturm]

What puzzles me is the fact that Java is object oriented, so the explosion for both missiles and cannons could use or extend the same class or classes, requiring little change to anything but the explosion itself. Maybe there's some stuff that needs to be restructured on a larger scale that I can't even speculate about as I haven't seen any of the source code.

You can only extend 1 parent class for each child class.

If you want 2 (TreeNode and Physics for example) you may get a collision of properties, variables and function-names.
At least the peoples which designed Java thought that.

The only real solution is to implement (not extend) a second class.
This is nothing else than setting requirements for some public stuff to exist ---- or copy+pasting your code and get a duplicate.

There is another solution:

Element . (E's) TreeNode . parentTreeNode . (parent TNs) getElement
Physics . getElement . TreeNode . parentTreeNode . getElement . Physics
OR
Physics . (P's) getElement . (E's) TreeNode . getParentElement . (parent E's) Physics
Element . TreeNode . getParentElement . TreeNode . getNextElement . TreeNode​

The problem : Each reference takes time to compute.

First option : Object orientated, but requires 5 hops to get to the parent-Element's Physics.
Second option : You only need 4 hops, but it's a lot slower to traverse a tree.

All other options create duplicates of the same code and require more effort for linking / unlinking.

Do you see this syntactic problem? No syntax sugar for that AFAIK (Glad if somebody could help me find some syntactic sugar for this)​

It would be a lot easier+faster if the language wouldn't enforce Object-Orientated onto you.

 

[Valiant70]

You can only extend 1 parent class for each child class.

If you want 2 (TreeNode and Physics for example) you may get a collision of properties, variables and function-names.
At least the peoples which designed Java thought that.

The only real solution is to implement (not extend) a second class.
This is nothing else than setting requirements for some public stuff to exist ---- or copy+pasting your code and get a duplicate.

There is another solution:

Element . (E's) TreeNode . parentTreeNode . (parent TNs) getElement
Physics . getElement . TreeNode . parentTreeNode . getElement . Physics
OR
Physics . (P's) getElement . (E's) TreeNode . getParentElement . (parent E's) Physics
Element . TreeNode . getParentElement . TreeNode . getNextElement . TreeNode​

The problem : Each reference takes time to compute.

First option : Object orientated, but requires 5 hops to get to the parent-Element's Physics.
Second option : You only need 4 hops, but it's a lot slower to traverse a tree.

All other options create duplicates of the same code and require more effort for linking / unlinking.

Do you see this syntactic problem? No syntax sugar for that AFAIK (Glad if somebody could help me find some syntactic sugar for this)​

It would be a lot easier+faster if the language wouldn't enforce Object-Orientated onto you.

I must have written that when I was pretty tired! LOL There's no need to extend or implement anything, really. My best guess is that an explosion is its own class which is instantiated with particular properties on impact depending on the weapon. (At least that's how I'd do it) The simple solution would be for beams and cannons to spawn explosions on impact but as Lancake said, there's a problem with the current explosion code that prevents this from working well, and that's what needs fixing. I.e. we need a new explosion class.

 

[Psy_commando]

I'm the tester that processed that bug report. I did not mean to "hypothese rudely", I underlined to lay emphasis on those words. If I came over rude towards you then I apologize.

http://bugs.star-made.org/issues/1178 says it's not implemented for now. And I don't have a source/link/citation for the rest that I said, but it's known that the missile damage system is inaccurate (and old), I've seen in chat that there are plans to rework it and that also involves the explosive effect on the cannons/beams (since they use the same system).

Thanks for clarifying! And sorry for the remark.
I'm just getting a little frustrated with people that sounds like they're coming up with stuff out of nowhere these days ^^;

I must have written that when I was pretty tired! LOL There's no need to extend or implement anything, really. My best guess is that an explosion is its own class which is instantiated with particular properties on impact depending on the weapon. (At least that's how I'd do it) The simple solution would be for beams and cannons to spawn explosions on impact but as Lancake said, there's a problem with the current explosion code that prevents this from working well, and that's what needs fixing. I.e. we need a new explosion class.

Normally, you'd want to avoid construction, memory allocation, and search algorithms, and other costly algorithms as much as possible. Creating explosion objects like that pretty much implies all of those.
Firing weapons is often handled using events and events managers, and resources are recycled as much as possible. Well, actually in the 2-3 game engines I worked with, they all worked that way..

Usually, in non-voxel engines it works pretty much that way:
You create a projectile event by firing a gun, its sent to the server. The server does a raytrace/hull trace, and see if it hits anything. If it does, it gets the entity it hit, then it runs the projectile's "damage" code, along with the entity's "on hit" code. And the server also dispatches client-side effects events, for the impact sound and effects.
A good chunk of the process must be the same in voxel games like starmade though.

But, anyways, if you take what Lancake said into account, along with some of the current issues, it all supports the possibility that the game has issues with blocks updates, rather than it being just an explosion thing. Just look at "planet eaters" putting a huge strain on the system. Or also at how blocks just seem to turn into "ghosts blocks" when you mine asteroids for a while. Since explosions destroy several blocks several times in a short time span, that's probably all tied together.

Possibly using a 2-3 levels priority queues system for the block update queue, along with actually making the armor blocks tougher, could minimize the issue ? Or maybe just having blocks enter a simple transition phase after being actually destroyed, and until the actual block update takes place? Like visually turning into a burnt pile of slag kind of block perhaps..

Of course, I got no ideas whether they already handle things that way, or if they're using something better..