Ambrosia Garden Archive
    • Nova Files renamed for clarity


      Know what's what, where.

      Someone asked recently where they could find a list of all the weapon IDs, and was directed to Nova Data 4. This reminded me of a bit of minor organizational cleverness that I've implemented in a copy of my Nova Files folder, which I've renamed "Nova Files Original for Research." It's nothing terribly impressive, but perhaps someone else will find it useful.

      Very simply, I've renamed the files in the folder, as follows:

      Nova Data 1CharGovtJunkMisnShip
      Nova Data 2DudeOopsRankSpobSyst
      Nova Data 3 Cron Desc
      Nova Data 4 outf pers pict weap
      Nova Data 5 Desc Nebu Str#
      Nova Data 6 boom desc flet roid
      Nova Graphics 1 cicn pict ppat
      Nova Graphics 2 rle8 rleD spin
      Nova Graphics 3ColrIntfSpinStr#
      Nova Music
      Nova Ships 1 rle8 rleD shan
      Nova Ships 2 rle8 rleD shan
      Nova Ships 3 rle8 rleD shan
      Nova Ships 4 rle8 rleD shan
      Nova Ships 5 big shipyard Picts
      Nova Ships 6 big shipyard Picts
      Nova Ships 7 desc pict shan
      Nova Ships 8 rle8 rleD shan
      Nova Sounds snd
      Nova Titles 1 picts
      Nova Titles 2 pict landings
      Nova Titles 3 pict landings
      Nova Titles 4 pict landings
      

      This saves me considerable time each time I need to hunt down a resource for inspection.

      File name lengths are limited to 32 characters so they work in Mac OS 9 -- I've since switched to OS X, but haven't expanded the names. If anyone wants to suggest improvements to the scheme, fine! I know there are a couple seldom-tweaked resources I missed in a file or two, and some of the file names are short enough that there is still room to add a bit more detail (which descs are which, perhaps?) without going over the 32-char limit of our poor OS 9 chums.

    • Wow, great idea... I always just memorized what was in the files, but this is certainly much more useful for development purposes. In fact, just having this list published somewhere would be a great help to many new developers...

      ~ SP

    • I always found ATMOS's layout ridiculously complimicated. Even better than this would be a rearrangement of the files so that they are more logical. For example put all descs and STR#s in one data file, all ships, weapons, and outifts in another, etc.

    • I took this a step further Dr.Trowel. Instead of renaming the Nova data files I made the data files more granular by separating each type of resource into an individual file. Here's an excerpt from a debuglog.txt:

      opening files in Nova Files folder:
        data.bööm
        data.chär
        data.crön
        data.düde
        data.flët
        data.gövt
        data.jünk
        data.mďsn.Auroran
        data.mďsn.BountyHunter
        data.mďsn.Federation
        data.mďsn.GenericDeliveries
        data.mďsn.GLiTech
        data.mďsn.MultipleUsage
        data.mďsn.oütf
        data.mďsn.përs
        data.mďsn.Pirate
        data.mďsn.Polaris
        data.mďsn.Rebel
        data.mďsn.Sigma
        data.mďsn.SpecialKlavs
        data.mďsn.Terraform
        data.mďsn.Tutorial
        data.mďsn.UnitedShpg
        data.mďsn.Vellos
        data.mďsn.WildGeese
        data.nëbu
        data.oütf
        data.öops
        data.përs
        data.ränk
        data.röid
        data.shďp
        data.spöb
        data.STR#
        data.s˙st
        data.wëap
        dësc.bars
        dësc.mďsn4-6K
        dësc.mďsn7-32K
        dësc.oütf
        dësc.spöb
      

      This arrangement makes it much easier to swap out the default scenario resources during TC development.

      This post has been edited by Arturo : 24 February 2005 - 02:41 AM

    • Arturo, on Feb 24 2005, 03:30 AM, said:

      I took this a step further Dr.Trowel. Instead of renaming the Nova data files I made the data files more granular by separating each type of resource into an individual file.

      Hm! I like Arturo's method. The advantage of my method is that renaming the existing files is much less work than shuffling all the resources around. I don't know if ASW & the add-ons page manager (pipeline) would be OK with Arturo posting a complete but reorganized copy of the Nova Files, but if they would allow it, it would be mighty fine....

      Another issue is identifying and adjusting for file content changes each time a new version of Nova comes out. Again, probably easier with my method, but Arturo's re-org is much more thorough.

    • That does look pretty handy. I wouldn't worry about new versions of Nova though. ASW seems to be waiting indefinitely on Contraband to catch up on their part before releasing 1.0.9.

    • Contraband officially has nothing more to do with it. 🙂 Nova for Windows has been moved in-house to Ambrosia.

      As for the data layout, it's a hangover from a data structure that changed every day for 5 years. 😄

    • pipeline, on Feb 24 2005, 06:08 AM, said:

      Contraband officially has nothing more to do with it. 🙂 Nova for Windows has been moved in-house to Ambrosia.
      View Post

      Really!?
      WOO-HOO!!
      Now maybe we'll finaly see some progress on winnova 1.08.

    • Heh. Ironically, I don't have this problem, since AppleWorks with a ConText of the Nova Data files is (almost) always open (yeah, I mean, right now, when browsing the web). If I need to lookup something, I look it up there first, then if I need to change it, I just need to check the D column and open the relevant file.

      So, Contraband has officially nothing more to do with WinNova (at least the maintaining?) At least, this clears up the things.

    • Ah, now that's good news. 🙂
      Don't suppose you could give us any indication of the current status?

    • I can't say too much (not my place), but I will say that Windows Nova is on the to-do list for Ambrosia's coding team, but there are other things that take priority at the moment -- number one a ColdStone/PoG update that has been very long awaited.

      Dave

    • Dr. Trowel, on Feb 24 2005, 02:35 AM, said:

      The advantage of my method is that renaming the existing files is much less work than shuffling all the resources around.
      View Post

      Actually the resource granulation method doesn't really take much time to create. Splitting up the resources by type only takes less than an hour to do. On the other hand, splitting up the missions into their respective strings took literally weeks to accomplish. What made splitting the missions into the individual strings difficult is the fact that none of the strings use fully contiguous blocks of mďsn RIDs. Each string usually consists of one or two main blocks of RIDs grouped together along with a smattering of lesser RID groups and another smattering of scattered individual RIDs. First I dumped all the Nova mďsn resources to a spreadsheet using wOOtWare's ConText utility. Then I had to go through all 791 of them to make sure that the hidden mďsn subtitle (you know, the part of the mďsn name after a semicolon) was meaningful and correct (this took most of the time). Then sort the spreadsheet based on the subtitles. Then split the main spreadsheet into individual string spreasdsheets based on those subtitles. Then use wOOtWare's ResStore utility to recreate the mďsn resources grouped by string. whew

      Since the v1.0.9 release will in all likelihood be the last revision made for EV:Nova, it would be a real boon for TC developers if ASW/ATMOS were to make v1.0.9 with the data files granulated in this fashion, or maybe even splitting up just the resources, never mind the mission string splits.

    • Hmm. Id prefer Trowels if only it showed what kind of desc each desc block was. Though, Im working more on TC than just plugins, so its only marginally useful. For testing, though, would be nice.

    • That sounds like a useful thing to do with the missions. I've currently got two research files, one with every non-graphic resource except dësc, and one with all the dëscs (although I think that I may have lost some of the resource names from that one due to over-population of resources- 3031).

      This post has been edited by Edwards : 25 February 2005 - 10:56 PM

    • For a second, I thought the title of this thread was "Nova Files creamed for charity". . .

    • Edwards, on Feb 25 2005, 08:50 PM, said:

      I think that I may have lost some of the resource names from that one due to over-population of resources- 3031.
      View Post

      You may or may not be aware of the inherent resource limitations. See Limitations of the resource fork and End of file message, ResEdit for details concerning those limits.

      ....................................

      Fnoigy, on Feb 25 2005, 11:35 PM, said:

      For a second, I thought the title of this thread was "Nova Files creamed for charity". . .
      View Post

      We really don't need your spamming here (or in your other two recent EVDC posts) on the EVDC. If you've got something on-topic and helpful, that's fine. But random chatter belongs somewhere else.

      This post has been edited by Arturo : 26 February 2005 - 02:51 AM

    • Those threads are why I mentioned the possible excess of resources 🙂 .
      Also, I just checked, and no, as far as I can tell, none of those dëscs' names or contents are corrupt.

      EDIT: I just read Zacha Pedro's post halfway down the first of those threads, and that is exactly what I got when I tried to combine the two files.

      This post has been edited by Edwards : 26 February 2005 - 08:07 PM