Jump to content

Miraculous Rocket without engine :)


Recommended Posts

I never think before how hot rocket exhaust is.

I build research rocket

Petroleum Engine, 5 thrusters, 5research modules. And this combination of 5 thrusters was surprisingly hot. So hot, it melts down steel engine.

Strangely, game check for existence of fuel tank (even if you do not need liquid fuel), but do not check for existence of engine. So, my rocket make dozen of automated trips before I see the problem.

Now I know, rocket exhaust is certainly hotter than 2430°C

How hot it is?

Does it depends on number of solid thrusters?

Is it possible to melt Abyssalite this way?

How people cool down their rockets, to prevent such spectacular meltdown in future?

Link to comment
Share on other sites

4 hours ago, Prince Mandor said:

5 thrusters

I wouldn't call that a "miraculous Rocket without engine". That would be "miraculous boat moving without engine", which is a silly name for a rowboat. Your rocket has thrust, hence not a miracle that it can move.

Now if the fuel tank acts like there is a rocket and grants the same speed/range, then you encountered a bug, which should be reported.

Link to comment
Share on other sites

32 minutes ago, Nightinggale said:

I wouldn't call that a "miraculous Rocket without engine". That would be "miraculous boat moving without engine", which is a silly name for a rowboat. Your rocket has thrust, hence not a miracle that it can move.

Now if the fuel tank acts like there is a rocket and grants the same speed/range, then you encountered a bug, which should be reported.

This rocket have 0 need for petroleum - it have all it thrust from thrusters. But game doesn't allow rocket with petroleum engine but without liquid tank. So, I put it in construction. 

Thing I cannot imagine is a heat from exhaust was enough to melt steel. And petroleum engine just melted away. But game, so vigilant in demanding empty petroleum tank, doesn't check for engine.

I'm not sure which part is a bug - engine too flimsy for its own exhaust, demand for not needed empty fuel tank or not checking for existence of not needed engine :)

And no, I have lots of more annoying bugs reported, without devs reaction. So, I postpone reporting after moment they fix lot of reported earlier

Link to comment
Share on other sites

42 minutes ago, Prince Mandor said:

Thing I cannot imagine is a heat from exhaust was enough to melt steel. And petroleum engine just melted away.

Real life rocket engines are quite good at melting themselves. They need a constant flow of liquid oxygen, which they pipe around the engine for cooling before it's is released into the flame. Without this cooling, the engine will melt within seconds.

Being able to melt a rocket engine ingame if you have a poor setup doesn't seem unrealistic.

44 minutes ago, Prince Mandor said:

I'm not sure which part is a bug - engine too flimsy for its own exhaust, demand for not needed empty fuel tank or not checking for existence of not needed engine :)

Clearly the latter.

45 minutes ago, Prince Mandor said:

And no, I have lots of more annoying bugs reported, without devs reaction. So, I postpone reporting after moment they fix lot of reported earlier

Maybe you should review what you report and how you write it. Looking through the bug reports (in general, I didn't look up yours), some are like quite literally impossible to fix based on the included information. Most eyecatching are "doesn't work on my GPU, but I won't tell which GPU I have, only that it's good".

When writing a bug report, write it short and precise while at the same time include as much information as possible. It seems they do read all of them, but they don't have time to fix all bugs the same day. Speaking from personal experience (not ONI specific), people report bugs, which aren't even there. My favorite is "window opened inside another window", which was closed with "you have two window on top of each other. Move one if you want to look at both at the same time". Another good one is "nothing moves when I load a savegame", which turned out to be a paused game. Because some people report "bugs" like that, spending hours trying to reproduce every single bug based on poor descriptions doesn't seem like a good use of development time. However if you add a savegame and write "load savegame. Click building and click this button. The game will then crash or whatever else goes wrong". This can be tested very quickly, which makes it much more likely to be fixed.

In your specific case, add your savegame and write that the rocket will melt the petroleum engine and that the rocket can fly even after that happens and without spending fuel. Short and precise and you don't have to give details on your setup because they can figure that out from the savegame.

Link to comment
Share on other sites

2 minutes ago, Nightinggale said:

Real life rocket engines are quite good at melting themselves. They need a constant flow of liquid oxygen, which they pipe around the engine for cooling before it's is released into the flame. Without this cooling, the engine will melt within seconds.

Being able to melt a rocket engine ingame if you have a poor setup doesn't seem unrealistic.

Clearly the latter.

Maybe you should review what you report and how you write it. Looking through the bug reports (in general, I didn't look up yours), some are like quite literally impossible to fix based on the included information. Most eyecatching are "doesn't work on my GPU, but I won't tell which GPU I have, only that it's good".

When writing a bug report, write it short and precise while at the same time include as much information as possible. It seems they do read all of them, but they don't have time to fix all bugs the same day. Speaking from personal experience (not ONI specific), people report bugs, which aren't even there. My favorite is "window opened inside another window", which was closed with "you have two window on top of each other. Move one if you want to look at both at the same time". Another good one is "nothing moves when I load a savegame", which turned out to be a paused game. Because some people report "bugs" like that, spending hours trying to reproduce every single bug based on poor descriptions doesn't seem like a good use of development time. However if you add a savegame and write "load savegame. Click building and click this button. The game will then crash or whatever else goes wrong". This can be tested very quickly, which makes it much more likely to be fixed.

In your specific case, add your savegame and write that the rocket will melt the petroleum engine and that the rocket can fly even after that happens and without spending fuel. Short and precise and you don't have to give details on your setup because they can figure that out from the savegame.

I was programmer in game development. So, yes, I know, but no If they do not have time for magic gas transformation, and do not have time to fix screen scrolling, then I do not bother them with some melted engine check. I can happily play this game for years, flying rockets with melted engine

Link to comment
Share on other sites

1 hour ago, Prince Mandor said:

I was programmer in game development.

Good, then make a mod, which fixes the issue. Once you know precisely how to fix it, then post a bug report where you link to the source code of your mod, preferably with commented code explaining precisely what you are doing and why. When they know precisely where the bug is, can easily reproduce it and are given a working fix, then they are way more likely to fix it. In fact Klei has currently fixed 100% of what I reported when I have pointed to specific lines in the source code.

Naturally you don't actually have to fix the bug yourself since it's not your game. However if you don't and you don't even bother to report the bug through proper channels, then don't expect it to be fixed.

Link to comment
Share on other sites

36 minutes ago, Nightinggale said:

You don't even bother to report the bug through proper channels, then don't expect it to be fixed.

I just wait a bit. Until developers at least acknowledge previous, more important bugs in their "proper channel" :)

Really, important bugs stay there in "pending" state for more than a year. 'Proper channel' just doesn't work anymore

Link to comment
Share on other sites

3 hours ago, Nightinggale said:

Klei has currently fixed 100% of what I reported when I have pointed to specific lines in the source code.

I'm glad they've fixed yours.  However, please be careful with your responses.  You haven't been around for 2 years.  There are plenty of people who have done precisely this, over the last two years, to no avail (yes, decompiling code, writing fixes, pointing the exact spots in code, and trying to get it fixed). These things have been done, and often the response has been dead silence. There is a history you don't know. 

It's great to see someone with a fresh optimistic perspective. Keep up the great work. I'm loving the things your adding in. But please also refrain from telling others they are not properly making bug reports.

6 hours ago, Prince Mandor said:

I have lots of more annoying bugs reported, without devs reaction.

The above quote is not an isolated incident, and the reports that are ignored have been all over the place (from great bug reports, to bad bug reports). The devs met specifically a few months back to address this (shortly before you joined on April 14th).  Here is @JoeW's response (it may help you when they don't fix something you suggest...):

Spoiler

------Apr 1, 2019 -----------------------------------------------------------------------

The way we look at bug reports is that they are there so that we may we sift through them and fix them as appropriate based on priority and what were working on. If they are there, you know we know about them. But it's not meant to be a channel of communication. 

All that being said, it seems like there is a disconnect here that we need to address. 

We're going to meet up tomorrow and figure some stuff out. Stay tuned. 

-------Apr 2, 2019 -----------------------------------------------------------------------

Ok - so we met for about an hour and a half today. 

First I wanted to clarify some things. As some of you have pointed out, we tend to communicate by doing more than by saying. This is for multiple reasons but at the heart of it, it's a resource issue. Responding to something means a lot more than I think a lot of you may realize. When an issue is reported it takes time to read and investigate. If the issue can be reproduced it may have multiple components responsible for the issue being fixed and even then there are knock on effects of cascading issues that result from those changes. 

All these things come into play when thinking about whether a bug should be fixed or prioritized for a different time. While often times a person who reports an issue may think the bug is going to get fixed asap, we generally approach it by prioritizing bugs based on the nature of the issue, how it impacts the community and what resources we have to address it. That's all a normal part of our every day, but communicating this stuff takes a lot of extra time. We agree that we can do better, so we are going to adjust, but we have to find a good balance there. 

In addition to this as was mentioned earlier in the thread, we do not like to participate directly in conversations because it changes the direction of the conversation. We don't generally take feedback as exactly what is written, but we take the conversation and try to dissect it and figure out where it lines up with what we are trying to achieve. You may have an absolutely wonderful idea, but we disagree with it's execution. Or a horrible idea with a nugget of brilliance. We need those conversations to decipher these things, but when we're involved it very often becomes definitive and creative conversation does not take place.

I want to be clear here. And I am not mincing words because I think it's important. This has been our approach for the last 7 years and it has worked very well for us. BUT - there have certainly been times in the past where the community has needed to remind us that we need to be a bit more visible and I definitely think there is room for us to be more communicative here. 

The team is going to pop in more often and let you know more that we're around. They read these forums every single day and I can tell you personally that we very much care and appreciate your feedback. We do not have the resources to respond to everything, or even a lot of posts, but the ONI team is going to be working toward making sure you all know that we're here and we are taking all your suggestion, feedback and bug reports into consideration. 

Thanks everybody. 

 

Link to comment
Share on other sites

13 minutes ago, mathmanican said:

I'm glad they've fixed yours.  However, please be careful with your responses.  You haven't been around for 2 years.  There are plenty of people who have done precisely this, over the last two years, to no avail (yes, decompiling code, writing fixes, pointing the exact spots in code, and trying to get it fixed). These things have been done, and often the response has been dead silence. There is a history you don't know. 

:shock: Maybe I have been lucky, or maybe it's because bug reports are treated differently close to going out of early access or something else. Also I have to point out that I have posted bug reports, which aren't specific in the code and that they do not have the same fine fixed rate.

18 minutes ago, mathmanican said:

But please also refrain from telling others they are not properly making bug reports.

Point well taken.

However my point really isn't about getting a high fixed rate of reported bugs. Instead it is about reporting the bugs you find and do the report as well as you can. What I see here is telling other people about the bug and then refusing to report it properly. I once experienced something like that. A coworker added a new feature. It required updating a part of the code I had written more than a year earlier. Now instead of telling me, either officially through the bug tracker or just telling me, he decided to gossip it to other people. 3 months later half the people knew and it became an issue because he had displayed that I'm lazy and not fixing bugs other people have known about for ages. I fixed it within 24 hours, but it was part of why the friendly work environment vanished and major part of why I left that place. It's horrible to be backstabbed like that on your professional pride and reputation.

That's why I say that if you want to make a topic out of some bug you find, do make sure Klei has a proper bug report. Going public about it, but making it important that Klei doesn't get informed through proper channels is neither nice or fair to Klei. In fact it could be borderline slandering.

So if you have a savegame, which highlights a bug, then give it to Klei with a short description of how to trigger the bug in the savegame. Locating the bug in the source code would be really nice of you and will increase the chance of an official fix, but it's optional. Just make sure you don't try to make an angry mob regarding a bug, which you haven't made sure Klei knows about.

 

As for the quote in the spoiler, thanks. It makes a lot of sense and I'm not surprised. However I missed it and it's nice to actually read it rather than assuming.

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

Please be aware that the content of this thread may be outdated and no longer applicable.

×
  • Create New...