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).
Testing/debugging/troubleshooting guide
Note: If you're currently having a problem, go directly to the troubleshooting section.
Introduction I: Testing II: Debugging Techniques III: Troubleshooting Appendix: Known issues
Introduction
A very important part of plug making, that is often overlooked, is testing them for potential problems. This is not just playing the plug like you would expect the player to do, but actually hunting for problems by trying every possible behavior. And unless the plug is really small, you should be helped in this task by a group of beta testers; this has the added benefit of providing feedback on other aspects of your plug, especially gameplay. Testing can be helped by some tricks, that will be resources just for you to use, not to be included in the final plug, that are often referred to as debug cheats. Lastly, once a problem has been encoutered, you should be able to deduce what the faulty resource is, and correct it.
I: Testing
Adequate testing is mandatory for a good plug. No matter how many revolutionary features it makes use of, how deep and thrilling its storyline is, how balanced it is, if there are bugs in it, it won't be good, especially if these bugs affect the content, such as locking people out of storylines or crashing the game. To make sure your plug is as bug-free as possible, the best way is still to play it thoroughly and entirely, not leaving anything to chance.
There is more to testing than checking that the game plays as you expect it when playing with the expected behavior (though it's of course mandatory that it plays well in this case). There can indeed be loopholes hidden in your missions (there are in EV, EVO, and EVN, actually), unexpected behavior when doing things not in the order you expected them to be done, and other such things. And if your plug isn't small, it will be too much of a task for one person to do, so you should be helped by people called beta testers. You should not have too many problems finding some: a list of volunteers is maintained and available (url="http://"http://www.ambrosiasw.com/webboard/Forum9/HTML/003091.html#")here(/url), you just need to email the ones you're interested in to state what you expect from them, check that they are still accessible and willing to test your plug, then email your plug to the ones who answered positively.
Here are some basic rules of testing: firstly, test with the latest version of the game, and if you can, test on both platforms (Mac and PC), or if you own only one, make sure you have testers running the other platform. Then, pay attention to what you are doing, so that if, or rather when, a problem happens, you are able to remember what you last did so that you can reproduce the problem. If you're a beta tester, when reporting to the author think to clearly state what the problem is, how you reproduce it, what you expected to happen, and all the relevant information you can give, and if you're the author, you should write that down (whether you or one beta tester found it) to help you track down the problem. Don't hesitate to ask your tester more information about a problem he reported if you're not able to reproduce it, but don't overuse them. After all, they are helping you out of kindness just in exchange for playing a plug before anyone else. Also, don't neglect their imput, and expose them to the same conditions as the users (i.e. don't give them info you don't plan to give to the users), it's ideal to test the readme and accessibility of your plug. It's important to test in the conditions the users will play your plug.
When you test, you should keep what you expect your plug-in to do on a real-world sheet of paper, this saves you from going back and forth to your plug editor, you can check it while you play. Write down everything you can. Especially, write your mission string on paper with the relationships between missions, the ncbs they set and which mission and paraphernalia (such as new outfits) they allow, as this is easily the most complex part of a plug, and the hardest one to debug. Sometimes by doing this you'll even realise bugs in the implementation of your mission string even before playing it.
When testing, the pilot log and debug log are your friends. Full instructions on how to obtain them can be found (url="http://"http://home.comcast.net/~slagblah/pilotlog.html")here(/url), and you should tell your testers to include either or both when reporting a bug (and therefore give them these instructions). Sometimes they give explicit reasons why there was a problem, but most of the time it will just contain what the engine did before crashing. You can use this information to tell what the engine attempted to do when it crashed, though sometimes it's what is last in the log, and sometimes what should have been next. The pilot log also contains all relevant info on the pilot, such as the ship he's flying and the outfit he owns, but also some hidden information such as the list of ncb set and the currently running crön events. The ncb list can greatly help debug mission strings.
When testing, try every possible path and decision. This includes, refusing, aborting, failing missions. Obviously, you know what you are expected to do next (go to some planet for the next mission) in your own plug-in, but play the naive and check it's clear for people who did not do the plug-in (that is, the whole humanity bar you). Testing is not just playing, and it can be a job in itself as you need to be on the lookout for potential problems. Sometimes this means playing the same mission string over and over, just aborting mission number 23 instead of failing it; though some tricks in the debugging section can help you make this faster, it's a time-consuming job. And if you spot a problem (a mission doesn't set the good ncbs for the expected behavior), it's too late to correct it for the pilot with which you spotted the problem as he has already played the mission, and the ncbs won't be retroactively corrected, so you need to check the fix with a new pilot.
To make things clearer for your testers, but also for yourself, make clear, numbered (beta 6, for instance) releases. Don't make too many of them, it's not useful as testers can still find other bugs in a beta you already know is buggy. Take your time, then correct a number of bugs at once and package it into the next beta release. You may test with a more advanced version (than the latest beta) that includes some fixes that have not been put in a beta yet, but think to keep a copy of all the betas you distributed to your testers, so that you can reproduce the bugs that are being reported with them and check it has been corrected or not in your latest private version. Keep a log of your changes. You can take advantage of a little-known technique: plugs are loaded in alphabetical order, so resources of plugs that come later in this order override resources in plugs that come before, so you can add to your current beta plug, little plugs, each containing one fix with just the change needed (usually one resource), this way you will be able to test with or without each little fix without the need to go back and forth the plug editor, and when compiling the next beta you will just need to copy the resources from the little fixes to the main beta plug.
Don't forget to proofread all your writing, especially descriptions; running them through a spell checker can help, and your testers will always be glad to notice mistakes and suggest a correction. In a related note, try not to assume the gender of pilot as I do for you (why can't HTML have {G "he" "she"}? It's less of a problem is English, at least :)), and use these dësc mutators instead.
Remember: beta testing is the most unpredictable part of development, and that's not limited to plug-ins. Indeed, you're looking for bugs you do not know about yet, and that you sometimes don't even suspect they can exist. And at times they won't be easy to track down. As a result, you cannot predict how long the beta test will last, so try to refrain from giving release dates. Actually, I think it's better to keep your project secret or at least not that talked about throughout its development and until completion (which is possible as you can even secretely recruit beta testers), people will be much happier with the surprise and result, and you'll get less mail asking when it will be out. Aprosenf surprised everyone when he announced EVNEW to enlist people to private beta test it, and it has been a good surprise to everyone, and an appreciated one. Take advantage of the beta testing time by allowing other stuff, such as graphics, to be done while the beta test is conducted.
II: Debugging Techniques
In this part you will be introduced to tips and tricks that will make testing easier and faster. This covers gameplay tricks as well as making resources that won't be in the final plug, just for you to make testing easier, that are known as debug cheats.
The hardest part to debug is the mission strings. Not only managing all those Nova Control Bits is complicated, but if you don't pay attention you'll need to replay entire mission strings just to test the fix for the last mission. An useful trick is to create copies of your test pilot. Whenever he has completed a mission, and the pilot fiel has been saved at takeoff, switch Nova to the background and copy your pilot file (check the last modified date of the pilot to know which one is the one you're playing right now), giving the copy a name such as " pilotname M12B1T1" (if it has just done the 12th mission, in your first beta, for your first try). Then, if you notice a bug in your mission string, by outputting a pilot log of all those pilots you will be able to track down which mission you should fix, and after fixing the 13th mission (for instance), you will just need to delete the pilots including and after M13 and start back to a copy of M12 (to keep M12 in case your first fix doesn't work), that way you will be able to test your fix rightaway. Just put T2 instead of T1 in the subsequent copies to track down all that crowd of pilots; the same way, when starting the next beta, start with a virgin pilot again, and put B2 instead of B1; you can actually trash all B1 pilots. This can be useful as well if one of your missions has a R( ) random operator, you can play it with the pilot copied just before it until you've seen both possibilities. And remember: Nova can be confused if you put pilots in different places, put them all in your pilots folder, so be sure they have different names.
Sometimes there is a quite hard mission, such as the last one in your string, that you need to debug, but you don't wish to play it each time. That's not that you can't do it (or at least I hope so, people should be able to complete the games they do, or lower the difficulty!), but it's time-consuming. You can make this faster with cheats named debug cheats. Not that it's a different kind of cheat fundamentally, but the use is different, you will use it to sail through a mission string like a ship in hyperspace. Usually the best for this is the simplest: just do a bigass turreted beam with a long range and a demented damage. If missiles are a problem, a point defense beam should get rid of them. Also, a big speed, accel and turn increase can't harm; sometimes a whole debug ship can be considered. However, you should keep all that debug stuff in a separate plug file so that you don't accidently leave cheats in your plug (though sometimes you can put them back as easter eggs, actually most if not all cheats in computer games are debug cheats eventually included in the final product; just make sure they are well hidden). Also, you should check that the mission can be actually done, don't let yourself forget that the users won't have these debug cheats.
Another, different kind of debug cheat to put is simply to add a chär resource to your plug-in, that will allow you to start with enough money, a good enough ship, a good enough reputation and legal status, etc... in order to start pla- I mean testing your missions rightaway; this way you have a pilot you are sure is virgin while not having to build it up. Be aware, though, that the PC version of the game at the time of this writing (1.0.6) is not able to offer you the choice between multiple chärs; you will have to override the built-in (ID 128) one. There are many cheating possibilities that you can use, and most are useful for developing plug-ins.
Stuff you make for debug use, not to be included in the final plug, is not limited to debug cheats. For instance, you can check what the effect of modifying some ncbs in your plug would be by making outfits that have no effect, but modify a ncb when bought (by using its OnBuy field). Don't forget the effect is usually not instantaneous, you may need to lift off and land, but this way you can quickly check what ncb(s) your next mission will need to set. You can also make outfits that end a certain mission if you find out you can't complete it, or other such things, the operators in set fields are very powerful for developing plug-ins. You can also make outfits that do nothing as well, but appear only if some conditions are met (such as some Require bit), for you to check they are met, then again you can use all the possibilities of the test field operators.
Some debug cheats can be more modest, for instance if you're doing a large universe with a lot of systems, it may be worthwhile to make an uber-reactor to recharge your energy almost instantaneously so that you can visit all systems and planets without worrying about lacking energy to hyperspace. Whenever something annoys you when testing your plug, consider crafting a debug cheat to make it easier. Nothing is too small to be worthwhile.
Usually you don't give your beta testers access to this debug stuff, as they may not know how to use it, plus you need feedback on the gameplay these cheats would distort. However, you may consider giving some chosen beta testers (such as other plug developers) access to these debug cheats to help you debug some tricky and hardly accessible parts, such as the last missions in your mission string.
III: Troubleshooting
Well, you suceeded, you met a problem! First, read the list of already known problems found in the appendix as it may have already been documented, as well as its solution.
Your problem isn't there, or the solution didn't solve it? Here you will find advice on how to isolate and pinpoint it, then fix it. Remember that Ambrosia tech support can't help you troubleshoot plug-ins, it would turn into a job in itself, and David Dunham (Ambrosia's tech support guy) has already enough work as it is :).
Firstly, use your common sense. If you've experienced a crash, think what the engine attempted to do when it crashed. If it crashed at game load, then check the debug log to see what it did before crashing. Sometimes there will be explicit warnings, but sometimes not, and it had a problem with something it attempted to do; sometimes it's the last thing in the debug log, and sometimes what should have been next, check a reference debug log from a normal game load to know it. At any rate, there is something deeply wrong with some resource in your plug. If you don't know for sure which one it is, make a copy of your plug, then remove in your plug editor parts of it until it loads (no need to play, we have a loading crash to debug!) Then in the faulty part, try to find the faulty resource (maybe with the same technique), and then investigate what's wrong. Remember that out-of-bounds values are very dangerous. Especially when referencing another resource. If it crashed at pilot load, then you should check the debug log but especially the pilot log. Then again, use your common sense and think to what you did that may have to do with the pilot. It's a bad idea to modify stuff the pilot owns/ the ship he's flying/ the system and planet he's in/ the mission that he's currently making/ etc... It's an even worse one to suppress one of them. Also, something may be wrong with the system he's just in, check the problem just below. If it crashed at hyperspace exit, then something is probably wrong in the system the pilot attempted to enter. Check the debug log and pilot log, and think what may be wrong with the system itself, the ships, perses, dudes and fleets that should be flying it, the planets that should be there, etc... If it crashed at some other point, think what could happen at that point (ncb change, cron (de)activation, etc...), and check the pilot and debug logs as always. Sometimes the crash will not appear to be consistent. Think what can happen at times but not at others, such as a ship that may be faulty but not always present in the system, or a crön that can happen haphasardly. Then again use your common sense.
If it's not a crash, it's already less grave. Check the resource that isn't giving you the expected behavior. That's not always the one to blame (the previous mission may not have set the good ncbs for the expected behavior, or see the problem of ships that cannot buy anything in the appendix, for instance), but it's the most likely to blame. If it's something not available when it should, or the other way round, check that it really should behave as you expect. Missions especially, with their legal status, combat rating, ncb, Require bits, ship, etc... requirements, are just behaving as they should as you just forgot the combat rating, for instance. Check everything, in particular the currently set ncbs, in the pilot log. There are also caveats in the Bible about why missions can sometimes be unavailable (such as not finding any destination system), read them. If it's something not behaving as it should, double check what you entered in the faulty resource. Also, some features documented in the Bible do not actually work well. If you're trying to use something that's not in use in the default Nova scenario, consider it could be the case. Also, remember there are some more missing features and bugs in the PC version for stuff that's not in use in the default scenario, such as multiple-choice chärs.
Remember also that the engine has not been specifically made to handle the possibility of the scenario changing over the course of a pilot life, though it usually goes without too much problem. But sometimes using a plug with a pilot that has been created before the was plug loaded can give some odd problems. The first one being that, if you add new përses, they will never appear; technically they have been flagged as dead at pilot creation since they didn't exist. At the time of this writing, seant is crafting an utility to allow new përs to be activated, though you have to tell your users to use it. Another thing is that you should attempt to modify things the pilot owns or can own, be in, is running, etc... as little as possible, as it may cause unexpected problems and behaviors. The pilot file stores everything by ID, so things should change if the plug-in changes them, but there are a few exceptions (for instance, the list of weapons of a pilot won't be changed if the default weapons of his ship change). If you meet a problem with something the pilot is in relation to when the plug is loaded and that the plug changes, don't be surprised. For these reasons, your plug should usually be tested and played with new, virgin (yeah, right!) pilots, but there are a few exceptions. For instance if you write a storyline extension people will usually play it with existing pilots, you should therefore test that it plays well with existing pilot files, or if that doesn't work, you should state that the plug should be played with a new pilot. It can be hard to give support to allow people to play with their pilots that that were just stuck with nothing to do at the point your plug allows new missions, but this is a popular feature, and it should be adequately tested it works if you don't tell it doesn't (and even if you tell it doesn't, be prepared to handle people complaining that it doesn't work well with their preexistant pilot).
Once the problem is identified, correct it, and test your fix. Sometimes it won't work yet, it may take more that one test/fix cycle. If after some different "fixes", you still can't fix the problem, think the problems may actually lie somewhere else, and attempt to correct where you think it actually is. If you can't find where the problem is, or if you do not seem to be able to fix it, don't hesitate to ask us at the Escape Velocity Developer's Corner for insight, telling when it does crash if it does, what your plug-in is supposed to do, how you implemented it, and what does not work. It's of no use to post "my plug-in doesn't work help me!!!!" (this has been posted many, many times, and all the feedback you're going to get until you explain your problem is questions about what doesn't work). Usually we'll end up finding out what the problems is, and if we can't, it's unlikely that anyone will. But we've seen the oddest problems you can imagine, and we collectively managed to track them down; most are in the list of known problems below.
If debugging seems without an end, keep faith. Each bug, even the smallest, you're currently fixing is that many less bug reports and complaints you'll get after releasing your plug. And once you're confident you've fixed all but the problems that are both minor and hardly reproductible, think it may be time to ship. Just make sure you tried your best.
Appendix: Known issues
(note: these are to be links to the answers below) 1: I can't buy most outfits when flying my new ship 2: My ship has a bad free mass, actual free mass is more than expected 3: Nova crashes with an out of memory error 4: At load, Nova gives assertion failures and doesn't load 5: When changing or saving my plug, my editor gives me errors 6: My image seems to have been resampled, or even looks like a pixellated mess in the game 7: When attempting to change the ship color in the shïp resource, it gives absurdly colored results 8: Some planet is never the destination of random missions 9: The mission I made isn't offered 10: I put a new image in my plug to replace a ship appearance or something else, but nothing changes 11: Some weapon I made for my ship disappears as soon as I land 12: I can't buy a weapon or ammunition outfit I made or modified
1: I can't buy most outfits when flying my new ship This one is as old as Nova itself. It has to do with the Contribute and Require fields. Technically, you just need to have your new ship have the last bit set in its Contribute field. The reason for this is that though most ships can be equipped with these outfits, the Vell-Os ships, being mental projections, cannot. Technically, this is simply done by having these outfits require that last Contribute/Require bit, that all ships contribute, save for Vell-Os ships; therefore if your new ship does not contribute that bit, it will be considered a mental projetion just like the other Vell-Os ships. Unless you wish to do this, you should set the last Contribute bit of your ship's shïp resource. This bit can actually be given the meaning "the ship currently flied is a hard, physical one". Read my guide about Contribute/Require/Scanmask if you're interested.
2: My ship has a bad freemass, actual free mass is more than expected This one has been brought to the attention of the Escape Velocity Developer's Corner by Uncle Twitchy, and collectively solved by its denizens. It's because your ship comes with at least two default weapons that use up the same, not weightless, ammo; give all but one of the corresponding ammo fields a zero value, and the non-zero one the total common ammo you want it to have. The reason for this is that the actual amount of ammunition given is not the total of the amounts found in the ammo fields, but only the maximum of these amounts; check some Polaris ships (that use multiple weapons using the same ammo, wraithiis) or Aurorean ships (that have multiple weapons using chaingun rounds). But when computing the total mass (including the one taken up y the default weapons) the ship should have, the engine considers the freemass plus the one the weapons should have taken, with the sum of all ammunition, while only a fraction of it is given, and when removing from this total mass the one of the stuff that the ship actually comes with, it make for more freemass that what you wanted. In this case it's sometimes not possible to correct the Freemass as you may wish the ship to have 0 actual free mass. To correct this, you should therefore give one ammo field (corresponding to the multiple weapons of the ship) the value you want the common ammunition you want the ship to have, and give the other(s) relevant ammo fields a zero value.
3: Nova crashes with an out of memory error There can be a number of reasons for that. First, Nova may actually have run out of memory. Increase the memory partition of Nova if you're running MacOS <X. If you're running MacOS X, Windows, or if increasing the available memory doesn't solve the problem, it may be actually something completely different. In the past (i.e. EV or EVO), it may have been a bad spïn, but Nova has better error handling, and the same mistake now gives a nice error and Nova doesn't load. Check the debuglog to see where Nova failed to load.
4: At load, Nova gives assertion failures and doesn't load Read the outputted debuglog. It should tell you which resources Nova expected to find, and didn't actually find (an assertion failure is just that, some piece of code asserted some resource to be loaded, but actually it did not find it, so could not load it beforehand). One reason for that may be that you badly entered some resource IDs when filling resources referencing others, and you pointed to inexistent resources, which Nova did not find. Correct the calling resource(s). Another may be that you're attempting to do a TC by replacing all files in the Nova Files folder. Indeed, some minimal resources are absolutely needed by the engine to load, such as one ship, one system, etc...; plus, on a PC the engine needs the whole Nova.rez file, that contains the relevant resources that are inside the resource fork of the Nova application itself on Mac. The complete list is a little too complicated to be known for sure and given here, but some folks at the EVDC made a plug named absolute minimum, that contains barely enough to allow Nova to load, which is a good start to making a TC.
5: When changing or saving my plug, my editor gives me errors There can be a number of reasons for that, some specific to the editor. But if on a Mac you realise there are more than 2700 individual resources or 16MB of resource data in a single file, then the problem is there. You should split your plug in two or more files. This was more or less known by some people until I made a definitive investigation about it, which confirmed an individual Mac resource file (plug-ins are actually resource files) cannot hold more than around 2700 resources occupying at most 16MB. This is the reason the Nova data files, most TCs such as the Classic and Override port, and some plugs actually span multiple files. The universal and only workaround is to split your work between multiple files. On a PC the rez file format has none of these limitations, but if you break them your Mac testers won't be able to reliably convert your plug to the Mac format, making it unusable on Mac, therefore you should observe these rules as well.
6: My image seems to have been resampled, or even looks like a pixellated mess in the game This is likely to be the following problem, that has been investigated and brought to the attention of the EVDC by Dr. Trowel, and confirmed by pipeline. The problem is that the image has a resolution different from 72 dpi. Try to correct it in your image editor to 72 dpi. The resolution tells the "real world" density of the image, it tells how many pixels there are per inch, which in turn can be used with the size in pixels to compute the size in inches of the image. For display it is traditionally 72 dpi (72 pixels per inch). This information is actually only really useful for print, but some routines apparently consider it for display and try to display the image with a size in pixels that would make the size on screen match the real world dimension, assuming the screen has a resolution of 72 dpi, thus resampling the image to a different pixel size; finding an image a different size than the one it expected, the engine then resizes it back to its former size, but some information has been lost in the process and the image seems more or less degraded.
7: When attempting to use the ship color field in the shïp resource, it gives absurdly colored results in the game We determined with Dr. Trowel that the coloring algorithm used there was completely lunatic and unusable in the pre-1.0.8 versions of the engine. Update Nova if you can, it's fixed in the 1.0.8 update.
8: Some planet is never the destination of random missions Chances are that this planet is inside a system that can change via a ncb (visibility field). It's a (bit controverted) feature of the engine, it does not allow the random destination of missions to be a planet that may very well disappear while the pilot goes there. But if the planet (the exact same planet, with the same ID) is found in both the old and new system (i.e. the same spöb ID is found in the NavDef fields of both systems), it will be able to be a destination of random missions anew. Obviously, this is not feasible if you want that very planet to change or completely disappear in the change (but if you just want a difference in the planet description, you can use dësc mutators instead, and keep the same planet spöb resource for both before and after), so in that case you can add a mission similar to the random one, that will appear not very often but always have that planet as a destination. However, you should make so that this mission is no longer offered when the storyline comes near to the point the planet will change, and/or have the mission be aborted with a Axxx operator when the bit that changes the system is set, so that the mission is aborted if it is running at that moment; that way the player won't keep a mission he can't complete.
9: The mission I made isn't offered There can be around ten power a zillion bazillion gazillion reasons for that. Honest. First, you should check that the mission can actually be offered in the conditions you're trying to obtain it: there are requirements in the planets you can have it offered to you, and where you can have it be offered (mission computer, bar, other places), you have to have a certain record, a certain rating, the chances have to be favorable. You also have to be able to carry the offered cargo, there can be requirements on you ship type, ncbs that need to be set or not and Require bits that need to be met. Also, read the second note at the end of the mïsn section in the Bible, it tells the mission won't be offered if the engine can't find a suitable random location, you should check the debug log as it may contain the actual reason.
10: I did put a new image in my plug to replace a ship appearance or something else, but nothing changes Your replacement image is a PICT and its mask and the image you're attempting to override is a Rle. You should convert the PICTs to Rle for it to override the one found in the data file. The reason for this is that the PICT does not override the Rle; indeed the overriding rule states that if there are resources with the same type and same ID in the plug and the data files, the one in the plug has precedence and overrides the one in the data files. Not having the same resource type, the PICTs and the Rle coexist, and the using spïn or shän resource, when referencing what the ID of the image is, just references an ID, not if a PICT or Rle is expected. And if the engine has both an Rle and PICTs available at this ID, it will always pick the Rle, even if the PICTs are in a plug and the Rle is in the data files. Therefore, you have to encode the image to Rle rightaway, and then the overriding rule will apply.
11: Some weapon I made disappears as soon as I land Chances are there is no corresponding oütf for your weapon. Create one for your weapon. Even if you don't intend your weapon to be available for sale, there still needs to be an oütf that grants it for it to remain in your ship. The reason is the engine translates your weapon loadout into outfits when you land, in case they are available for exchange, and translates them back into weapons when taking off. If at landing the engine doesn't find any outfit with a weapon ModType and ModVal the ID of your weapon, it will be translated into nothing, and actually disappear. This has another consequence: don't make more than one outfit that references the same weapon, or Nova will hate you.
12: I can't buy a weapon or ammunition outfit I made or modified It may be that the OnBuy field of the oütf contains a Gxxx or Dxxx operator (and maybe another operator could cause the problem). If you really wish another outfit to be granted/deleted while this weapon or ammo outfit is bought, add Gxxx, where xxx is the ID of the outfit you're filling. This bug has been reported by Masamune and many people at the Developer's Corner: if a weapon or ammo outfit contains a Gxxx or Dxxx operator in its OnBuy field, when buying the outfit it does not actually gives it. This does not happen for non-weapon outfits. Until the bug is fixed, apply the workaround: put a Gxxx, that will give the outfit itself, in the OnBuy field.
Your problem isn't here, or the solution didn't solve it? go back to the troubleshooting section (note: "troubleshooting section" is obviously an internal link to there) and read forth for advice.
What d'ya think of it? BTW, I have little experience in actual beta testing, so please post your own experiences and avice. Also, if you experienced problems hard to track down or really common newb mistakes that are easy to solve (i.e. there is one solution), please put them so that I add them to the list of known problems.
------------------ The (url="http://"https://secure.ambrosiasw.com/cgi-bin/store/hazel.cgi?action=serve&item;=breakdown.html&BREAKDOWN;_SKUID=1480")Ambrosia Mac CD(/url) with other registrations - 5$. Paying for (url="http://"http://www.ambrosiasw.com/games/evn/")EV Nova(/url) as it's such a great game - 30$. The (url="http://"http://www.ambrosiasw.com/games/evn/tshirts.html")1337 EV Nova T-shirt(/url)(url="http://"http://www.ambrosiasw.com/webboard/Forum25/HTML/000003.html#ZachaPedro05-18-200409:42AM") (/url) - 22$. The (url="http://"http://w00tware.ev-nova.net/")NovaTools(/url) by wOOtWare to tinker with your Nova - FREE! The feeling you're a Nova geek - priceless. There are things money can't buy or that are free, for everything else, there's indeed Mastercard.
I'm going to bump this... I remember you posted a few of these right around the transition period, and I know that I missed them. Seeing as this one has no replies, I can assume the same for most of you.
~ SP
Zacha Pedro, please check this topic and make sure all of your guides are listed there.
mrxak, on Oct 2 2004, 08:05 PM, said:
Zacha Pedro, please check this topic and make sure all of your guides are listed there. View Post
Excellent question, so far I was throwing them into the wild without paying attention of them being listed. Seems that yes (except the recent templates), but let me check them on my laptop (posting from school PC) to be sure they are all here (all have originals on the laptop where I wrote them on TextEdit).
They are all here, just add the düde and spöb and s˙st ones. Though don't add the plugin intro tutorial (it's not user-usable stuff yet), nor this basic mission tutorial: this is one of my first works, and I wish to redo it.