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).
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
I'd suggest you to re-format the "Visibility" section, because it is pretty long and would be clearer if more divided into parts. Apart from that, maybe see if you shouldn't cut down the length of the parts about EVC and EVO (I myself, having never played them, skipped those parts because I couldn't understand them, and I must say they are pretty long in themselves). Apart from that and the few spelling mistakes, good job.
In fact, I would suggest trying to find out what the s˙st editor is like in different editors because that way you could mention which ones are easier to use (Mission Computer has a very good galaxy map editor).
Once again, nice job, ZP.
Pace (haldora), on Sep 28 2004, 04:37 PM, said:
Once again, nice job, ZP. View Post
Firstly, I'm just writing this and have little experience in making things easier to read; I'm leaving such things to web designers who will better arrange it than I would. Second, the parts about EVO are the examples I had at hand, since I couldn't find for Nova; one can check the Override TC if he'd like to know more, or ignore the example and try to understand without it (hard, I know). Otherwise, this is for the reader to know in which ways the system change has been traditionally used. However, I think I can replace the New Taranto example indeed.
Thirdly, I really don't wish to endorse or advise an editor, make PC users jealous, compare them, etc... I'm leaving the choice of the editor to the reader, and help him whichever editor he may be using, just informing him of some features his editor may (not) have, both in order to help people using and not using a particular editor, and helping people realise ResEdit with templates is not the be-all and end-all of plug deving; but nothing more. This is mainly for reasons of future compatibility, and personal feelings.
A change: instead of the New Taranto example, put "For instance, you could use it in a bar desc to give the impression the bar is always changing, having people blow up each other, blow up the bar itself, have it regenerate (see where I'm looking?), 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..."
I wonder if it might not be a bad idea to include a small tips and tricks page, that might include little useful tricks like semicolon comments...
My other question is, and this actually doesn't appy to this one, but you aren't including the actual flags values for flag fields (e.g Food (0x001) low prices). Are you assuming a graphical editor? I'm cool with that, but it might not be a bad idea to include them... then I suppose you'd have to explain hex addition too... oh well.
Other than that, looks good. I'll probably convert this one after I finish w/ spob.
-Brindy
Hex additions are explained in my Bible Explained to Dummies. I assume that, if the reader has to enter hexadecimal, he can check the actual hex values in the Bible: as I said in another template, I won't say everything the Bible says as I would sometimes just be repeating information found there, that is already clear enough in the Bible (wildcards in dëscs), or there is little need to know usually (hex values), or only usable by advanced users, or just too long (oütf ModTypes and ModVals).
As for such tricks, they are un(der)documented, so I don't know myself to which extent they can be used, etc... so (as you may be seeing with the semicolon comments) I'm reluctant to tell the reader about them unless I really know they can be used; the break I'll take will serve to test such things and better document them.
Rereading it, I realise the new example that replaces the New Taranto one isn't very good either, as people reading this may very well be people that never came to the EVC/O/N boards. Leave me some time to replace it (I'm very attached to it as it's a really little resource consuming but living thing to do in a plug).
(note: answered to a PM about these TMPLs:) As I said in another such topic, I allow anyone to read, copy, publish, modify, ignore, set on fire, and wipe his ass with this work (all my plugin guides: annotated templates, Bible Explained to Dummies, Contribute/Require/Scanmask guide, etc...). I just ask to be credited as the original author, that you tell if you modified it, and not to make money out if it. Other than that, go ahead. I don't ~need~ to find a web developer since they were originally for Space Pirate's plugin site (and I'll know he'll be using them), but I then decided anyone could use them. EVula even posted a message offering to host them, that's saying something. But there can't be too many places these guides are displayed. I'm doing this in order to have more, bigger and better plugins in the future. Just one thing: for this to be successful, I'd like web developers to display the "Non-Technical Nova Bible" as well (that his author allowed use as well) so that it doesn't create a hella lotta bad plugins as well.
Zacha Pedro, on Sep 29 2004, 05:01 AM, said:
Actually, I'd think it would be better to have them listed here as well, I could go ahead and add them in... Remember, this has to be as easy as possible for the reader, and we want as little flipping between documents as possible. Of course, I know it's practically worthless (and makes things unnecessarily technical) to repeat all the stuff the bible says, but if there is something important, I'd suggest at least referencing a part of the bible.
We know the n00bs don't actually read all of the bible, so it would be a good idea to remind them whenever possible.
BrindyBlitz, on Someday, Sometime, said:
Hex addition should be explained sometime in the Getting Started section, I suppose. I figure I'll go and add in the html anchors in both the Non-Technical Nova Bible and the Bible for Dummies, and link to them as reference material with some frequency. Also, if I can manage to set up a bible like EVula's for EV and EVO, I'll do those as well.
Quote
Such a page listing all of these tricks would be good for a wholly separate guide, I think. Especially with all of the undocumented features, there really isn't anywhere (aside from these boards) that tells people how to do them.
As I said in another such topic, I allow anyone to read, copy, publish, modify, ignore, set on fire, and wipe his ass with this work (all my plugin guides: annotated templates, Bible Explained to Dummies, Contribute/Require/Scanmask guide, etc...). I just ask to be credited as the original author, that you tell if you modified it, and not to make money out if it. Other than that, go ahead. I don't ~need~ to find a web developer since they were originally for Space Pirate's plugin site (and I'll know he'll be using them), but I then decided anyone could use them. EVula even posted a message offering to host them, that's saying something. But there can't be too many places these guides are displayed. I'm doing this in order to have more, bigger and better plugins in the future. Just one thing: for this to be successful, I'd like web developers to display the "Non-Technical Nova Bible" as well (that his author allowed use as well) so that it doesn't create a hella lotta bad plugins as well. View Post
That reminds me, I've downloaded the NTNB, and I still have to go about formatting it... I'll get that up soon.
Keep up the great work! ~ SP
This post has been edited by SpacePirate : 29 September 2004 - 07:10 PM