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).
Hey folks, several people are in the process of figuring out the .rez format, and it seems worth while to pool info. I've just been working on some RealBasic modules to transfer resource data from .rsrc files so I can get some projects I have working on windows, so I won't be much help in figuring out .rez stuff.
Just wanted to get this up in the hopes that cooperation leads to a windows editor
(though I suppose one could make an editor that edits .rsrc files which are then dropped onto teh converter to make .rez files)
-STH
------------------ Mac<-->PC pilot file Conversions: (url="http://"http://phair.csh.rit.edu/~seant/EV/PilotConvert/")http://phair.csh.rit...V/PilotConvert/(/url) "Create enigmas, not explanations." -Robert Smithson
An editor for .rsrc files would be a pain because everyone would have to download the Mac version to be able to read the game's data files.
By the way, dropping a .rez file onto the plugin-converter will generate a subdirectory containing a file for each resource, a file containing the resource map, and a file containing a script for assembling them. Not that I can think of a use for this in any way.
------------------
(This message has been edited by Mehrunes (edited 07-24-2003).)
Actually I think it would maybe be realistic too to create an application that outputs MacBinary files (.bin) that then can just be run trough the convertor. This has one major advantage : Mac Users can then play the PC-created plugs too. If you directly make .rez files they can't do that because the convertor does not work two ways.
Think about it , in my opinion PC created plugs should work on a Mac , also because Mac plugs work on a PC. I don't think making strictly a .rez editor is a good idea.
Entarus,
------------------ -Nothing lasts forever- (url="http://"http://www.AmbrosiaSW.com/cgi-bin/ubb/forumdisplay.cgi?action=topics&number;=9&SUBMIT;=Go&urgaylol;=yes")EV Developer's Corner(/url) (url="http://"http://www.ambrosiasw.com/cgi-bin/ubb/forumdisplay.cgi?action=topics&forum;=Uplink+web+board&number;=69") Uplink Forum(/url) (url="http://"http://www.apple.com")iMac, Therefore, I am(/url)
Quote
Originally posted by Entarus: **Think about it , in my opinion PC created plugs should work on a Mac , also because Mac plugs work on a PC. I don't think making strictly a .rez editor is a good idea.
**
That's an excellent point, I agree completely.
<Let me preface this by saying I know next to nothing about Windows architecture>
Is the converter app scriptable in any way? Would it be possible for some editor app to "run" a plugin through the converter?
If so, the app should be designed to create bin files and optionally convert them by pushing them through the converter.
</Preface>
------------------ (url="http://"http://www.ariossoftware.com")Arios SoftWare(/url) (url="http://"http://www.ariossoftware.com/programs/evone/")EVONE 1.0.0 - the plugin editor for EV/EVO/EVN(/url)
Originally posted by Entarus: **This has one major advantage : Mac Users can then play the PC-created plugs too. If you directly make .rez files they can't do that because the convertor does not work two ways. **
Personally, I think several changes to the mac engine would solve many problems, but I suspect I'm in the minority in seeing (url="http://"http://www.AmbrosiaSW.com/webboard/Forum26/HTML/011714.html")this(/url) as a good thing.
This sin't why I decided to swing by the board, though. I was searching for a pre-made way fro RealBasic to read resources in data forks when I discovered Forker. It's a system extension for OS9 (and lower?) which allows ResEdit to open and edit the data fork for files. (url="http://"http://www.resexcellence.com/files/forker13.hqx")http://www.resexcell...es/forker13.hqx(/url)
Hope folks find it useful.
Originally posted by seant: **Personally, I think several changes to the mac engine would solve many problems, but I suspect I'm in the minority in seeing this as a good thing.
Matt Burch said specifically that there would be no major engine changes. Do you know what sort of breach between community's you are steering at? PC only plug-ins are a bad thing both for Mac and PC users. if you make a plug-in would you not like it to be played by most possible people? And since I think at this point mac users are in the majority (also people who DON'T visit the forums). I'm sorry in my opinion you should abadon your plan for a .rez editor and stop hoping for engine changes and find a TRULY cross-platform solution , also if it does not lie within REALbasic's grasp.
Originally posted by Entarus: **Do you know what sort of breach between community's you are steering at? PC only plug-ins are a bad thing both for Mac and PC users. **
I think you misunderstand my desire: I want to see the breach between PC and Mac users closed, not opened (as outlined in more detail (url="http://"http://www.AmbrosiaSW.com/webboard/Forum26/HTML/011714.html")here(/url)). Different formats for pilot files and plugins discourages cross platform sharing. Right now, Windows users are effectively second class citizens in regards to Nova because they can't make plugins on their platform, and once they can, how many will port their plugin for use by Mac users (not to mention the waste of diskspace in having two different formats of the same plugin).
For me, I see converters as a kludgy necessity. I honestly do not know how much of a change would be necessary to implement the windows code to read .rez and .plt files on the Mac version, so I can't say whether it falls into the "minor" or "major" category. Even if it is a major change, I imagine Ambrosia could get permission from Matt and hire another programmer to make the changes if they desired; Matt deserves a break from us.
As a Mac user, I am relatively unaffected by all of this right now, but I can forsee a forking of the EVN community into Mac and Windows camps. Already, the PFTN has made a seperate category for EVNwin pilots. With the present situation, it may make more sence to have a Mac add-ons page and a Windows add-on page, which I feel will be disasterous to the community as a whole.
(This message has been edited by seant (edited 07-25-2003).)
(This message has been edited by seant (edited 07-30-2003).)
Originally posted by seant: **snip
Its seems we both want the same thing. But since there is not going to be an engine change , we might as-well look for other solutions. And I don't think a .rez editor is a good idea because plug-ins created with it will ONLY work on a PC , UNLESS the same application also outputs a normal .bin file with Mac Resources in it , OR the application uses some kind of other format and that there is both a convertor on Mac and Pc to turn it into Mac and Pc plug respectively. Therefore I think its better to look for the .bin solution right away because that is much more cross-platform friendly , Mac users only have to unpack it (run it trough an application ) and Pc users only have to convert it (run it trough an application).
See my point?
Entarus, I am currently working on doing exactly that, but it still has major flaws. My application outputs bin files, and it can also load the resources from bin files. However, after the files are converted into .rez format, there is no convertor to convert the files back into a bin.
This is why we should have either a convertor for the Macintosh version, or, preferrably, use seant's idea of having the Macintosh version of Nova able to read the .rez data format. Neither option will take considerable work, especially the first.
However, if Matt could get his hands on the code for a Win>Mac convertor, he could easily make Nova convert the plugins to the Mac format internally, and continue playing with a minor loading slowdown.
------------------ Eat blazing electric death!
Originally posted by seant: **Hey folks, several people are in the process of figuring out the .rez format, and it seems worth while to pool info. I've just been working on some RealBasic modules to transfer resource data from .rsrc files so I can get some projects I have working on windows, so I won't be much help in figuring out .rez stuff.
Are the formats of these files available anywhere? Even roughly? Is there some forum I haven't visited yet? I too would like to be able to hack at the EVN data files, and happen to be a PC user. Given file formats, I can write my own editors(and host them, once my server gets back from no-stable-connection land), but I'm not really good at figuring out binary formats.
------------------ -- Alkiera Kerithor
Here's the .rez format...
The file is seperated into 3 main sections... 1. File header (contains offsets to each resource as well as the resource map) 2. Resource Entries (the resources themselves as written in the Nova Bible) 3. Resource Map(Contains an entry number, resource type, resource ID and name of the resource in the same order the resources themselves are listed in the file) File Header & Offset list - (INTEL BYTE ORDER) 42 52 47 52 - Header LONG - 01 00 00 00 unknown LONG - Offset of end of header(before the "resource.map" line, actually it seems to always point to the first 'e' in the 'resource.map' string at the end) LONG - 01 00 00 00 unknown LONG - Number of first resource in Index (all index entries are numbered sequentially starting with this number) LONG - Number of entries in Index repeated for each resource entry { LONG - resource offset LONG - resource length LONG - Unknown ( the last entry in the list contains it's own offset, for all other entries this is 00 00 00 00) } "resource.map" - 12 byte String 00 - null terminator **everything else appears to be in Motorola byte order Resource Entries- These are defined in the Nova Bible. Each entry is immediately followed by the next Here's the format of the a few of the resource types... // 1860 bytes struct Ship { SHORT shipHolds; SHORT shipShield; SHORT shipAccel; SHORT shipSpeed; SHORT shipTurn; SHORT shipFuel; SHORT shipFreeMass; SHORT shipArmor; SHORT shipShieldRecharge; SHORT shipWeapon1; SHORT shipWeapon2; SHORT shipWeapon3; SHORT shipWeapon4; SHORT shipWeapon1Count; SHORT shipWeapon2Count; SHORT shipWeapon3Count; SHORT shipWeapon4Count; SHORT shipWeapon1Ammo; SHORT shipWeapon2Ammo; SHORT shipWeapon3Ammo; SHORT shipWeapon4Ammo; SHORT shipMaxGuns; SHORT shipMaxTurrets; SHORT shipTechLevel; LONG shipCost; SHORT shipDeathDelay; SHORT shipArmorRecharge; SHORT shipExplode1; SHORT shipExplode2; SHORT shipDispWeight; SHORT shipMass; SHORT shipLength; SHORT shipAI; SHORT shipCrew; SHORT shipStrength; SHORT shipGovmnt; USHORT shipFlags; SHORT shipPodCount; SHORT shipDefaultItem1; SHORT shipDefaultItem2; SHORT shipDefaultItem3; SHORT shipDefaultItem4; SHORT shipDefaultItem1Count; SHORT shipDefaultItem2Count; SHORT shipDefaultItem3Count; SHORT shipDefaultItem4Count; SHORT shipFuelRegen; SHORT shipSkillVar; USHORT shipFlags2; ULONG shipContributes; ULONG shipContributes; CHAR shipAvailability(255); CHAR shipAppearOn(255); CHAR shipOnBuy(256); SHORT shipDeionize; SHORT shipIonizeMax; SHORT shipKeyCarried; SHORT shipDefaultItem5; SHORT shipDefaultItem6; SHORT shipDefaultItem7; SHORT shipDefaultItem8; SHORT shipDefaultItem5Count; SHORT shipDefaultItem6Count; SHORT shipDefaultItem7Count; SHORT shipDefaultItem8Count; ULONG shipRequire; ULONG shipRequire; SHORT shipBuyRandom; SHORT shipHireRandom; CHAR Unused(68); CHAR shipOnCapture(255); CHAR shipOnRetire(255); CHAR shipShortName(64); CHAR shipCommName(32); CHAR shipLongName(128); CHAR shipMovieFile(32); SHORT shipWeapon5; SHORT shipWeapon6; SHORT shipWeapon7; SHORT shipWeapon8; SHORT shipWeapon5Count; SHORT shipWeapon6Count; SHORT shipWeapon7Count; SHORT shipWeapon8Count; SHORT shipWeapon5Ammo; SHORT shipWeapon6Ammo; SHORT shipWeapon7Ammo; SHORT shipWeapon8Ammo; CHAR shipSubtitle(64); USHORT shipFlags3; SHORT shipUpgradeTo; LONG shipUpgradeCost; LONG shipSellValue; SHORT shipEscortType; CHAR Unused(16); // 192 Bytes struct Govt { SHORT VoiceType; USHORT Flags; USHORT Flags2; LONG ScanFine; SHORT CrimeTol; SHORT SmugPenalty; SHORT BoardPenalty; SHORT KillPenalty; SHORT ShootPenalty; SHORT InitialRec; SHORT MaxOdds; SHORT Class1; SHORT Class2; SHORT Class3; SHORT Class4; SHORT Ally1; SHORT Ally2; SHORT Ally3; SHORT Ally4; SHORT Enemy1; SHORT Enemy2; SHORT Enemy3; SHORT Enemy4; SHORT SkillMult; USHORT ScanMask; CHAR CommName(16); CHAR TargetCode(16); ULONG Require; ULONG Require; SHORT InhJam1; SHORT InhJam2; SHORT InhJam3; SHORT InhJam4; CHAR MediumName(64); ULONG Color; ULONG ShipColor; SHORT Interface; SHORT NewsPict; CHAR Unused(16); }; // 1860 Bytes struct Miss { SHORT AvailStel; SHORT Unused; SHORT AvailLoc; SHORT AvailRecord; SHORT AvailRating; SHORT AvailRandom; SHORT TravelStel; SHORT ReturnStel; SHORT CargoType; SHORT CargoQty; SHORT PickupMode; SHORT DropOffMode; USHORT ScanMask; SHORT Unused; LONG PayVal; SHORT ShipCount; SHORT ShipSyst; SHORT ShipDude; SHORT ShipGoal; SHORT ShipBehav; SHORT ShipNameID; SHORT ShipStart; SHORT CompGovt; SHORT CompReward; SHORT ShipSubtitle; SHORT BriefText; SHORT QuickBrief; SHORT LoadCargText; SHORT CompText; SHORT FailText; LONG TimeLimit; SHORT CanAbort; SHORT ShipDoneText; SHORT Unused; SHORT AuxShipCount; SHORT AuxShipDude; SHORT AuxShipSyst; SHORT Unused; USHORT Flags; USHORT Flags2; SHORT Unused; SHORT Unused; SHORT RefuseText; SHORT AvailShipTyp; CHAR AvailBits(255); CHAR OnAccept(255); CHAR OnRefuse(255); CHAR OnSuccess(255); CHAR OnFailure(255); CHAR OnAbort(255); LONG Require; LONG Require; SHORT DatePostInc; CHAR OnShipDone(255); CHAR AcceptButton(32); CHAR RefuseButton(32); SHORT DispWeight; CHAR Unused(17); }; Resource Map- **this is the last entry in the offset index. LONG - Unknown (always 00 00 00 08 from what I've seen) LONG - Number of resource types in the file repeated for each type of resource included in the file { 4 Byte String - Resource type name LONG - Offset from beginning of resource map to first entry of that type LONG - Number of entries of that resource type } repeated for each resource entry { LONG - Index of resource in file starting from the number defined in the resource.map 4 Byte STRING - resource type ("spn", "shn", "bm"...) SHORT - Object ID (in game terms, i.e. Federation govt is ID 128) 256 Bytes - ANSI String - Object 'Name' (any additional space is filled with buffer overrun) } EOF
The .rsrc format is very similar. Hope that helps.
That looks like what I was looking for, thanks. I detest all-caps type names, tho. All-caps anything, for that matter. All hail 'Find and Replace...'
Originally posted by Mehrunes: **Here's the .rez format...
**everything else appears to be in Motorola byte order
First, are you saying the endian order switches half way through the file??
I believe the resource format is very similar indeed. I guess I am the only one coding C, but if more were, someone should simply "port" the Macintosh Resource Manager to work with the rez format. i.e. GetRezResource, AddRezResource, WriteRezResource etc. Doing so would let Mac apps read and write the files natively and would make the process elementary.
The resource format has to be public knowledge, and if not, someone must of reverse-engineered it by now. Anyone willing to do a quick comparison?
Originally posted by Mehrunes: **The .rsrc format is very similar. Hope that helps. **
See (url="http://"http://developer.apple.com/documentation/mac/MoreToolbox/MoreToolbox-99.html#HEADING99-0")http://developer.app...tml#HEADING99-0(/url) for data structs on macintosh rescource forks. This structure is the same for .rsrc data fork based resources.
Originally posted by AriosSw: **
**<HR></BLOCKQUOTE>
First, are you saying the endian order switches half way through the file??(/B)
Exactly. Everything in the first section is Little Endian, everything else is Big Endian.
The resource format has to be public knowledge, and if not, someone must of reverse-engineered it by now. Anyone willing to do a quick comparison? (/B)
The problem is two-fold. The people who did WinEVN didn't do what you suggest, they made a way to convert the resource-fork data into normal data, and changed the EVN engine to work with this new data format.
The problem is a major difference in the way files are stored under Windows and MacOS... Windows uses vfat, which just has one place to store data in a file. MacOS uses hpfs(?), which apparently gives a file 2(or more, I dunno) places to store data... a data fork, which is just like the windows one, and a resource fork, which is where all the EV data is stored. To store Mac files under Windows and maintain that resource data requires a special format, called MacBinary(.bin). This format isn't toooo horrid, but really isn't exactly convienient.
Porting the Mac Resource Manager would require the permission of Apple, which, well, isn't likely, IMHO.
As a side note, I also work in C/C++(under windows) which will be rather handy when I have to convert all these Big Endian numbers around.
Mehrunes, you obviously know a lot about the .rez file format. Did you hack all of that yourself or did you get it from ATMOS or Contraband? Do you also happen to know the .bin file format for Mac plug-ins?
------------------ C:dos C:dosrun rundosrun
I figured it out myself, but I don't know the details of the .bin format. I'm wondering what is necessary for the Mac to use the base .rsrc files, as then Windows plugin distribution could be in that format to avoid handling the Mac .bin format.
Originally posted by Mehrunes: I figured it out myself, but I don't know the details of the .bin format.
The official MacBinary specification.
Originally posted by Mehrunes: I'm wondering what is necessary for the Mac to use the base .rsrc files, as then Windows plugin distribution could be in that format to avoid handling the Mac .bin format.
A Mac-based application to convert back and forth between standard resources and .rsrc is trivial - such things already exist, but I could probably throw together one that's specifically targeted for EV Nova if there's any demand.
------------------ David Arthur | (url="http://"http://davidarthur.evula.net/")davidarthur.evula.net(/url) | (url="http://"http://www.ev-nova.net/")EV-Nova.net(/url) Truth! Justice! Freedom! And A Hard-Boiled Egg!
(This message has been edited by David Arthur (edited 07-30-2003).)
Originally posted by Alkiera: **MacOS uses hpfs(?), which apparently gives a file 2(or more, I dunno) places to store data...
Macs use HFS+. Also, to be picky, Mac files can have unlimited forks - adding them with the file manager is trivial The reason you do not see a lot of multiple fork files is that, well, no one bothers.
Originally posted by Alkiera: **Porting the Mac Resource Manager would require the permission of Apple, which, well, isn't likely, IMHO.
No no no. I do not mean an official port, which would be completely unnecesary. Perhaps a porting layer would more accurately describe it. Just a bunch of the commonly used functions that have names very similar to the real Mac functions, but would instead write to rez or bin files. That way, the actual app code would have to undergo few changes to write to the new files and this "layer" would just transcribe the data into the correct format.