Annotated template:
The s˙st resource
The s˙st resource stores information on the Nova systems, one s˙st resource being one static system (this means that, in order for a system to change: one planet to disappear, a station to appear, its government to change... there has to be two s˙st resources that will look alike, just with the differences desired, and the two will be swapped with a NCB; more on this later). It contains everything needed to caracterise the system: the planets/stations/etc inside it, the ships that can appear here, it's position in the map, which other systems it is linked to, which government rules it, etc...
To being with, the name of the s˙st resource is being used for the name of the system as it will appear everywhere: in the galactic map, in mission texts in replacement of the <RSY> and other such wildcards, etc... Notice, however, that as with other resource names that are being used by the engine, if there is a semicolon ( ; ) in the resource name, the engine will ignore it and everything after it. This allows you to add some information that may help you track down which version of the same system this bloody #+!$*/# one is. It is not really known for which resource types this actually works, but if you see a semicolon in a resource name in the data files, and it's obvious only what's before it is considered (for instance "Koria; Rebs assim"), then you can be sure this works for the resource type considered (s˙st here); experimenting cannot hurt, either.
The xPos and yPos fields
As in the spöb resource, these two number fields specify the position of the system, but this time on the hyperspace map. Increasing xPos will move the system to the East (right), decreasing, to the West (left). Increasing yPos will move the system to the South (down), decreasing, to the North (up). The values are in pixels, in the medium zoom of the map. Some editors or standalone applications allow you to place the systems graphically, replacing (and saving you the trouble of filling) these two fields. It's important that two systems, that will replace each other as being "the same" (just a little changed), have the exact same coordinates, so as to allow the engine to keep track of hyperlinks and the such.
The Con1-16 fields
These sixteen number fields tell the ID of the systems to which the player can hyperspace from the current system. Notice that, if the destination system does not have the current system in its Con fields, the engine will correct it and make the hyperlink two-ways, though it will give a debuglog warning, so don't rely on it, be a good boy and make your hyperlinks both ways. Leave unused Con fields to -1.
The NavDef fields
These sixteen number fields store the IDs of the spöbs found in the system. Notice the first four can be directly selected by the player with the F1-F4 keys, respectively. Having a stellar exist in more than one system at the same time is not supported (more on this later). Leave the unused NavDef fields to -1.
The DudeType fields
These eight number fields hold the kind of ships that can be found in the system:
128 & more: This will make the ships in the düde resource with that ID able to appear in the system
-128 & less: This will make the flët with the opposite ID able to appear in the system, this is used for instance in some Polaris systems in which cargo convoys appear. Notice that, contrary to a düde, a flët can spontaneously appear (without being called by a system) in the systems it is set (in the flët resource) it can appear.
-1: field ignored. Leave the DudeType field(s) you don't need to -1.
The Prob fields
These eight fields state the probability for each of the matching düde or fleet to appear in the system, from 1 to 100 (i.e. the first probability field is the probability for the düde/flët in the first DudeType to appear, and so on); the sum has better be 100. Leave the fields matching unused DudeTypes to 0, so that you can check (using a spreadsheet, for instance) that the sum is 100 without these troubling the math.
The AvgShip field
This number field gives the average number of ships that can be present in the system, not counting the player's ship. The actual number of ships will be between value/2 and 3*value/2. You can set 0 for the system to be completely devoid of AI ships at all (don't put a landable but uninhabited stellar in such systems (as the player may get stuck with no fuel there), unless you wish to handle a lot of "Im stuck!1" complaints...).
The Govt field
This number field tells which government owns the system, which is being used to compute the player's legal rating in the system, draw map boundaries, etc... You should enter the ID of the gövt resource of the government that will rule the system, or -1 for the system to be independant.
The Message field
This number field allow you to specify a message that will be displayed instead of the "entering system xxx at (date)" at the bottom of the screen when the player just jumps in it (like, "Message Buoy to all Auroran ships: you have entered Federation space, prepare to be scanned."). The value to enter is the index of the string to display in the STR# ID 1000 (in Nova Data 5); for instance border Fed systems have 1 in this field, which makes the engine display the example message above, which is the first string of STR# ID 1000. If you wish your system to display a whole new message buoy, not found in STR# ID 1000, the best is to add a STR resource with ID between 1000 and 2500 (beware! STR ID 1000 will override the first entry of STR# ID 1000, 1001 the second entry, and so on, so choose an ID matching an unused entry in STR# ID 1000), fill it with the string you wish to be displayed as message buoy, and enter the ID of the STR, minus 999, in this field.
Put -1 for the default message to be shown instead.
The Asteroids field
This number field is the amount of the first of the navigation hazards: the asteroids. Though they can't hurt you, they tend to get in the way of missiles and shots; however some can be mined for resources. You can enter values from 0 to 16. Notice that those "Rochak dust field" and other such things defined in nëbu resources are just pretty images to be shown on the star map, they don't do anything by themselves and you have to add the asteroids, interference and murkiness in the systems supposedly affected by these nebu to give them some credibility. Traditionally in the EV games there can be asteroids pretty much everywhere in the galaxy, but big concentrations of asteroids are found in asteroid fields/belts/etc.
The Interference field
The second navigational hazard, radar interference, is specified by this number field. In fact, what to enter here is the percent of the time the radar display of the player will be covered by static: 0 for no interference to 100 for no radar at all. Notice this also affects guided weapons that are set to be affected by sensor interference. This sensor interference can be fought by the player with sensor upgrade and other such outfits, that will reduce this value by the amount in the ModVal fields, so the actual sensor blackout will usually be less if such outfits are common. Traditionally in the EV games, the nebulae (plural of nebula) are supposed to produce sensor interference (and since Nova, murkiness), though the biggest interference there is in a system in Nova is in fact artificial...
-
The Person fields
These eight number fields provide possibility for 8 përs to appear in this system more often that they do otherwise (just like fleets, pers appear spontaneously and haphazardly): enter in the fields the IDs of the përs that are to appear, and leave the value -1 in the fields you don't need. Notice that if the përs is dead (killed by the player or another ship), nothing will bring him back, not even this with 100% probability. -
The PersProb fields
These eight number fields are for the above fields the same as the Prob fields for the DudeType fields: the respective probability of appearance of the eight përs which ID is in the fields above. -
The Visibility field
This text field holding a control bit test expression allows you to hide and show the system depending on NCBs at your leisure. Simply put, the system will be visible when the expression evaluates to true, and will invisible otherwise, meaning you can't hyperjump to it, you won't get missions to stellars in this system, it will no longer appear appear in the star map, etc...: as far as the player is concerned, the system doesn't exist anymore/yet.
The uses of this are multiple, and not limited to the following, though what it is mainly used for is:
-changing something in a system or stellar after some event, including, but not limited to, making a new stellar appear, making a stellar disappear, adding a bar, etc... To do this, there has to be two versions of the system, one "before" and one "after", with the differences between the two being what does change. Then the event that is supposed to change the system (usually completion of a mission) sets a NCB, say b3590. The "before" system, that was here so far, becomes invisible, while the "after" system, invisible so far, becomes visible: the "before" system has !b3590 in its Visibility field, and the "after", b3590. You can make more than one change: two successive changes (ennemy station gets destroyed, then after a few missions replaced by an allied station), or two exclusive changes: one change that happens if player chooses path A and one if the player chooses path B, or more changes if you like.
-making systems, though as previously unknown or unaccessible, appear out of nowhere. This is simpler to implement than the above, though if you're making a whole load of new systems appear, it could be better to just make a few "door" systems appear, the others having always been there but previously unaccessible since there was no way of reaching them by hyperspace before the appearance of the few "door" systems.
This possibility of a mutable universe didn't appear until the late versions of EVC (the EVC scenario doesn't make use of it at all), and EVO used it for showing the player the results of his actions: destroying an ennemy outpost, advancing the war against the Voinians, exploring a previously unknown nebula, or making a ski resort in a snowy planet. The Nova scenario uses it more to stress the current action: destruction of New Ireland, terraformation, etc... though also for completion as well. But this feature has some drawbacks and caveats that you should be aware of.
First off, it is difficult to envision using it on a large scale, it would be too much resource-consuming. Remember there is a maximum of 2048 s˙st resources available, but especially 2048 spöbs (that have to change as well, or little will actually change, and usually the systems that change have one spöb or more, making them exhausted sooner than s˙st). Making a medium government change entirely following an invasion can be considered, though it will give you work. Changing entirely a major government will be horribly resource-consuming, and don't even think about it if it's not the only major change that may happen (be it in the same storyline or another). Do not even think of anything more, unless you're unbeleivably skilled and you ~really~ know what you are doing and ~really~ know that there will be enough resources. This feature is better thought as the epitome of what can happen, and better used a few at a time, or the player will see it as normal, which it isn't.
Second, it's a major source of bugs, unexpected behaviors, and annoyances. For instance, in order to avoid giving missions (and missions are really what makes the EV games interesting) to places that may suddenly cease to exist before the player has the chance to go there, the Nova engine, for a random-destination mission, will never pick a stellar that does not always exist (i.e. that is in a system that is swapped with another that does not contain it). To satisfy the engine, the exact same stellar (with same ID) has to be in all systems that swap at the same coordinates; this is the exception to the rule that one stellar cannot exist in more than one system: one stellar can be set to be in more than one system, provided their Visibility fields are exclusive, (i.e. are never true at the same time). Then only can this stellar can be the destination of random missions (obvioulsy, it's satisfied if the stellar is in a system that never changes). Usually, you don't swap systems to keep the same stellar (though that can be used just to change the amount and kind of traffic inside a system or the navigation hazards), but in case you wish to change one stellar in a system that contains more than one (like in the EVO scenario with the cure of New Calcutta, the systems contains New Tokyo as well), the stellar that is supposed to change has to change (i.e. the before and after have different IDs), but the second stellar can actually be the same and exist in both the "before" and "after" systems, so as be able to be the destination of random-destination missions. And even stellars that have to change need not be devoid of missions that go to them. What you could do is, for each random mission that could go the changing stellar if it didn't, have a fixed-destination mission that always go to the stellar, but other than that looks exactly like the random mission, and that is available only when the stellar exists (in fact, you'd need two of them, one for the "before" stellar and one for the "after" stellar). But don't forget why ignore-changing-stellar has been implemented: don't give the player a mission that he may not be able to complete since the destination no longer exists: make the mission to the "before" stellar no longer offered when the storyline comes near the point the system change will happen, and/or make the changing event abort (with the Axxx operator) this mission should it happen to be running. You need not take the same precautions with the mission to the "after" stellar, though; same thing if the stellar appears from nowhere (terraforming or station construction): make a mission that always go there for each random mission that would (should the stellar not be in a changing system), and that's all, you don't need to care about it disappearing.
Another kind of bug that can happen due to this feature happened in EVO, in fact. Back then a stellar could exist in only one system (the ID of the system it was in was in a field in its spöb resource), therefore there was two versions of New Tokyo, one before the New Calcutta cure and one after. And one recruiting mission (the one of Stellar Corp, if my memory serves me well) was at New Tokyo, but only the before-the-cure version. That meant that, if you did the mission string to cure New Calcutta and was not in Stellar Corp, you could not get in Stellar Corp any longer - not nice. That's the reasong why this recruiting mission has been moved to Molos in the 1.0.1 update of Override. There must be other bugs the system-swapping feature induces, though they have not been remarked so far.
Third, keeping track of all those bloody $*#(-!!%?(& systems (and stellars) is more work for you, and that shouldn't be neglected. This will likely delay plug release, give you more bug reports, headaches, and your toothpaste tube will be empty.
Some things you should know as well about this feature: the systems you're swapping must be at the exact same coordinates. That's how the engine knows how to update the hyperlinks and other such things, like explored status (so that the system doesn't turn unexplored all of a sudden). This means you don't need to explicitely link adjacent systems to all the versions of the swapping system, though doing it can't hurt if the 16 fields are not nearly filled.
Another thing: the Visibility fields of the different swapping systems must be logically mutually exclusive. This means that, for instance, if you have a system that changes twice, once with b6297, then once with b5997, you would spontaneously set the Visibility fields to !b6297, b6297 & (!b5997) and b5997 for the first, second, and third versions, respectively. But these expressions are not mutually exclusive: the first and third are both true if b6297 is not set and b5997 is set. Of course, that never happens in your storyline, since the mission that sets b6297 happens first. But the engine does not know it, and chokes at the idea it does not know what to do should the situation above happen. Therefore, you should modify the last Visibility field to be b6297 & b5997, for the expressions to be logically mutually exclusive, whatever happens.
By the way, systems can appear out of nowhere, but I don't think it's a good idea to have a system disappear and be replaced by nothing, it will likely confuse the player to no end, unless you have a really good reason for that.
Another thing is that if you only wish to change a description (be it a stellar or bar description), or if your change can be taken down to just a change in a description, you don't need a Visibility change. Use instead the {bxxx "string1" "string2"} description mutator, it will be much simpler. For instance, you could use it in the bar desc of New Taranto (an UE planet in EVO) to show changes in the bar (the commanding NCBs being changed with cröns) with a minimal amount of hassle, just many {bxxx "text"} thingies. This can easily be applied to many systems, should you wish to give the impression of a massive change.
Wow, did I talk for that long? Well, leave the field blank for the system to be normal, always there. -
The BkgndColor field
This hex field, that's probably implemented as a color picker in your editor, allows you to choose the background color of the system. If there is an hex field, it's encoded the same as an HTML color (first two hex numbers unused, then each following pair being one color channel, first Red, Green, then Blue), use some tool that will give you the HTML color from a color picker to know what to enter here. A non-default background color is traditionally associated with systems inside nebulae. Leave zero (black) for the usual default pure black color. -
The Murk field
This number field indicate the amount of murkiness in the system, which is actually the propensity of AI ships, weapon shots, asteroids and stellars to fade to the background when away from the player, making them harder to see (the Alphara system is the best example of this feature). It's a percentage, so 100 is the maximum, and 0 is everything normal. -1 (or any value below) will do the same as 0, but will hide the starfield. Systems with murkiness are usually systems around nebulae, though you can give the player your own reason for your system to be murky.
The AstTypes field
This hex field, which is as usual a number of checkboxes (16) in your editor, lets you state which kind of asteroid will be found in the system. Notice "Small metal" and the such are only what this will give in the default Nova scenario, you can very well replace some asteroid types with yours if you feel like doing so (however, there is a max of 16 different asteroid types, so you can't add yours without replacing some built-in one, sorry).
"Small metal" There will be small metal asteroids (defined at röid ID 128) in the system
"Medium metal" (ID 129)
"Large metal" (ID 130)
"Huge metal" (ID 131)
"Small ice" (ID 132)
"Medium ice" (ID 133)
"Large ice" (ID 134)
"Huge ice" (ID 135)
"Small dust" (ID 136)
"Medium dust" (ID 137)
"Large dust" (ID 138)
"Huge dust" (ID 139)
"Small crystal" (the kind that gives Opals when mined) (ID 140)
"Medium crystal" (ID 141)
"Large crystal" (ID 142)
"Huge crystal" (ID 143)
The ReinfFleet field
This number field houses the ID of the flët resource of the fleet that is to hyper in to the rescue of the ships of the government that owns the system (and of its allies) should they be outnumbered. Leave -1 for no such fleet.
The ReinfTime field
This number field is the number of frames that have to go between the moment the fleet is called and the moment it hypers in. Usually in the like of ten-twenty seconds (300-600) for most systems in the default Nova scenario. Nowhere does the reinforcement fleet appear instanty, but putting 0 will do so.
The ReinfIntrval field
This number field states the number of days needed for the defense fleet to regenerate if it is called (even if it arrives after the battle and no ship of it is destroyed). 0 will make the fleet be available again every day (though not twice the same day), while more will be the number of days taken by the fleet to be available again.
There can be a maximum of 2048 s˙st resources, which means s˙st ID from 128 to 2175 can be used. Notice the limit has long (in the development cycle, it was already 2048 at release) been 1000, which is the reason why many places in the Bible assume a max of 1000. As always, assume the bigger (2048), these parts have not been updated.
.
.
.
I need comments on the Visibility feature, especially, and if you think I'm explaining it right (i.e. that i'm not scaring people too much, that it accurately reflects the problems encountered with it as I did never use it on a large scale, etc...)
This post has been edited by Zacha Pedro : 28 September 2004 - 08:26 AM
