Having never developed an OXP, the only disadvantage I noticed with Notepad is the lack of displayed line-breaks when viewing Unix formatted text files. (As an aside, I never heard anyone speak quite that highly of Windows Me - in my opinion, having only very briefly used it at a friend's place, the biggest problem after lack of Unicode was its FAT32-imposed file size limitation. The commonly-cited problem with crashes after resuming from sleep when some USB device had come unplugged was just a config issue, then?)
As an aside, I never heard anyone speak quite that highly of Windows Me - in my opinion, having only very briefly used it at a friend's place, the biggest problem after lack of Unicode was its FAT32-imposed file size limitation. The commonly-cited problem with crashes after resuming from sleep when some USB device had come unplugged was just a config issue, then?
I don't know about that. "Out of the box" it was a shocker. But I found most of the problems seemed to be caused by System Restore (a shiny, new feature in ME). Once I learnt how to disable that it just hummed along. I didn't see a BSOD for years (and never had an occasion when I thought, "I wish I could do a system restore."), until the computer started playing up a few months before it finally gave up the ghost. I wish my current celeron/Win7 notebook was as reliable. It freezes up almost daily.
Now, about this converting <pointyBrackets>XML<pointyBrackets> business. It's very simple XML with no attributes, mixed namespaces, or other hoopla, so a CSS stylesheet should be all you need. You just need to know all the the possible element types... <string></string> <array></array> <key></key> etc...?
After reading SandJ's list of ideas (now deleted) I was able to see that I have left out some additional areas that this thread should cover. These are:
Correct packing of the OXP. Including documentation and Change Logs files.
Version numbering.
Licensing & copyrights.
Documentation writing.
Wiki entries for OXP.
I am about to add these to the first post
To start here are few points for the Basic Dos and Don'ts:
Dos:
Always comment your code. It helps both you and others later if you put comments in your code that explains what each function does or what certain parts of the code do. The more thorough the commenting is the easier debugging and maintaining is.
Always indent your code. Either use a tab or a fixed set of spaces for each level of indenting. If you uses tabs always use tabs. If you use n spaces always use n spaces. Doing this will indent your code consistently so it is much easier to read and to find the relationship between parts of the code.
Don'ts:
Do not create global variables always do this.<varname> = <value/expression> never do var <varname> = <value/expression> that are not inside a function. Reason is because the var ... form when not inside a function is global and that variable name could already be used by some other OXP. Using "this" to declare them makes the variable part of the worldScript object that is your script and therefore will never clash with a variable from another OXP. Generally there is no need to create a global but if you find a reason to do so it is suggested you prefix the variable name with the name of the OXP. (This reduces the chance of a name clash)
Do not hard code System names in mission screen and manifest screen instruction texts. Instead use the code "%Jxxx" where xxx is the number of the system. (e.g. "Go to LAVE main station to collect Agent Jones" should be "Go to %J007 main station to collect Agent Jones".) The reason for doing this is that names of systems can be altered by OXPs so you can't be guarantee that it will always be the name you hardcoded into the text. "%Jxxx" is one of the codes that get automatically substituted in mission and description texts.
Chat and relax with other commanders in the [url=irc://irc.oftc.net/oolite]DS's Seedy Space Bar[/url]. The Coolest Bar in the Eight.
Correct packing of the OXP. Including documentation and Change Logs files.
Don’t put your OXP and its documentation in a folder also called <something>.oxp. It causes confusion about what actually constitutes the OXP, and on Macs the entire folder will appear as a single file so the documentation can’t be seen.
Correct packing of the OXP. Including documentation and Change Logs files.
Don’t put your OXP and its documentation in a folder also called <something>.oxp. It causes confusion about what actually constitutes the OXP, and on Macs the entire folder will appear as a single file so the documentation can’t be seen.