Ways we could maybe use aspects of I, Voyager in Moonwards

kimholder

Hello
Charlie contacted us a while ago to let us know about I, Voyager. It's a great piece of software, a lovely way to get familiar with the solar system. It already works smoothly and looks good. 

We haven't gotten the sky of our moon colony looking the way we'd like it to eventually. We may try using work already done in I, Voyager to achieve the realism we want - an Earth hanging in the sky, turning on its axis as time progresses, reflecting the sun the way it should, and the heavens spinning as they should over the course of the day. Right now, for the Earth we just have a simple ball hanging some 30 km from the rest of the game environment, emitting light, and the sun isn't shown. 

Our project is quite extensive and right now we can't spend time on these kinds of touches. And also, I'm the asset person, not a code person, so I'm not the right person to discuss it, probably. But I'm opening the discussion to note that we feel this might be a good resource to us, and that we are interested in how this progresses. 

If we had enough success we'd expand into depicting skyhooks, O'Neill cylinders, and a variety of ships. I, Voyager might impact our work there, as well. We'll be looking in here with interest. 

kimholder

Incidentally - yes, we're making a lunar town as it might be in half a century, as a sandbox simulation, at https://www.moonwards.com/

Charlie W

Awesome! Moonwards looks fantastic! I hope our project can help make it even better!

I've been pondering this from a high-level program point of view. Basically, you need ivoyager (the submodule) to be as unobtrusive as possible. Here are some features that should make that possible.

• We can strip the solar system down to whatever bodies you need. It's just data tables. The program can be told to use a set of reduced tables outside of the ivoyager submodule. Resources (textures & models) are not loaded if the solar system object is not present in the data tables.
• The program is constructed using dictionaries in ProjectBuilder and init settings in Global, which can be modified from the outside. We should be able to "gut" whole systems that are not needed. 
• Since all of the above is done "from the outside", you can update to new ivoyager versions without having to rewrite custom code. (If an update doesn't work for some reason, just revert until we figure it out.)

Charlie W

One potential hiccup is colliding class names. For example, we have class "SettingsManager". So you couldn't combine another project that had that class name. All of our class names can be found in ProjectBuilder.

I've thought of a few solutions, but all are rather painful. One very ad hoc solution is to append an "_" to all of our class names. The more correct solution is to have an I, Voyager "namespace". So the class is now Vygr.SettingsManager or something like that. I'll have to think about whether that's possible in GDScript.

Edit: Wow! Based on a quick test, it appears that I can use a namespace in GDScript. As it happens, I've wanted to do this anyway so ivoyager would behave more like a "library" in my own projects. Perhaps I'll get this into v0.0.9.

Edit 2: No, that doesn't work due to cyclic references. We'd have to just prefix our class names. I'll have to think about that.

Charlie W

Here's another hiccup (just documenting as I think of things). Our units are all defined in a static class UnitDefs. These have to be constants in a static class because they are used to define other constants throughout our code. So then we have `const METER := 1e-13` because it works well for representing the entire solar system. Bit it isn't what you want for the moon surface. (I assume you're probably using 1 meter = 1 game unit.) However, our goal is that you can use ivoyager without changing code inside of the ivoyager submodule.

It may be that we need to move UnitDefs (and perhaps a few other constant defining classes) outside of the submodule. This gives me another "project organization" item to think about.