The first public annoucement...

Well i said first public annoucement of it, but what actually meant to say was the first public description of what its basic features will be.

I have just passed 2 months development of iNova, phew, and i feel you all may like to know exactly what is happening, and this way i may get some even better feature requests. All current requests are excepted until they are deemed unfeasable. I hope to have a public release (not complete thing) by the end of the year

iNova 0.2.9 Features and Screen Shots
Well apart from the beta testers, no one knows this stuff yet, so your the first. iNova has gone a completly different path to the traditional EV Nova Editors. Ditching the Resource Fork format for the most part it now relies heavilly on the Mac OS X Bundling system. Basically iNova will add several new kinds of bundle extension to the system, .inova is the main one. Inside these bundles will be all the information about the plugin. When you wish to open an exisiting ResourceFork based plugin you will be required to "Unpack" it in to the bundle format. You can also create an empty bundle to start work on from scratch as you would expect. When you have complete the plugin that is in bundle form you then "Pack" it back in to a ResourceFork.

Bundles are basically just folders, and data inside them is just text files and jpegs. All of those work on windows and linux. Hmm, you windows users will be getting part of iNova afterall.

If you think that is cool though, which it is, sort of, then prepare to like iNova even more. For all plugin developers today the #1 biggest problem, that none of you mentioned, are bugs. They are unavoidable. How many times have you gone in to EV:N to test a part of your plug and a nice big juicy bug pops up outta nowhere. You then go back in to your editor and scan through hundreds of resources and things to find its cause. I don't know about you but i hate it.

Well this is where iNovas main feature comes in to play. The Debugger. I have tested this, it has not been released to the testers yet, but its working a treat. I scanned one of my personal plugins which i had gone through and looked for errors in, and it detect almost all of them. Of course i still got to add all the kinds of errors you might encounter so it will take a while to fully complete it. It also finds all NCB Expressions in the plugin and allows you to search them, quickly and easily, just like spot light. This feature is looking promising, and i'm spending a lot of time on it. The debugger along is already over 10000 lines of code , and is nowhere near done.

Also just on a side not i have made it so iNova does a "syntax colouring" on the NCB's and allowed you to add comments into the NCB's which are removed upon packing. Here is a sample NCB Expression
( p0 & b226) & !b227 {Comments are allowed too}

OK, I also have some screen shots you may be interested in. Note i still have a hell of a lot to do on this, so it will change, as the look has already changed from previous iNova screen shots i have posted.

well I hope that i can get a bit of feed back on the features i have started and partily completed so far. I still have a lot to do, and i hope you will all like it when its done.

Tom Hancocks

I must say, this looks pretty sweet. So if EVNEW were to implement the ability to "pack" data in and out of .rez files in the same way then it would make it pretty easy to share plug-ins between platforms.

DaGekkoMan, just bell me if you want Nova-style backgrounds for the interface. It looks fantastic!

Dave @ ATMOS

Awesome, I always wanted someone to make an editor that doesn't tie me down to the actual plugin files to find something. Although it seems to me that you'd pack Nova plugins into a bundle, and unpack a bundle back into individual Nova readable plugin files.

I do have a couple questions:

1. What resources will iNova eventually edit? Are you going for things like graphical system editors, or just the text based stuff?

2. How will iNova handle going from multiple plugin files to a bundle and back again? It'd great if you could specify plugin files name for different resource types. As in store all universe data (Syst, Spob, ect) in a file called "Blah Universe" and all landing pictures in the files "Blah Landing Pics #" But have it customizable so the user can choose the names and which resource types went into which file names.

3. Are you still looking for beta testers

Nice bryce models in the background..

Seriously this sounds great.

I´ll bet most of the TC/Large plugin developers here will love this.

How about Spotlight-type search of all fields? eg. If I want to find all resources (ships and outfits) that reference weapon RID# blah.

And I certainly hope it doesn't store images and sprites as JPEGs...

It looks like it could be cool, but then again I haven't been much dissatisfied with Nova Tools for what I've done so far. That might change as I do more, of course.

Oh, another thing: I really think that it should have a method of working directly from a plugin, or a temp-unpack folder. Often I find that, except for the delay in starting Classic, I like to be able to jump into ResEdit, pop open a file, look at a couple resources, tweak one setting, save, and go to test it in Nova. Repeat from "jump into ResEdit". To be a really useful tool, I personally think iNova would need to be able to support that kind of really quick tweaking process. If you can do that, and it has a nice interface, it could be a really awesome app.

This post has been edited by Weepul 884 : 26 February 2005 - 07:39 PM

Excellent. Too bad I can't use it

MacOS 9.1 and all.

modesty_blaise_us, on Feb 26 2005, 07:03 PM, said:

Nice bryce models in the background..

Seriously this sounds great.

I´ll bet most of the TC/Large plugin developers here will love this.
View Post

Of course we will.

DaGekkoMan, on Feb 26 2005, 02:17 PM, said:

Hmm, you windows users will be getting part of iNova afterall.
View Post

Traitor!! Guards, seize them!

Nice work! Looks impressive even in its beta stage!

Ragashingo, on Feb 27 2005, 12:34 AM, said:

3. Are you still looking for beta testers
View Post

One question I can answer.

All users of Jaguar and Panther are welcome, though I have to say we are more Panther users so far, and Jaguar users will therefore be even more welcome.

Drop by the iNova forums to offer your help.
(it also contains support and announcements, so those not wanting to beta-test can also drop by to see where the work is at)

Fnoigy, on Feb 26 2005, 09:33 PM, said:

Traitor!! Guards, seize them!

Nice work! Looks impressive even in its beta stage!
View Post

Alpha stage. The fact the "Unpacked" plugins can be opened on windows is merely a side effect.

I may do a method of opening actuall resources forks, as i realize some people will not like the idea of unpacking/packing

Yes iNova will have graphical editors. I have allowed you to edit the plugins by text files is so that you are not limited by the editors that i create.

I hope to have graphical editors for most of the resources, but don't be surprised if some are not there, as this will only be the first release and things like Mission Computer and EVone never had all the graphical editors implemented when they first launched public versions.

One of the tabs reads "NCB's" when it should read "NCBs" - the apostraphe before an S indicates the possessive. </spelling nazi>

Looks fantastic. Will click-and-dragging images/sounds and/or converting image and sound formats be supported?

Hopefully. I do plan on spending a while on developing this.

On a related note, is there any REALbasic programmers here who would be interested in helping out? Drop me a PM if you are

DaGekkoMan, on Feb 26 2005, 03:17 PM, said:

Bundles are basically just folders, and data inside them is just text files and jpegs.

Weepul already spotted this -- I just gotta second it. JPEG is a lossy format -- isn't there going to be image degradation when the PICTs in a resource fork are JPEG-ed?

For play-testing of plugs it would be convenient to have a system that did resource-plug / bundle-plug conversions in the background upon open and save, but if you stick with JPEG it seems to me it would make for repeated losses of image quality each time a plug is saved.

I see what your saying, it should be easy enough to transfer to another format. I merely used JPEGs at the moment for testing purposes, but i gotten so use to seeing JPEG files that i keep say JPEG's

I would suggest using TIFFs instead. Lossless, and it avoids any potential problems that might arise from the Windows incompatibility with JPEGs inside PICT wrappers.

Lindley, on Feb 27 2005, 01:28 PM, said:

I would suggest using TIFFs instead. Lossless, and it avoids any potential problems that might arise from the Windows incompatibility with JPEGs inside PICT wrappers.
View Post

Definitely. TIFFs are what professionals use when they take digital camera shoots. Ever experienced a messed up JPEG pic when a TIFF version of the exact same thing was 10x better?

Yes -- TIFFs are good. PNGs might work well enough, too. I’m not as familiar with that format’s abilities.

To minimize file bloat (since download time matters to lots of people), I think it would be best if your program could export these three color depths, and could keep track of when to use each:

• 1-bit black and white -- used for sprite masks.
• 8-bit, 256 colors -- used in “legacy” graphics made for EV & EVO.
• 16-bit, 32768 colors -- used for many off the graphics in the EVN stock scenario.

Some of the graphics in the EVN stock scenario are 32-bit, millions-of-colors images, but I don’t know if the game engine actually displays these differently from 16-bit images.

There’s also the issue of image resolution -- strange and terrible scaling disasters happen if Nova comes across a PICT that specifies a dpi (dots per inch) resolution other than 72. For example, I can paste this image into ResEdit, at 600 dpi:

and Nova will show me this:

My explorations of this problem are mixed into the discussions in this thread. Apparently ATMOS ran afoul of this problem too -- it messed up some nebula pics. Since iNova is going to have to deal with image format conversions anyway, it would be great if the program could correct this problem by adjusting image resolutions without resampling.

It’s gonna be great to have another editor in my toolbox -- I’m really looking forward to your debugger!

Will iNova leave EnRLE'd resources in their RLE format?

Anaxagoras, on Feb 27 2005, 11:50 AM, said:

Definitely. TIFFs are what professionals use when they take digital camera shoots. Ever experienced a messed up JPEG pic when a TIFF version of the exact same thing was 10x better?
View Post

Actually...(I just have to chime in here) TIFF isn't really used much at all. It makes for very large files, and eats up memory. For event shooters and sports shooters, JPEG actually can be best as it's relatively fast to preview, transfer, process if needed, and publish. They're taking thousands of these, so space and speed concerns are pretty important.

When quality is the key, RAW format is the way to go. Each camera manufacturer has their own "format" for it, but it's all the same idea: the data straight off the sensor, not demosaiced, nor color nor tone corrected. This is smaller than a TIFF because most sensors are set up with a bayer-pattern color mosaic, where each pixel location only records red, green, or blue, not all three. Afterward, these are turned into a full-color image.

Not that that is really relevant. :rolleyes:

This post has been edited by Weepul 884 : 27 February 2005 - 08:07 PM

Weepul 884, on Feb 27 2005, 08:06 PM, said:

<snip>
View Post

Crap. I can't believe all my art magazines lied to me. Bastards.