I found a way to dig out Neutronium

[alexius_92 5]

All you need is Super Productive duplicant with tier 3 digging and some luck

https://www.youtube.com/watch?v=oU-BxSBGSNg

 

Sandbox Super Productive Test.sav

[Gurgel 1903]

Irresistible force meets unmovable object...     A nice bug!

Just do not dig the bottom layer, dupes falling out of the world will probably crash the game. 

[alexius_92 5]

2 minutes ago, Gurgel said:

Irresistible force meets unmovable object...     A nice bug!

Just do not dig the bottom layer, dupes falling out of the world will probably crash the game. 

It's not a bug, it's a feature. I hope they won't fix that. I have some plans for that.

[Soulwind 290]

Have to disagree there.  That definitely looks like an unintended side-effect (i.e. bug). 

If it was deliberate, then it wouldn't be just a random chance of it working.

Neutronium is marked as Special / Immeasurable / Impenetrable for a reason.

Edit:  still nice find there

Edited September 4 by Soulwind

[nessumo 40]

2 hours ago, Gurgel said:

Just do not dig the bottom layer, dupes falling out of the world will probably crash the game. 

Will they?

[Gurgel 1903]

1 minute ago, nessumo said:

Will they?

I think I read a bug report about this some time ago...

1 hour ago, Soulwind said:

Have to disagree there.  That definitely looks like an unintended side-effect (i.e. bug). 

Definitely a bug, there is not even a need to discuss that. But the spirit of the cool people here is "If it is there, USE IT!"

[sheaker 61]

As I remember it was mentioned already. You should also get a lot of skill points after that.

[Lbphero 2586]

that is... awesome!!

[Zarquan 1006]

On 9/4/2020 at 10:47 AM, Gurgel said:

Definitely a bug, there is not even a need to discuss that. But the spirit of the cool people here is "If it is there, USE IT!"

I would tend to disagree with this interpretation.  Generally, when debates of "unfair exploits" show up, the argument is about whether aspects of the physics that don't make sense in the real world should be used.  In this case, the stated purpose of neutronium is to not be diggable, so this is definately a bug.

Edited September 7 by Zarquan

[Tsabo 29]

On 9/6/2020 at 2:59 AM, Zarquan said:

I would tend to disagree with this interpretation.  Generally, when debates of "unfair exploits" show up, the argument is about whether aspects of the physics that don't make sense in the real world.  In this case, the stated purpose of neutronium is to not be diggable, so this is definately a bug.

Have to disagree with this, the Gravitas lore is full of discussions on how to remove neutronium. There's more ink spilled in game on diggable neutronium than there is on diggable granite.

P.S. I've been irrationally annoyed at the name "neutronium" since I first read it. Lore-wise the material isn't even supposed to be matter, it's a warped space-time by-product of time-travel. Call it "Chronium", "Temporium", or something.

Edited September 7 by Tsabo

[mathmanican 3326]

Try the bug. Watch your dupe skill level hit max int level. Assign them every job and watch their morale die with tons of skill points to burn. Then scrub them in the skill scrubber only to see more bugs ensue. It's all been well documented in the bug tracker. Disasters await you if you head this route.

Is something(s) in this process bugged? I'll let you decide.

[Gurgel 1903]

3 hours ago, mathmanican said:

Try the bug. Watch your dupe skill level hit max int level. Assign them every job and watch their morale die with tons of skill points to burn. Then scrub them in the skill scrubber only to see more bugs ensue. It's all been well documented in the bug tracker. Disasters await you if you head this route.

Is something(s) in this process bugged? I'll let you decide.

I think there is also some sloppy coding in there. Skill level should not go to max_int, that looks like some bad use of the "special value" idea. Probably a -1 that goes into an unsigned int. Clearly not something that is supposed to happen.

[Zarquan 1006]

21 minutes ago, Gurgel said:

I think there is also some sloppy coding in there. Skill level should not go to max_int, that looks like some bad use of the "special value" idea. Probably a -1 that goes into an unsigned int. Clearly not something that is supposed to happen.

My thinking is that it isn't that the dupe's stat is set to max_int when they mine neutronium, but instead they completed a task that should have taken them an extremely long time and it gives the superproductive dupe them XP equivalent to working for that time. 

Since, as far as I can tell, the devs do not currently intend for dupes to be able to mine neutronium, I doubt they put in special code to handle the skill gain.  I think that it is probably a stop-gap that the skill points don't overflow when they mine the neutronium, where the game doesn't let the skill points overflow due to XP gain.  And it would make perfect sense for that stop-gap to not exist in the skill scrubber, as you should never be able to reach that number of skill points anyway.

Edited September 7 by Zarquan

[Gurgel 1903]

4 hours ago, Zarquan said:

My thinking is that it isn't that the dupe's stat is set to max_int when they mine neutronium, but instead they completed a task that should have taken them an extremely long time and it gives the superproductive dupe them XP equivalent to working for that time. 

That should not give them the max_int value, but would wrap and give them some arbitrary value. As they are getting max_int, it likely is a set value, not a calculated one. Of course, they could have done the calculation in double and then do a text of the form

if (x > max_int) {

   s = max_int;

} else {

  s = (int) x;

}

 

I would still call that "sloppy coding"  

Not that bad on the coding side, but an error flow would be better, IMO. 

Edited September 7 by Gurgel

[Zarquan 1006]

5 hours ago, Gurgel said:

That should not give them the max_int value, but would wrap and give them some arbitrary value. As they are getting max_int, it likely is a set value, not a calculated one. Of course, they could have done the calculation in double and then do a text of the form

if (x > max_int) {

   s = max_int;

} else {

  s = (int) x;

}

 

I would still call that "sloppy coding"  

Not that bad on the coding side, but an error flow would be better, IMO. 

My bet is that it's more like

if (x != max_int) x++ 

Or

if (xOrig > x) x = max_int

I would argue that these are both reasonable contingencies to prevent a random xp glitch from rendering a dupe useless.

Edited September 7 by Zarquan

[Gurgel 1903]

1 hour ago, Zarquan said:

My bet is that it's more like

if (x != max_int) x++ 

Or

if (xOrig > x) x = max_int

I would argue that these are both reasonable contingencies to prevent a random xp glitch from rendering a dupe useless.

First one is unlikely, at least for the neutronium case. Unless they really take a few seconds to count up to the max.

2nd one is a hack that is not really any better than my version (given that this is a _rare_ calculation), but does the same and can be used with arbitrary, same-type addition. It looks very likely they do something like this. But, if they do something like this, they could instead go into an error-flow, as this is _not_supposed to happen in normal operation. I am not sure doing defensive coding is the right decision here, I think having the error would be better.

Side note: Of course, the real reason for these bizarre constructs is that C has no overflow/underflow detection, while the CPU registers actually give you that for free. A long-standing design defect. 

Edited September 7 by Gurgel

[Zarquan 1006]

1 hour ago, Gurgel said:

2nd one is a hack that is not really any better than my version (given that this is a _rare_ calculation), but does the same and can be used with arbitrary, same-type addition. It looks very likely they do something like this. But, if they do something like this, they could instead go into an error-flow, as this is _not_supposed to happen in normal operation. I am not sure doing defensive coding is the right decision here, I think having the error would be better.

I would argue the second one makes perfect sense.  I believe I have used that exact line if I was expecting overflow to be a possibility.  I would also argue that it is better than your solution because it doesn't involve using doubles and type conversion.  This just detects overflow and corrects for it.

I agree that it is stupid that some languages don't automatically detect overflow.

Edited September 7 by Zarquan

[Gurgel 1903]

26 minutes ago, Zarquan said:

I would argue the second one makes perfect sense.  I believe I have used that exact line if I was expecting overflow to be a possibility.  I would also argue that it is better than your solution because it doesn't involve using doubles and type conversion.  This just detects overflow and corrects for it.

The second one comes with a potential surprising behavior: It stops working as intended if you accidentally trigger coercion of any kind. Mine is just inefficient but has no potentially surprising behavior. Probably comes because I am used to write security-critical software. If you can assure no coercion, the second solution works fine.

27 minutes ago, Zarquan said:

I agree that it is stupid that some languages don't automatically detect overflow.

Because C does not have it, almost all other languages do not have it either, because their run-time systems are based on C or they are intended to be able to be compiled to C. The one exception I know is Python, which promotes integers to long-numbers instead of having them wrap.

And because of that historic design limit in C, all numeric code that needs to deal with over-/underflow is either non-portable (because it requires a tiny bit of assembler code) or not efficient (because it requires using larger numbers or additional checks). It really is a shame, the respective bits are there in every CPU I know, even the Intel 4004 has them. I guess this is a left-over from some really early "big iron" CPU designs that did not check for over-/underflow or where that was more expensive than doing calculations without. 

[psusi 272]

On 9/7/2020 at 7:36 PM, Gurgel said:

And because of that historic design limit in C, all numeric code that needs to deal with over-/underflow is either non-portable (because it requires a tiny bit of assembler code) or not efficient (because it requires using larger numbers or additional checks). It really is a shame, the respective bits are there in every CPU I know, even the Intel 4004 has them. I guess this is a left-over from some really early "big iron" CPU designs that did not check for over-/underflow or where that was more expensive than doing calculations without. 

The overflow bit is there but checking it after every operation takes time, which is why C opted not to do so.  I believe there were some CPUs that instead of setting a flag on overflow you had to go check, would raise a fault instead ( like divide by zero ), which is why technically C leaves the results undefined.

[Gurgel 1903]

2 hours ago, psusi said:

The overflow bit is there but checking it after every operation takes time, which is why C opted not to do so.  I believe there were some CPUs that instead of setting a flag on overflow you had to go check, would raise a fault instead ( like divide by zero ), which is why technically C leaves the results undefined.

Actually, you do only need to check that flag if the code does. Otherwise you ignore it. But historic CPUs that would do this different are probably the reason here.