Your browser does not seem to support JavaScript. As a result, your viewing experience will be diminished, and you have been placed in read-only mode.
Please download a browser that supports JavaScript, or enable it if it's disabled (i.e. NoScript).
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.
This post has been edited by Edwards : 13 March 2005 - 03:02 PM
Wow, this is a very very elegent solution to that problem.
Jeeze. Its really quite awesome.
Rather beats my thread, I think. Ill have to test your plug out.
~so the only two fields, then, that are evaluated immediately are the OnShipDone and the OnDestroy (for a stellar) field? I didn't know about the latter.
Hmm. How does the router system know which system to send you to?
This post has been edited by NebuchadnezzaR : 10 March 2005 - 12:11 AM
NebuchadnezzaR said:
Simple. The only router system that is visible at any given time is the one that contains the correct Router spob. This is achieved by giving it the same VisBits as the system that it will send you to.
If you're wondering about how it choses between different planet-systems in the same orbit, that's done by putting the starting systems for each planet-system in a different location, so that you will re-load into a different router system for each planet-system (that was actually the last bug I had to work out of the demo- I had test spobs I and II both starting at the same place :rolleyes: ).
Actually, most NCB set strings seem to be evaluated immediately (in space). (Even OnFail, although I haven't yet managed to get a mission to continue until I land after failing. I think I know what's going wrong, I just haven't had time to test it.)
Ah, yeah. Should have seen that.
Two planet systems in the same orbit? Wow. Quite versatile.
And there really arent many NCB set strings that you can activate in space, especially since crons only fire daily. But yeah, I assume most would eval immediately. But do you actually fail the mission before you land on the returnstel (like where you see the failtext)? Ive never seen resolution to that. If so, its still only onAbort, onFail, onShipDone, and Ondestroy. Nothing else can be triggered, except maybe the onsuccess of autoaborting missions.
You can fail immediately via scanning, being disabled, or failing the SpecialShipGoal. Trust me, I've managed all of them (with no failtext- the mission vanished immediately. I may not have had any cargo, though).
If so, its still only onAbort, onFail, onShipDone, and Ondestroy. Nothing else can be triggered, except maybe the onsuccess of autoaborting missions.
No, the full list is: crön: OnStart, OnEnd (albeit only after time has passed- hyperspacing or an auto-aborting mission with PostDateInc (see this thread).
mďsn: all the ones you mentioned, although my auto-aborting missions have not set the OnSuccess string.
shďp: OnCapture (whether you use the ship as your own or not), OnRetire (if the ship gets blown up, and probably if you capture another ship and use it as your own). Also, OnPurchase is set for ship 128 when you get it after using an escape pod.
spöb: I have only tested OnDestroy, but I suspect that the other set strings are evaluated in space as well.
Also, I suspect that the nëbu resource's OnExplore also fires immediately.
Yep. That was one of the things I made sure of (and it also causes one of the few problems- see the last few paragraphs). It will even send you to the right planet if the is more than one in the system.
BTW, did I break any records for post length?
Gah! Nova quits on me when it tries to create a pilot. I've got no data files, just absolute minimum and this. Was there something else I'm supposed to do?
Ooooooooooops.......
I REALLY need to pay attention to little details like that. You also need to have Nova Graphics 2 in the Nova Files folder.
(EDIT) All right, the file has been updated: The readme now specifies that you must have Nova Graphics 2 in you Nova Files folder. There are a few more comments in the plug itself, as well as a new document explaining what's going on in the major parts of the plug. I've also edited the description of how to do this, both in the download and in the first post.
This post has been edited by Edwards : 11 March 2005 - 01:28 AM
That's ######ing brilliant! I was skeptical, but it works perfectly.
If you set up your crons differently, you'd be able to prevent the spob being pulled out from under the player. It would just require 1 additional cron, and 2 more NCBs. Create a new cron (Orbital Counter) with a lower RID than the current ones. Put the Pre-Holdoff value in this new cron, and remove it from the old ones. Have the Orbital Counter cron Bxxx On Start, and put Bxxx in the Enable on field of the movement crons. Also, add a !Bxxx to the On End string of all movement crons. Now, you have 1 cron which does all of the counting.
Also, add a !Byyy to the Enable On fields of the movement crons, add Byyy to the On Start fields of your Router missions, and !Byyy to their On Abort fields. Basically, the movement crons will never be able to fire when the player takes off from a spob, only when the player hyperjumps.
This post has been edited by slouch : 12 March 2005 - 02:09 PM
Very nice. There's just one difficulty with it. A system's effective state of visibility changes one day after the bits controlling it change. Your trick prevents a system from moving out from under you when you take off from a planet in the same system, but if you have a one-day-jump ship, and jump to the next system, the bits will change, but the system will not. If you then land on a planet in that system, and take off, the systems will change, leaving you behind (and incidentally, not giving you the Router mission).
My sub-conscious is yelling at me that there's a simple solution to this, but I haven't worked it out yet .
Holy ######! Has Masamune heard about this? That's ######ing great! I have some questions, though. Does the ship blowing up show any little explosion animations and/or sounds as it blows up? What about the shän for the ship? Does it need a physical presence? And what about the router spöbs? Do they have to have graphics in order for the engine to know how big they are for the collision math? Also, if your moving spöbs have gravity, how does that affect the Nxxx modifier? You mentioned that the background colour doesn't change, but what about the stellar's gravity?
What the...Kanerix? Wow.
I'll ask him if he's seen this topic.
Holy Fapping Mother of All Squirrel Felchers, I'll be damned.
Damned to heck for the better part of eternity, to be precise.
Meer words can not express how awsome this is, yet I shall declare this: Sephil Saga shall again have rotating systems!
Kanerix, on Nov 7 2005, 11:18 AM, said:
Does the ship blowing up show any little explosion animations and/or sounds as it blows up? What about the shän for the ship? Does it need a physical presence? And what about the router spöbs? Do they have to have graphics in order for the engine to know how big they are for the collision math? Also, if your moving spöbs have gravity, how does that affect the Nxxx modifier? You mentioned that the background colour doesn't change, but what about the stellar's gravity?View Post
The ships do not need explosions- just set their ExplodeTypes to -1. The shan can point to a plain black image for both sprite and mask- the ship does not need any physical presence to self-destruct. The routers spobs, I believe, do need to have a sprite with functional mask to kill themselves. They can, however, be placed beyond the area of the system that the player can reach. And I have absolutely no idea how gravity is affected. I'll have to check that.
And remember, the demo plug requires Nova Graphics 2 in addition to AbsoluteMinimum- this allows some useful graphical illustrations of what happens to the Router spobs.
Masamune, on Nov 7 2005, 05:33 PM, said:
Meer words can not express how awsome this is, yet I shall declare this: Sephil Saga shall again have rotating systems
Why, thank you. I actually did this with Sephil Saga in mind. I knew I should have tried to contact you when I first posted it...
And do you mind if I quote that "Holy Fapping..." bit from time to time? Perhaps post it on my wall? (EDIT)That line has had me rolling on the floor for the better part of an hour now...
Edwards
This post has been edited by Edwards : 08 November 2005 - 02:56 AM