a (semi) elegant solution.
Well, this isn't quite as efficient as I first thought, but it's better than previous efforts, as it shifts the bulk of the resource load to systs and spobs, both of which have a limit of 2000.
--------------------
A summary of previous experiments by Masamune (see this thread for more detail):
A rotating planetary system works well, except for two things:
-
If a planet moves while you are on it, when you take off, you will discover that the planet has moved on, leaving you in the system "behind" it in the orbit. That is, you will be in the now-visible system that that has the same X,Y coordinates as the one you landed in.
This isn't much more than an annoyance, unless you have lot of missions with long PostDateIncs. -
If you quit and reload the game, or load another pilot and then reload the first one, you will find that you are in the currently visible system at the same X,Y location as the lowest RID'd system that contains the planet you last took off from (I will call this the "starting point" of a planet).
This is caused by the game only saving the spob that the pilot is currently at, not the system, and it is a major problem.
The most obvious way around this is to have a mission, available in each system location, that sends you to that system (via Nxxxx) whenever you take off or load. The problem is that this requires literally hundreds of missions, and there is a maximum of 1000. This is a problem if you intend to have a complex story.
What you need to remember, however, is that missions aren't the only resources with NCB set strings, and an NCB set string is all you really need to put the player back in the right system.
Sparked by the thread on Interplanetary Warfare (I worked on this at the same time as that), I chose to try spobs.
--------------------
Here it is (note that this only covers problem #2):
Create a "stack" of systems at the starting point of each planet. Each system has a VisBit string that matches that of another system in that planet's orbit, and each one has a different spob (wormhole type- no jump distance problems or map entry).
Each of those spobs has a planet-destroying weapon, and each one has an OnDestroy field that will Nxxxx the player to the corresponding system. I call these Router planets. They need to be destroyed via Yxxxx when you start the game, due do the Start Game Dead flag not working.
Due to a wonderful feature of the game, a spob with a planet-destroying weapon will destroy itself when it fires, if it can be destroyed and if the weapon has no ProxSafety. The only problem now is to get the planet to fire when you end up in the system after reloading, and more importantly, not when you merely jump into it.
This is where the few missions I used come in. Each one is fully invisible, automatically accepted whenever you land on a planet in each different orbiting system (more on this later).
It creates a self-destructing ship (armor 0, DeathDelay 20) at a random location in the Current System (-6). The SpecialShipGoal is to Destroy All Ships (this only fires when the last ship finishes blowing up).
In its OnAccept, it un-destroys all of the Router planets, in its OnShipDone, it aborts itself (this is important- in each Router spob's OnDestroy field, have it abort it activating mission, as OnShipDone fails to fire immediately if you are Nxxxx'd out of the system), and finally, in its OnAbort, it re-destroys the planets it un-destroyed at the beginning.
--------------------
The in-game effect of all this is as follows:
When you land on a planet, you are given the mission. This activates all of the router planets.
When you take off, the SpecialShip will appear and start blowing up. Twenty frames later, it will finish blowing up and the OnShipDone string will disable all of the Router spobs (without setting off their OnDestroy fields).
That is what happens if you do not reload the pilot file: nothing. If, however, you do reload the pilot file, when you enter the game, this is what will happen:
(In slow motion:) You will appear in the planet's starter system, with the mission still running. The SpecialShip will appear in the system, and start to blow up. However, this time, the Router spob will shoot at the SpecialShip, and in so doing, blow itself up, activating its OnDestroy set string before twenty frames have passed and the SpecialShip finishes blowing up. That set string sends you back to the system you are supposed to be in, and aborts the mission, which re-destroys the Routers that were activated by the mission.
(At full speed:) There is a brief flash of a strange system, before the planet you are supposed to be on appears under you (NOTE: the system will keep its background color from before the move, as well as any particles that might have been on-screen). All of the Routers have been rendered harmless again.
--------------------
And finally, I said I would elaborate on where the mission is available, so here goes. Create another set of systems, one for each moving planet/system, and place them in out-of-the-way places (they probably should not be on top of each other). Set their VisBits to something impossible.
Now, in every system that contains a moving planet, place a link to the corresponding invisible system.
Next, set the AvailStel of each mission to be "Stellar in a system adjacent to" the appropriate invisible system. Have the mission only activate/deactivate the Routers for that system. If you don't have enough space in its OnAccept set string, you can add an auto-aborting missions to activate/deactivate more Routers.
The only problems that I've found with this are that it doesn't shuffle you along when the system moves out from under you in the normal course of gameplay, and that, due to a rather unfortunate order of operations with changing system visibility*, it will fail to compensate on reload if the system moved on takeoff (perhaps add a friendly notice in the readme, saying that "if you take off, and find yourself in the wrong system, do not quit or load another pilot until you have landed again, on any planet"?).
--------------------
Total Resource Requirements:
Roughly, this will double your s˙st count, and add one spöb for each. Additionally, it will use on mission for each orbiting system.
More precisely, it uses:
One syst and spob for each location of each planet-system that orbits.
One to two misns for each planet-system that orbits (depending on orbit size).
One dude, one desc for each misn, two govts, one rle8/rleD, one shan, one ship, and one weap.
--------------------
Please comment on this, ask for clarification on things you don't understand, etc.
Also, be sure to download and dissect the example I've made.
*The order of operations is that, when the system changes its state of visibility, its RID changes to the now-visible (probably the highest-ID'd visible) system in the same location. Unfortunately, the contents (spobs) of the system do not change until a day later, so you can land on a spob that is in the "wrong" system, one that is not connected to the correct Router Activation system.
Attached File(s)
Rotating_Syst_Folder.zip (9.96K)
Number of downloads: 47
This post has been edited by Edwards : 13 March 2005 - 03:02 PM
.