Discovery Gaming Community

Full Version: multi-base planets
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Sorry this is kinda long but it's complex subject and a lot of incosistency. I've been working on trying to fit the planets with multiple bases into the wiki conversion script, and want to file report while I'm thinking about it. I believe the full set of these is Pecos, Planet New Paris, Planet Lyon, and Planet Marne but if there are more please tell me.

The best operational model for these seems to be using a non-dockable dummy planet for visuals, and some kind of hidden host object for the individual parent objects. Pecos is the only one that uses this model already. Planet New Paris and Planet Lyon use a single dummy planet and multiple host objects, but the host objects use a planet archetype that show up on the navmap. Planet Marne does not use a dummy planet, and instead just uses two parent objects that are stacked (the Brigands base is the large visible planet, the Council planet is the small and not-so-hidden object), which also results in both planets showing on the navmap.

So first batch of bug reports for this, is that Planet Marne should be converted into a dummy planet. Marne uses ew16_planet_4 for the main planet, and ew16_planet_8 for the not-so-hidden planet. Probably ought to keep those as the host objects and create a new object for the dummy planet (this will preserve peoples visit lists). All of the other associated planet objects should have their archetype changed to invisible_base, or change the object definitions to include "visit = 128" to hide them on the navmap, which also works but is not as robust. These changes only seem to affect how the client draws the navmap so does not seem to have any effect on savegame files at all. The list of planets that should get their archetype changed:

ga01_planet_1_npi
ga01_planet_2_npi
ga01_planet_3_npi
ga04_planet_1_li
ga04_planet_2_li
ew16_planet_4
ew16_planet_8

The other big part of the problem space is the infocard management, which does not display in the wiki consistently. Usually, undockable objects have the stats plus a full-text description in a single infocard, while dockable objects have just the stats in the host object's infocard and the base object has a secondary full-text infocard that is loaded when the base is visited, so after you dock an object the base description infocard gets prepended to the host object's stats infocard.

In this model, the dummy planet is not dockable, so it should use the undockable variety of the infocard with stats and full descriptions (you see everything about the planet when pressing F9 from space). Then create stat infocards for the host objects that each contain cloned copies of the dummy planets stats (but not the description text), and then add base-specific description text to additional infocards that are called with infocardmap when the individual bases are docked. So basically you can F9 the planet from space and get the description of the planet, but you can F9 the base while docked and get the description of the base like normal,

The Planet New Paris and Planet Lyon objects already use this model, with the dummy planet infocard having planetary stats and descirption, while each of the subordinate host objects have their own stat infocards with cloned copies of the dummy parents stats, and then the base objects have the full-text infocard that is prepended to the host object's stats infocard. Planet Marne and Pecos do not work this way and need to be fixed.

Obviously, Planet Marne does not have a dummy planet so it does not have that infocard. The two planet objects that are already defined both use the same stats card, and the two base objects both use the same infocardmap description card (so visiting one of the bases gets you full descirption of both). So, to-do list here is to create a full infocard for the (new) dummy planet, create cloned stat infocards for the two host objects, and create distinct description infocards for the two bases.

Pecos is in really bad shape here. The dummy planet has an ids_info infocard but it is just the planet stats and no text (there is no full-text description in the card, and no other card referenced in the infocardmap--not that it matters). Also, each of the 3 bases on Pecos all use the same infocard value, which seems like it was supposed to be the Pecos full-text infocard. Basically the to-do list here is add the full-text from the base infocards to the Pecos infocard, create cloned stat infocards for the base host objects, and create full-text infocards for the three distinct bases to use with infocardmap.

Hope this helps somebody to get it fixed
I really do wonder why there aren't more planets like these. Makes a lot of sense, especially capital/densely-populated planets, like manhattan. I do notice how it would be tricky to classify their infocards, but i don't understand your first problem.

To help in the infocard prob, why not place the infocards of the base itself on the docking ring? While the planet itself can be F9ed to give a general description in addition to giving a list of the bases to land on, the docking rings can be F9ed to reveal the specific base they lead to. Only prob I can see on this solution would be the, what I call, the Shasta-bug, which means that orbitals being directly-above/below can't be selected on the navmap. Planet New Paris suffers from this bug.

Also, I agree that the solution of "overlayering" planets seems pointless, and am in favor of the single dummy-planet.

I'd love to help, but I don't know squat how to code. What i can do, however, is proofread and grammar/spellcheck the infocards for ya.
Interesting thought. I'll forward this up the chain and incorporate it into my infocards.
Dummy planet is simple. Untextured sphere, radius 10 or so. Looks just like a standard sphere, just much smaller. For some planets, this just wasn't thought of when this multilayering was implemented.
The "dummy planet" I am referring to above is the "real" planet, which only exists for the purpose of providing a visual (it is simple though, just give it the planet archetype and no base= definition). The "host" objects are the ones that are hidden (archetype=invisible_base) and those have the discrete base=definitions for the individual bases

Quote:I really do wonder why there aren't more planets like these.
It's sub-optimal and generally unnecessary.
I dunno about unnecessary... having multiple docking rings kinda sounds like a good idea in the following scenarios:

1.) create more places to sell different kinds of ships in the "same" place
2.) different docking rings dedicated to different types of traffic: civilian, police/military, trading corporations. It's also going on the thought of not "putting all your eggs in one basket", meaning that, iRP, if one docking ring is destroyed, you at least still have two more reserves.
anything that can be done with a separate docking ring can be done better with an additional orbital platform or docking rings on a moon

they are interesting, not trying to get them removed, but they are kludgy and dont work as well as just defining another base somewhere