Shrugger! Unity!

[Draco18s]

I'm going back to modelling the asthenosphere now; not much point in having a roguelike without a planet to stand on.

Ah, but there's a great deal of point in a roguelike where, by a few actions and some particularly remarkable RNG rolls, you no longer have a planet to stand on!

Portable Hole, meet Bag of Holding.

[Shrugging Khan]

Well, blowing up the planet is certainly an option.

Anyways, you're all probably a lot better than me at math; what kind of formula could I use to spawn stars in a higher density towards the galactic plane?

Right now, I just spawn them at the centre of the scene, give them a random rotation, and tell them to move back by a few thousand kilometres (inb4 realistic distances - I tried, but unity did not like).

Oh, and if the entire sky were treated as a hollow sphere with the stars tacked onto the inside, then how would it have to rotate for the relative motion to emulate the rotation of the planet (at any given latitude)?

[Draco18s]

Anyways, you're all probably a lot better than me at math; what kind of formula could I use to spawn stars in a higher density towards the galactic plane?

If we assume that you're placing stars along an X and Y axis, where X is longitude and Y is latitude (so Y90 is the north pole  and Y-90 is the south pole), then something like this:

Y = random(90) - random(90);

That'll get you a bell curve towards the equator plane (which is roughly where the galactic plane is).

Oh, and if the entire sky were treated as a hollow sphere with the stars tacked onto the inside, then how would it have to rotate for the relative motion to emulate the rotation of the planet (at any given latitude)?[/b]

This is where local rotation comes in.  Rotate the sphere by the latitude value, then use your localRotation.eulerAngles to spin it along its vertical axis (y?)

[Shrugging Khan]

Thankee! I'll make good use of that info.

PS: Other little question - when you put a Reaction wheel on a spacecraft (in space) but mount it far away from the centre of mass, how will that affect the rotation of the craft?

PPS: Nevermind, I think I found out. The reaction wheel will be less efficient the further out it is, won't it?

[Draco18s]

PPS: Nevermind, I think I found out. The reaction wheel will be less efficient the further out it is, won't it?

I don't know what a reaction wheel is, but generally speaking in physics, the farther away from the center of rotation your force is being applied, the more effect it has.

It's called Mechanical Advantage (specifically: a lever).

[Shrugging Khan]

That would be my usual understanding, too. But the thing with machines in a vacuum is that you can't work with leverage. Spacecraft usually use flywheels for precision work on their attitude (else: manoeuvring thrusters); see http://en.wikipedia.org/wiki/Reaction_wheel for more information on that one.

[Draco18s]

Oh!

I don't know the answer to your question, but I do understand how they work.  They work on the principle of action-reaction.  It's not so much that they make the spacecraft rotate by spinning them, but rather the change in the spin on them changes the spin on the spacecraft.

I don't think you'd actually have to worry about that level of detail in a simulation.  Reaction Wheels are for very very tiny adjustments.

[Shrugging Khan]

On an unrelated note; do I have any physical (CPU / RAM) disadvantages from declaring public variables, objects or methods, as opposed to nonpublic ones?

[Draco18s]

On an unrelated note; do I have any physical (CPU / RAM) disadvantages from declaring public variables, objects or methods, as opposed to nonpublic ones?

No.  Public/private is just error checking preventing you, the coder, from changing values you shouldn't be.
(Not entirely true, there are differences at runtime, but the gain/loss of resources is unbelievably tiny; takes upwards of 10 million accesses to accumulate 1 ms of lost processor)

[keith.lamothe]

Yea, I suggest making everything private unless it needs to be broader, just to avoid unintentional access/modification from other classes.

It isn't hypothetical; a lot of my bugs are actually from braindead typos like picking the wrong field.  Though most of those I catch in internal testing before they sneak out.

On a similar note, I find it preferable to not do getter/setters except when the associated logic is complex or the field in question really needs the protection.  Saves coding time and cpu time.  Of course, this is from my perspective of "only an Arcen programmer will ever maintain this code", which is radically different than writing a library or whatever.

That said, the "readonly" modifier is great for fields you don't plan to change after construction.  We have tons of those in our enum/typedata-pattern classes.  Granted, I've only _once_ accidentally modified a typedata field that I meant to access, but I don't think Space Tanks have ever quite forgiven me for intermittently revoking their ability to enter transports.  During the game.  ALL Space Tanks.  Everywhere.

[Shrugging Khan]

I also pretty much dropped the teaching of "Getters and Setters everywhere!" (as taught at our university), and only use them where it actually provides necessary functionality.

But alright, thanks gents. I'll stop feeling guilty about all those public values, then.

[Draco18s]

I also pretty much dropped the teaching of "Getters and Setters everywhere!" (as taught at our university), and only use them where it actually provides necessary functionality.

Pretty much.  For a semi-RPG I built I was performing some cryptography on the player's stats, so that it was harder to use CheatEngine to access and modify the values.  So I used getter/setter to translate between the obfuscated value and the actual value.

Minecraft also has getters for a lot of values simply because it allows for a lot of power in terms of future or mod content.  So you can have a block that looks different based on side and metadata, or items that have different icons based on NBT data.

But in general it's probably fine to skip them if you don't see a use for it.

[windgen]

> I suggest making everything private unless it needs to be broader, just to avoid unintentional access/modification from other classes.

Python has a good solution to this dilemma.  Instead of a "private" keyword that gives you a compiler-enforced "this field can't be accessed from other classes," the Python Way is to use an underscore in front of the names of fields that are intended to be internal as a strong suggestion that outside classes shouldn't use it.

When you get right down to it, sometimes it's good to be able to access private fields if you really need to.  The underscore tells you "This isn't intended to be part of the public API, so it may break in later releases without warning, and it's also probably totally undocumented so you ought to read the code to be sure it does what you think it does."

There are countless times I've wanted to access a private field in some library, and I have to either re-implement that part of the library, or make my own fork, for no good reason other than the library author made the field private because they weren't creative enough to envision my use case.

Then again, if you're writing application code that's not going to have any downstream users, "private" doesn't matter so much, because if you discover later that you need to access it, you can always just change the declaration yourself.

[Draco18s]

There are countless times I've wanted to access a private field in some library, and I have to either re-implement that part of the library, or make my own fork, for no good reason other than the library author made the field private because they weren't creative enough to envision my use case.

Reminds me of the ItemStack sensitive version of getIcon for Minecraft, which was marked as Final.

http://www.minecraftforge.net/forum/index.php/topic,12446.0.html

Just read Lex's replies when I tried to ask for Forge to un-finalize the function.

Three days later someone else made the same suggestion and the change was made.

[keith.lamothe]

Yea, my tendency towards "private" was in the context of writing code that's entirely internal to Arcen.

If I ever write library code again, many things will need to be different   Though there I would probably expose it through getter/setter stuff.