DevSin's Changes (Q/A/Discussion)

[FredSRichardson]

I'm just going through DevSin's changes and I thought this deserved it's own thread (I'm getting in deep, and I'm going to need DevSin's help )

The changes are substantial and look like they quite significantly improve NearInfinity.  I'm just now trying to break up the changes into categories:

• Architecture Support:
Any changes for better architectecture support (versions of OS, Java, etc).  In particular, DevSin has changes for supporting MacOSX.

• Bug Fixes:
Pretty obvious: any changes that prevent program failure or incorrect program behavior.

• Enhancements:
New features or improvements.

• Coding Style:
This one is prone to personal bias on my part, but I want to try and weed out the change that represent differences in coding style so that it's easier to browse the other changes.  Sometimes a change in coding style leads to a bug fix, so this one isn't as clear cut as it seems.

As I said, the changes are substantial.  The diff file is 14000 lines (that's excluding differences in white space).  I'm going to start off by taking out the last category of changes (Coding Style) so that I can more easily review the other types of changes.  I'll post again when I get further along or when I get stuck

[Avenger_teambg]

There are 2 other alternatives:

1. blindly apply all changes, if something breaks, blame DevSin.
2. give him SF access, if something breaks, blame DevSin.

Well, just an idea

[FredSRichardson]

There are 2 other alternatives:

1. blindly apply all changes, if something breaks, blame DevSin.
2. give him SF access, if something breaks, blame DevSin.

Well, just an idea

  This is what I'd really like to do.  Based on the amount of work DevSin has done, he really should be the lead developer on this.

I don't know if he's interested in this (DevSin, are you?  Please let me know!).  But it's also worth reviewing what's there so long as someone (me) has the energy to do it.

Of course, if I completely run out of steam I'll probably accept the changes whole-sale as they are, but I at least want to try and go through them.

[FredSRichardson]

String Changes:

There are a lot of renamed fields.  Some of this is "regionalized"   (Dialog -> Dialogue), but in general the changes improve the clarity of the various field description ("L. Ring" -> "Left Ring"), in other cases there are spelling correctoins.

Mixed in with these changes are new field descriptions that were "unknown", and what are probably corrected field descriptions.  I'm not sure I'm completely qualified to review the corrected field changes or not.

Since I happen to own all the relevent games (PS:T, BG1/2/ToB, IWD1/2), I can probably at least test to make sure Dev's changes work with all the games under XP.  I'll try to be good for something

[Grim Squeaker]

Since I happen to own all the relevent games (PS:T, BG1/2/ToB, IWD1/2), I can probably at least test to make sure Dev's changes work with all the games under XP.  I'll try to be good for something Smiley

Not sure if any of the relevant code has been touched in the latest updates, but keep in mind that NI also works for NWN.

[FredSRichardson]

How well did it support NWN?  I always figured that the NWN community primarily used other tools (like the bioware ones).

JOH also mentions KoToR, but I have no idea how well that's supported.

[devSin]

You shouldn't apply my changes wholesale. If you want to do it a file at a time, you can post the filename and rough overview, and I should be able to comment on or explain some particular changes. There are also some that I don't think should be merged in, and some I feel that probably should be discussed. Discretion, of course. If I added a qualifier (like final) or something similarly uninteresting, you could just do whatever you want. If you're working on file X on a particular day, you could always just post the diff and ask for comments.

You could add me to the developers, but I probably won't ever really do any work on it, and I'm certainly not the person to maintain it. One of the reasons the code style is different is that I had no intention of distributing the changes, and turning it into something that I can easily read allowed me to work pretty quickly (I only messed with it for a couple of weeks).

For now, I'd ignore changes that simply correct, clarify, or make consistent item labels. The structure updates should be universal (the game is the same on both platforms), and I was pretty careful about checking stuff before making the change. Once these get rolled in, it can be re-diffed and these items can be considered, or they can just be left as they currently are if you run out of steam.

[devSin]

All of the Aurora data types are completely different. I did not touch any of that stuff, and none of my changes should affect Aurora file viewing (I don't think NI yet supports editing).

[devSin]

There are a lot of renamed fields.  Some of this is "regionalized" :)  (Dialog -> Dialogue), but in general the changes improve the clarity of the various field description ("L. Ring" -> "Left Ring"), in other cases there are spelling correctoins.

My region is California. ;-) "Dialogue" is always correct, never "dialog." There may be an English-speaking country out there that uses it, but I can't think of one offhand.

[FredSRichardson]

Sorry to take so long to get back here.  Everything you said makes perfect sense.  I'll definitely go through the changes more carefully.  I tend to take a more conservative approach.

I'll be able to do a bit more work on this over the weekend.

There are a lot of renamed fields.  Some of this is "regionalized"   (Dialog -> Dialogue), but in general the changes improve the clarity of the various field description ("L. Ring" -> "Left Ring"), in other cases there are spelling correctoins.

My region is California. ;-) "Dialogue" is always correct, never "dialog." There may be an English-speaking country out there that uses it, but I can't think of one offhand.

I didn't know this!  My spelling is bad enough anyway =)

[Blucher]

"Dialogue" is always correct, never "dialog." There may be an English-speaking country out there that uses it, but I can't think of one offhand.

"Dialog" is just a Biowarism I think.

Actually it is a recognized variant of Dialogue, it's just...erm...slangish. (I don't think that's a word either. )

[Rabain]

They probably did that after a dozen mistakes of typing Dialouge instead of Dialogue and I still see that mistake a dozen times a week around the fora.

[jcompton]

As has been mentioned, it _is_ a valid dictionary word, but usually more associated with programming ("dialog box") than with conversation ("holding a dialogue between the two parties.")

And amusingly, the built-in browser spellchecker doesn't like "dialogue." But then, it doesn't like "spellchecker" either, so the hell with it.

[devSin]

I should have clarified that "dialogue" is the proper spelling in the context we were discussing. Dialog is used often enough that I wouldn't consider it wrong, but it is the less proper of the two.

Modal windows are referred to as "dialogs."

Although you can, don't use "dialogue" as a verb.

[NiGHTMARE]

Let's start with the small stuff (e.g. getting people to recognize when to use "your" and when to use "you're") before moving on to more complicated things .

[Caedwyr]

Let's start with the small stuff (e.g. getting people to recognize when to use "your" and when to use "you're") before moving on to more complicated things .

Like were, where, wear, we're.

[devSin]

I put up a better build with better source of my crap. It should be a *lot* more diffriendly (all but EffectFactory), and I don't really have any reservations with just dumping in the changes en masse. There are one or two changes I'd want to make afterward, but I don't care enough right now to update the source archive. ;)

JAR
Source

EDIT: (1/9/07) source archive updated with latest changes (for Fred)
EDIT: (1/27/07) JAR and source archive updated with minor changes

[berelinde]

Is there an actual new version of NI on the horizon?

[cmorgan]

That JAR is wicked cool - lots more info. Thank you for putting it up.

[devSin]

I put it up forever ago. I hid it in Cam's playthrough bugs in the fixpack forum to keep the undesirables away. :D

It's recent enough and shouldn't contain any bugs that weren't in previous 1.33 betas, but don't use it with nuclear materials or anything. There might be a small issue with the precedence of some checks somewhere that I introduced that I'd want to reinforce, but you shouldn't ever see it. There's also a couple issues with the world map where the IESDP is wrong (for BG2, at least), some minor spelling errors, and I didn't add support for Mac NWN (I've since done it locally), but it's pretty much all I'm ever going to do with it.

Make sure to read the license if you want to modify and/or redistribute. But you should probably just wait for Fred to roll it into the SourceForge tree (someday!).

[Miloch]

Undesirables = people with little knowledge who might request enhancements?

Like for example, how hard would it be to add Ascension64's beregost.class (Tutu Beregost crash fixer) to the JAR?  I'd do it myself but I know very little (i.e., nothing) about Java.

[devSin]

Undesirables == people who don't read the fixpack forum, I guess.

You can shoot notes to Fred or igi if you have questions or suggestions; it's their project.

The JAR I've posted features only things I actually cared (and had the time) to change, but I don't have any interest in maintaining it or otherwise modifying it.

[Ascension64]

You might not need to...the Beregost thing is probably a little too wayward to add to a general editor like NearInfinity, after some thought about it. I'm working on a GUI-based version that can process SAV files directly...it's going well.

[FredSRichardson]

Okay, it's been forever and a day since I last worked on this.  And DevSin has made up for it by providing his change

I've merged in DevSin's stuff with my last release, so it really looks like DevSin's code with a few minor tweaks.  I guess the biggest difference is that my files have Windows EOL format (CRLF) while DevSin's are in Mac EOL format (CR).  The other option out there is to use *nix EOL format (LF).  I'm not big fan of Windows, but I'd settle on CRLF format so long as we can all deal with it.

I'll try to get this version up for review pretty soon.

[devSin]

I guess the biggest difference is that my files have Windows EOL format (CRLF) while DevSin's are in Mac EOL format (CR).  The other option out there is to use *nix EOL format (LF).  I'm not big fan of Windows, but I'd settle on CRLF format so long as we can all deal with it.

Say what? They better be CRLF or LF. I put my hand on the bible that I haven't saved anything with CR line endings in the last five years, and if there are CR line breaks in that code, they didn't come from me.

I edited a couple of files directly in NetBeans, which may have tried to be helpful and use CR line breaks, but I can't imagine they'd do something that stupid...

EDIT: I just checked a random sampling of the files from my local sources, and they are all LF (which I would tend to agree with when working with Java tools). Maybe yours got changed to CRLF somehow or they got fudged when pushed into the repository?