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).
@guy, on Jun 24 2008, 03:48 PM, said in RezEditor Alpha Log:
Why is that? It seems pretty straight-forward.
Of course it does when I've already given you the answer!
And I only said it was the hardest thing in the DLOG specification. DITL is much harder.
On a related note, should a Cnnn field end in a null byte? Since it's a fixed length there doesn't seem any reason to do so but just thought I'd check.
A C xxx string is filled out with nulls if the string is shorter than the specified length, but there's no additional null terminator on the end like with a CSTR.
@nonconventionally-creative, on Jun 24 2008, 05:50 AM, said in RezEditor Alpha Log:
Anybody got it to run on a Mac?
Nope, it still won't have the "Have a nice day" message appear. The same "can't be launched" error appeared.
I'm uploading alpha3 (again, earlier than I expected based on how much was done). IMPORTANT: This alpha does not have a dist folder. At the command line, switch to the build\classes folder. There, run: "java net.sourceforge.rezeditor.Main" (no quotes) (Java must be in your PATH variable - instructions from the links here.) Edit: And, in the new version, it won't pop up an error unless you do something wrong. Edit2: Also, if your JRE screams at you because net.sourceforge.rezeditor.base.TYPE (where TYPE is any resource type except Boom), congratulations because your JRE is doing more work than it needs to and eliminating the workaround used to run this before I write the full implementations for all types.
This post has been edited by Nonconventionally Creative : 24 June 2008 - 06:20 PM
congrats on getting it to an alpha stage.
@david-arthur, on Jun 25 2008, 09:29 AM, said in RezEditor Alpha Log:
I still think it would have been simple :p. Wait, shouldn't it do nothing if it's divisible by 2? Like "cursor += cursor%2". Although the DLOG could just use an ESTR (even-padded pascal string) rather than a PSTR and AWRD.
Right, so if the type is C020 then the string can be a full 32 chars long? (edit) Okay, just tested and Nova needs a null byte on the end else it carries on reading into the next field until it does find a null byte.
This post has been edited by Guy : 25 June 2008 - 05:06 AM
@general-cade-smart, on Jun 24 2008, 09:15 AM, said in RezEditor Alpha Log:
Hey Creative! Didnt you read the list carefully? The Awrd (whatever that is. Im not going to even to care to guess what it is, since not only it is awful and ununderstandable- maybe inscrutable would be better, and those words that tell how something cant be accessed or passed trough), is ignored, so you dont have to care. Got it? Ignored.
I thought I would pass on even this little help to you, because I understood this much from the list (even if I otherwise didnt). I want to do everything to help you in this awesomely interesting app- I have yet to tell how much I like this app, and how long I have waited for something to replace EVNEW (I havent told you how terrible EVNEW is either. To give you a picture of how interesting this is, I religiously read every reply by you in this topic, heck I read any reply at all in this topic. No matter how boring.
I think next time I will tell you how much I like this idea.
I actually think it means much more than that. As I read it...any of us (Windows, Mac, or Linux) can work on a .rez file in our specified operating systems without annoying conversions or manipulation of the plug. Is that right? I mean if I can use Java to open up a .rez file over here, then I can send that .rez file to someone with a windows box or someone with a Mac and they can pop open this application and work on it. That is what I read this as. Forget a replacement for simply EVNEW...it is a replacement for all the segmented editors.
Granted...it is a little early to be talking like this...but if it works...anyone with Java could work on a plug, regardless of OS. Or maybe I miss understand it...that could be a possibility too.
@guest_swithich_-, on Jun 24 2008, 06:59 PM, said in RezEditor Alpha Log:
Yep. I've even thought of maybe creating a web version, since sourceforge gives space for a website. Of course, this supposition is pointless at this point.
@guy, on Jun 24 2008, 08:35 PM, said in RezEditor Alpha Log:
Wait, shouldn't it do nothing if it's divisible by 2? Like "cursor += cursor%2".
That's what I thought, too, but it didn't produce the expected results. Hence the need for experimentation.
Okay, just tested and Nova needs a null byte on the end else it carries on reading into the next field until it does find a null byte.
Ick - that doesn't match ResEdit's behaviour. What's the point of specifying a fixed-length string if you aren't going to read for a fixed length?
@guest_swithich_-, on Jun 24 2008, 09:59 PM, said in RezEditor Alpha Log:
As I read it...any of us (Windows, Mac, or Linux) can work on a .rez file in our specified operating systems without annoying conversions or manipulation of the plug.
MissionComputer has been able to edit .rez on the Macintosh without requiring the user to convert since version 3.2, which I released in September 2005. I've also lobbied Ambrosia repeatedly (whenever an upgrade was planned) for .rez support in the Macintosh version of EV Nova.
@david-arthur, on Jun 25 2008, 06:28 AM, said in RezEditor Alpha Log:
Well, I have noticed that sometimes EVNEW allows you to enter one length and sometimes another. This might just be a bug with EVNEW, though. It usually seems to be 254 vs 255 (although I think I remember from my earlier testing that some of them are 64 vs 63 - in comments in my source files), making me think it's a < vs <= issue. One thing I just checked in EVNEW. Various fields (including the Name) take up 256 bytes, but only fit 255 characters because they require a 00 at the end. Presumably Nova's reader . I did a comparison between the hex of two otherwise identical files with only the field in question different, and the fields do not refer ahead of time to their length, like that PSTRING. Speaking of which, does that mean the PSTRING only takes up as many bytes as its first byte +1?
On another note: I've been looking at the Apple downloads page, and for 10.5.2+ (and maybe only on Intel 64-bit) they offer Java 1.6 - the compatibility issues might be because Swing is the single most-changing element of Java. Can someone try this? I looked on the online Javadoc page for Swing and some constructors/methods do include "Since 1.6", so this might be the problem. Luckily, there are older constructors/methods that should work...
@nonconventionally-creative, on Jun 25 2008, 02:05 PM, said in RezEditor Alpha Log:
Speaking of which, does that mean the PSTRING only takes up as many bytes as its first byte +1?
Correct. It isn't padded out if you give it a short string.
@david-arthur, on Jun 26 2008, 01:28 AM, said in RezEditor Alpha Log:
Hm, my own experimentation just now tells me that a) Rezilla and ResEdit both do nothing if it is already aligned, and b) MC doesn't behave how you describe, it just always adds 1.
I just tested this too and if I enter too many chars in a C020 field ResEdit will complain, saying it should have no more than 31 chars.
@guy, on Jun 25 2008, 04:19 PM, said in RezEditor Alpha Log:
Sorry, you are indeed correct - I missed a Length-1 when interpreting my code.
Update: found and squashed another GUI bug (this one relating to newly created resources that were never displayed - would have caused major issues with the command-line form). The next alpha will feature an input box that allows the user to create his own Booms by ID and then close and save them (not as a file, but within the program, so they can be opened again later - I still need to check up on how I handle the ID-changing thing - I think I'll totally change the way I keep track of resources.)
I tried alpha 3. I thought I would be joyed with improvements. You had a lots of improvements in general, even if I am not sure how it works (it doesnt seem to be standard?). But when I tried to run it, I got errors. Even if I followed the instructions to letter.
I followed the instructions to run on a command line... and put the Java 1.6 bin directory in path first thing. Then im met by this lovely confusing error message:
C:\Documents and Settings\Tom\Työpöytä\RezEditor\build\classes\net\sourceforge\r ezeditor>java net.sourceforge.rezeditor.Main Exception in thread "main" java.lang.NoClassDefFoundError: net/sourceforge/rezed itor/Main Caused by: java.lang.ClassNotFoundException: net.sourceforge.rezeditor.Main at java.net.URLClassLoader$1.run(Unknown Source) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(Unknown Source) at java.lang.ClassLoader.loadClass(Unknown Source) at sun.misc.Launcher$AppClassLoader.loadClass(Unknown Source) at java.lang.ClassLoader.loadClass(Unknown Source) at java.lang.ClassLoader.loadClassInternal(Unknown Source)
I deleted the classdir which pointed to 1.5 before adding it to the path. Then I did something so complicated and unortodox that I never should have done it- I recreated the classdir env. variable and made it point the to bin directory in Java 1.6. It still errored. It errored me 3 times, no matter what I did, in the same way?
So, now im confronted with a error about a class not being found? Why? Why didnt you supply us with the class file we need? Why did you even insist us to run class files instead of jars, which provide at least rudimentary userfriendliness? You still didnt explain why you suddenly decided to drop jars, which arent that userfriendly in themselves.
So when will you fix this, so I can open it and see how much improved it is? Because I hear you improve it a lot, finishing the Boom GUI. There was even classes for every resource, whatever that means.
The whole requirement of using command lines is awful- we have to use DOS to open a app (!). Nevermind the requirement of adding paths, which is unusual and any other programs I use havent asked.
There is some bug fix again. Too bad I wont see it yet. I dont even understand what it is about actually.
Also, I find this interesting: create his own Booms by ID and then close and save them (not as a file, but within the program, so they can be opened again later
Hmm, I wonder how you can save things without putting it into a file? That just doesnt happen. At least usually.
Oh, and when you are going to toss, junk, bin, you got it, the requirement of the command line and give us a nice .exe to click on? MissionComputer is also in alpha, but David Arthur never told us to build it from the source code. Well, sort of, as we dont literally compile it, but we still tell Java to run a source file. Not even in alpha 1.
So yeah, I'll to tomorrow to get a answer. Maybe longer, because tomorrow means "when I wake up and turn on my computer".
This post has been edited by General Cade Smart : 25 June 2008 - 06:37 PM
You have to run it from the build\classes directory, NOT the build\classes\net\sourceforge\rezeditor directory. The reason I distributed that one that way was because my IDE won't build the jar unless I do a "Clean and Build", which I can't do because I invalidated my sourcecode by recompiling the abstract superclass and adding new abstract methods.
The "saving" not to a file means that I keep track of the object, so that when it is opened again by the ID picker (in alpha4, just a stub), the same values are in the data fields as the ones you entered by clicking "OK"
As for dropping the command line requirement, that is currently gone since I removed the -ea dependency. You can just double click the jar file (which you can think of as the Java equivalent of an .exe file)... except that I don't have a .jar file for the previous reason. Maybe I'll look into the manual jar-making...
I did and...
C:\Documents and Settings\Tom\Työpöytä\RezEditor>cd build
C:\Documents and Settings\Tom\Työpöytä\RezEditor\build>cd classes
C:\Documents and Settings\Tom\Työpöytä\RezEditor\build\classes>java net.sourcef rge.rezeditor.Main Exception in thread "main" java.lang.NoClassDefFoundError: net/sourceforge/reze itor/Main Caused by: java.lang.ClassNotFoundException: net.sourceforge.rezeditor.Main at java.net.URLClassLoader$1.run(Unknown Source) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(Unknown Source) at java.lang.ClassLoader.loadClass(Unknown Source) at sun.misc.Launcher$AppClassLoader.loadClass(Unknown Source) at java.lang.ClassLoader.loadClass(Unknown Source) at java.lang.ClassLoader.loadClassInternal(Unknown Source)
C:\Documents and Settings\Tom\Työpöytä\RezEditor\build\classes>
I think this is broken big time. You need to fix this mess. You owe me a patch, a patch release, like Alpha 3a.
I figured out the jar thing and built it. So it seems I'll release alpha4 early :sigh: just like the others. Edit: meaning, the functionality I promised above is not fully implemented. Or I might spend a bit more time now and implement it. Hmm... Edit2: Yup, almost done with the new functionality. So I'll probably be early and complete.
This post has been edited by Nonconventionally Creative : 25 June 2008 - 07:39 PM
@general-cade-smart, on Jun 25 2008, 07:36 PM, said in RezEditor Alpha Log:
MissionComputer is also in alpha, but David Arthur never told us to build it from the source code.
To be fair, this is a much different sort of project - Nonconventially creative is publishing seeds early and often by comparison to my practices. I'd been working on MissionComputer 4.0 for nearly six months before I posted the first alpha, and of course it was based on a programme that had grown and matured since 2001. The seeds Nonconventionally creative is posting at the moment are more closely parallel to the private builds I designated d1 through d5, though he's updating it more frequently than I did even those. If he feels it helpful to get feedback at an early stage, then I see no reason to object.
An interesting piece of trivia I unearthed while researching this message: I spent more time on just the first alpha of MissionComputer 4.0 than I did on version 1.0 from start to finish.
DA, how do you keep track of all your resources? Right now I have an array of 32640 elements for each type, which is a waste of memory but was easier to implement when I wrote it. I'm thinking of using an object like a Vector to keep track of them (since all of the individual classes extend Resource), but I'm worried that there might be a time delay when adding new resources, especially if I have it sort itself. I've noted that the arrays do not actually contain the objects but their references, so it might not actually take that much to just do an arraycopy for the expansion, but with a lot of objects the sort might take some time... Wait, if it know it's sorted, all it has to do is bump up all the objects beyond the insertion point. Hmm... I think I'll have to write my own implementation rather than use one built into Java, but since the Java source is freely available, it shouldn't be that difficult. I think I'll do that, but feedback would still be appreciated.
alpha4 will not be up tonight, unfortunately. It's those layouts again. Speaking of alphas, there is a difference between alphas of something new and something being improved. I had noticed that.
@nonconventionally-creative, on Jun 25 2008, 09:20 PM, said in RezEditor Alpha Log:
DA, how do you keep track of all your resources?
I have a class called Resource which stores the resource's type, ID, name, and data, and has methods for reading and writing data in all the forms (PSTR, DWRD, etc.) needed.
For each resource type, I have another class, called ShipResource, WeapResource, and so on. It isn't a sub-class of Resource, but rather a wrapper for it, and has Load and Save methods which use the methods in Resource to read the data and copy it into its own properties.
When you open the shďp editor, it creates a new instance of ShipResource, giving it the desired ID and telling it to load the data. Once this has happened, it copies the data from the ShipResource's properties into its own interface, often re-calculating to represent the different possible values of each field in a human-readable form. When you save a resource, it goes through the same process in reverse. (The editors for most of the other resource types, of course, act likewise).
Resources that aren't currently in use aren't kept in memory at all; until surprisingly recently, this would have been impractical and unreliable. MissionComputer keeps a cached copy of the open file in a hidden location, and only loads a resource into memory when you ask for it; when you save a resource, it's written back to disk. I've been building a more complicated system which would store the resources in memory (in the form of an 'RFBlock' for each file) and dispense with the cached file, but it won't come live until version 4.1 at the earliest.