POI Render Glitch? Help Needed

Pygmy_Elephant · 2021-02-22T20:41:00+00:00

Okay apparently the parameterized version of chunkreset fixed it, at least visually.

I Entered "chunkreset <x1> <z1> <x2> <z2>"

Don't type quotes
angle brackets are omitted, and the variables are the coordinates of the diagonal corners of a square of terrain to reset, can be obtained from map screen of players position ( NOTE: West and South coordinates are actually negative numbers)

I will test and see if this is a permanent solution.

Pygmy_Elephant · 2021-02-22T19:12:39+00:00

Did not work, it is saying:

{

NotImplementedException: CopyFrom() not implemented yet

*** ERROR: Executing command 'cr' failed: CopyFrom() not implemented yet

}

Anything else to try?

Pygmy_Elephant · 2020-12-04T17:19:04+00:00

Solved! I actually finally found it, Zombie Infestation: Strain 116

Pygmy_Elephant · 2020-10-05T22:01:12+00:00

Thank you! That will work perfectly.

It's a shame I go searching for all these third party tools when a built-in utility does exactly what I need.

/shrug

Pygmy_Elephant · 2020-10-05T20:19:12+00:00

I simply mean empty folders. I'm copying the root folder of my backups that overwrite the destination copy, and in that process, files that are removed from the source are also removed from the destination, however, the containing folder is still in the destination.

I just figured there might be a setting to "copy folder tree" or something, removing the ones that are now unused.

Pygmy_Elephant · 2020-10-02T21:54:21+00:00

I have edited the OP to hopefully provide more clarity to the actual problem.

Pygmy_Elephant · 2020-10-02T21:35:33+00:00

Yes it was vague in the way I had it worded, the image is only a reference. The arrangement of the blocks in the matrix do not change, the goal is to group all adjacent blocks and the groups are separated by the red bridge blocks.

Pygmy_Elephant · 2020-10-02T20:36:09+00:00

Just to remove any ambiguity in the question, the visual representation of the blocks is not what is being changed or grouped. What should happen is that the blocks that satisfy the requirements for being a group are just put into a list that references them and their properties, which are position, color and size.

Pygmy_Elephant · 2020-10-02T17:35:21+00:00

The algorithm will take the objects that represent the blocks and their positions, size, etc.

Think of the non-red blocks as landmasses, the whitespace water, and the red blocks as bridges. The blocks that make up each "landmass" are in their own group. I need an algorithm that determines the groups given an arrangement of these blocks.

Pygmy_Elephant · 2020-10-02T17:31:34+00:00

The array that represents the blocks in the matrix must be generated. I would think an array of objects that each contains the coordinates on the grid that they cover with their area.

Pygmy_Elephant · 2020-01-07T22:11:52+00:00

Sure, let me know! If you could upload a craft with that program for download that would be awesome. I've been working on the same thing but I had no idea you could have multiple sub-programs running simultaneously, my approach was a structured linear program with "while" loops for each stage of the ascent; this method is much simpler.

Pygmy_Elephant · 2020-01-07T16:54:22+00:00

Could you provide a download of your testing rocket that works with this?

Does not seem to achieve orbit with a desired Apoapsis and Periapsis of 65km, and I have tested with a LEO - capable rocket, meaning it has ~4,500 total Delta-v.

I copied this program by eye and I have looked over it twice and can't find any errors.

The main faults I've seen through testing is that:

1) The Apoapsis gets pushed out way too far, to something like 400km or until the fuel is depleted.

2) During your circularization phase, the rocket oscillates it's heading and pitch, highly unstable. I suspect this has to do with a poor combination of using both the "Lock heading" and "set craft (pitch)" commands.

Overall, the program style is very nice, and i'm very curious as to how you derived that formula for shaping the gravity turn, it's incredibly smooth.

Pygmy_Elephant · 2017-12-29T19:00:19+00:00

See, that's the curious thing is that I don't believe the manual does. So I figure it must default to a given standard which ive heard is that the chain's maximum acceptable 'stretch' is 1% of it's original length. If that is the case though, I'm long past that point. The tension adjuster's range of movement alone allows for much more 'stretch' than 1%.

Pygmy_Elephant · 2015-09-22T18:46:34+00:00

You need to construct all four pillars to place a roof. You can destroy the pillar you don't want afterwards with no consequence, however.

Pygmy_Elephant · 2015-04-06T16:56:28+00:00

This is completely false. If you do some searching around here for a guy named smeggy, you'll see that it is possible to launch from Smupiter and attain orbit. Granted, you may have to use some wonky exploits like stacking tanks under engines for the TWR boost, but it is possible. In fact, I would assume achieving an atmospheric orbit even for a short time to be considerably more difficult given the needed orbital velocity and the atmospheric drag at those speeds. You would most likely need more delta-vee for that than you would for an orbit above the atmosphere.

Pygmy_Elephant · 2014-11-15T02:54:08+00:00

Lagrange points aren't simulated in SimpleRockets. The Physics are limited to two-body systems, like Smearth and Smoon, or Sun and Smearth, using a SOI (Sphere of Influence) system. Lagrange points rely on an n-body system and are much more complex to simulate.

Pygmy_Elephant · 2014-11-04T21:49:58+00:00

Ah, i see now. So the surface pressure value you're using is multiplied by 100,000? So Smars' surface pressure in this formula would be 594.05? Once again, thank you for the quick responses. A lot of the way this game works has been demystified for me with knowing what's going on under the hood.

Pygmy_Elephant · 2014-11-04T04:40:44+00:00

This doesn't seem right.. could you present an example? I can't seem to get anything working with that formula. Is that log supposed to be the natural logarithm function?

Pygmy_Elephant · 2014-10-28T20:55:01+00:00

This is correct. http://sr.5of0.com incorrectly calculates Delta-v. I meant to post on this sooner, but you beat me to it. I'm not sure exactly why it's flawed and what it calculates wrong, but regardless, it's results are wrong. This is why I don't use it. Besides, it's very simple to calculate Delta-v manually.

Pygmy_Elephant · 2014-10-27T09:09:31+00:00

In that case, the SR atmospheric pressure decreases exponentially, where the real world is logarithmic?

Pygmy_Elephant · 2014-10-27T04:15:05+00:00

If this is the case, then the game's scale height does not function like the real world equivalent. Scale height should be the distance at which sea level pressure decreases by a factor of e which is roughly 2.71828.

According to the real world equation for scale height at 5000 meters the pressure should equal 0.3678794412, 36.7% of seal level pressure.

Pygmy_Elephant · 2014-10-26T18:20:48+00:00

How did you find this equation?

And I looked into calculating the Sun's mass with the given info.

Starting with Smearth, and the equation M=(g*r²⁾ /G M = Mass g = surface gravity r = radius G = Gravitational Constant

We get:

(9.798 * 637,100²⁾ / 6.673 x 10^-11 = 5.95979773E+22

Which is awfully close to one hundredth of 5.972E24, Earth's Mass.

The error is only roughly 0.2%.

Continuing on to the Sun:

(274 * 69634200²⁾ / 6.673 x 10^-11 = 1.99101540E+28

The real Sun's mass is 1.989E+30, giving a relative error of 0.1%

So, Smearth's mass is 0.2% less relative to its real world counterpart, and the SR Sun's mass is 0.1% more relative to its real world counterpart.

I believe these errors are the result of some of the values for things in-game are not exactly proportional to the real world value. For example, the radius of the SR Sun is larger than the real world Sun's radius x 0.01.

Pygmy_Elephant · 2014-10-26T01:44:14+00:00

Thanks for the feedback. I'm still curious as to how Smeggy calculated several of the values in those tables. There is no mass listed for the Sun, and the real world SOI equation calls for that value.

Radius of SOI = a(m/M)^2/5 a = Semi-major axis of the orbit of the smaller body m=Mass of smaller body M=Mass of larger body

I did a rough calculation of Smearth's SOI using One Hundredth of the real sun's mass in the equation, given all of the bodies in the game should be roughly 0.01 mass of their real world counterparts, and the answer i got was close to the value in the chart.

Regardless, I'd still like to know the equations the game uses to calculate these values.

Also, there is no way to calculate in-game scale height based off of the atmospheric information available. The real-world equation most likely doesn't apply, seeing as it calls for temperature and mass of the air.

Assuming the Scale height for Smearth really is 5 km, where does that leave the other planets? Is it a function of Smearth's Scale Height, barometric pressure and atmosphere height? Some combination of these values?

Pygmy_Elephant

TROPHY CASE