Pocket Plane Group

Friends and Neighbors => Near Infinity => Topic started by: Taimon on March 14, 2008, 07:48:14 PM

Title: Concerning v1.33b19
Post by: Taimon on March 14, 2008, 07:48:14 PM
I have been tinkering with v1.33b19 lately (devSin's version precisely) and intend to use this thread as some kind of feedback/question/bugreport platform.
It's a bit sad that v1.33 never got a proper release, since the codebase changed a lot compared to 1.32. Lets hope Fred finds his way back into the forums.

Anyway, the first thing that really annoyed me was, that, if you have a lot of cre files in override, and you start up NI and click on a dialog file, NI seems to freeze for some time (40s on my install). It is creating a script compiler instance which in turn gathers all creature and area names for later verification. I tried to fix this locally by moving the indexing in a SwingWorker (requires Java 1.6 unfortunately) and deferred script compilation until you click compile (or simply view the relevant code in an edit view when "Autocheck BCS" is enabled). Also added some notification in the status bar.

I noticed another small compiler/decompiler bug: When compiling an Integer, NI does some kind of unsigned -> signed conversion, if the value is too big for a signed int (> 2^31 - 1). This is done by subtracting 2^32. Upon decompilation this is reversed, but the condition was faulty (only checked for < 0) and so compile/decompile of "HappinessLT(Myself, -289)" would lead to unexpected results.
However, is this whole conversion really needed? I'm not so firm with scripting engine details.

Is there a list of release-critical bugs in v1.33b19? I may spend some time trying to fix some of them.

Ah, and if anyone is interested in diffs or something, just let me know.





 
Title: Re: Concerning v1.33b19
Post by: devSin on March 14, 2008, 09:09:03 PM
Anyway, the first thing that really annoyed me was, that, if you have a lot of cre files in override, and you start up NI and click on a dialog file, NI seems to freeze for some time (40s on my install). It is creating a script compiler instance which in turn gathers all creature and area names for later verification. I tried to fix this locally by moving the indexing in a SwingWorker (requires Java 1.6 unfortunately) and deferred script compilation until you click compile (or simply view the relevant code in an edit view when "Autocheck BCS" is enabled). Also added some notification in the status bar.
This should occur regardless of the override contents (file access will be slower, but meh, it has to be done)? Trolling through to get the script names is lame, but it should only happen once, so the damage is fairly minimal (less so than upping the version requirement yet again, at least). It shouldn't launch into its full gathering until you actually hit a node with triggers/actions (e.g., view a dialogue with code for State 0 or switch to edit view and browse the action/trigger list), but the decompiler does need it for its compile/decompile check (to populate the warnings list with invalid script names). Deferring isn't necessarily bad, but you have to spend the time somewhere, and I can't think of many cases where building the list early is untenable (even if you don't need it right then, you will eventually when looking at code that references script names, even if not changing anything, or if you want to run the BCS checker).

That 40s is dreadful, though (40ms, maybe, hopefully?). With ~2500 CREs in the override (not to mention hundreds of AREs), it'd be rare for me to see a 4s delay opening when opening the first script or dialogue.

I noticed another small compiler/decompiler bug: When compiling an Integer, NI does some kind of unsigned -> signed conversion, if the value is too big for a signed int (> 2^31 - 1). This is done by subtracting 2^32. Upon decompilation this is reversed, but the condition was faulty (only checked for < 0) and so compile/decompile of "HappinessLT(Myself, -289)" would lead to unexpected results.
However, is this whole conversion really needed? I'm not so firm with scripting engine details.
Probably not, but there may be some purpose to it (the sign/unsign conversion is done in other places, so I just decided not to bother even thinking about it). In BG2, the BCS ints (all of them, I think) are signed, which is why you'll get some -1 values spit out as 2^32 (even though the compiled script gets the signed value). Stupid in lots of cases, but not so bad when working with ORd state values (otherwise, you have to do the conversion yourself).
Title: Re: Concerning v1.33b19
Post by: Taimon on March 16, 2008, 04:35:31 AM
My description on the first problem was really inaccurate. You are right on most parts. It only happens if the script compiler is involved (i.e. the dialogue file has triggers or actions and you are viewing them) and there is no instance already.

Sadly, the 40s are true for my older system. (Harddisk is 3 years old and I'm still using Win2k.) I have like 3500 cre files in override. (I know, I should biff them.) Thinking about it, when the average access time is ~10ms and the harddisk doesn't do some tricks like waiting for multiple request and answer them in one turn, the 40s seem appropriate for 3500 files. Windows does have some kind of file cache, so if you close NI and reopen it, the whole procedure is much faster. (I actually did write some test code and it took only half a second if the files are cached.)
The main reason for the deferring was, that it really takes that long the first time. If it only took 3 seconds, I wouldn't mind building the list early.
Maybe I rewrite the indexing thread, so that it doesn't need SwingWorker. (It just was the quickest solution.)

I'm not so sure what to do about that unsign/sign conversion. Will investigate further, if I find some time to do so. For the moment I just disabled the signed -> unsigned conversion in the script decompiler (which strangly is only applied if there is some IDS mapping in the action which uses the integer).
Title: Re: Concerning v1.33b19
Post by: devSin on March 16, 2008, 06:20:30 AM
The problem with dialogues is that the code is all stored as plain (not compiled) text -- if you disable the compile/decompile check when assembling the Viewer components, it's going to be fairly rare that the dialogue code is ever checked (unless you hit Compile Check when writing or changing your dialogues, you're never going to know if something is wrong). It works for Autocheck BCS since the code has to be decompiled to be displayed anyway (and you must recompile to save any changes), but dialogues would happily let you write nonsense code without any indication that anything is wrong if they don't force the comp./decomp. routine. I also don't know how disabling the auto-compilation would affect the dialogue code checker or the reference searcher (although, the reference searcher doesn't actually pick up references in dialogue triggers/actions, so I don't think it'd make much difference there).

Only disabling the conversion of nr to a positive value will cause some failure with giant numbers (the (de)compiler will barf if it encounters a large unsigned DWORD in something like a combined state check, for instance). I haven't looked into other places where it might fail, so it might require additional changes elsewhere (or special handling for code that commonly has negative numbers, but only as a last resort).
Title: Re: Concerning v1.33b19
Post by: Taimon on March 16, 2008, 02:26:08 PM
Well, I thought, that if you want to save your changes to a dialogue file, you first have to click "Update". And this should automatically invoke the check compile. But nevertheless, I now see your point with doing the compile/decompile on the viewer, since the decompile does transformations like replacing the number on a state check with the ORed strings from state.ids. (You mentioned it before, but stupid me didn't understood it then.)
I'm still wondering why the "indexing" on your computer is so much faster.

Concerning that (nr < 0) check in Decompiler.decompileInteger: I re-enabled it, and put it in the next if statement (that checks if this is a flag value like state). Solved the HappinessLT issue and hopefully doesn't break anything else.
Title: Re: Concerning v1.33b19
Post by: devSin on April 13, 2008, 11:19:05 PM
Concerning that (nr < 0) check in Decompiler.decompileInteger: I re-enabled it, and put it in the next if statement (that checks if this is a flag value like state). Solved the HappinessLT issue and hopefully doesn't break anything else.
OK, finally had a look at this. Since everything here is bitwise, the signedness doesn't really matter. You should be able to get rid of the sign conversion entirely and replace the IDS walk loop condition with nr != 0 && bit < 32 (~L:267) and the "your IDS is bahroken!" condition with nr != 0 (~L:279).
Title: Re: Concerning v1.33b19
Post by: Taimon on April 14, 2008, 10:53:57 AM
Yep, this is probably the best solution.
I also changed the unsigned &rarr; signed conversion in compileInteger to a simply (int) typecast.
(Same could be done for the writeUnsigned* methods in util.Filewriter. I'm not even sure the current check there is correct.)

Btw, someone should start commenting Near Infinity. :)
Title: Re: Concerning v1.33b19
Post by: devSin on April 14, 2008, 11:24:25 AM
I also changed the unsigned &rarr; signed conversion in compileInteger to a simply (int) typecast.
I: params in BCS need to be signed 32-bit ints, so the conversions here won't ever break anything (not much reason to just cast to int, and it all has to be ASCIIized anyway).

(Same could be done for the writeUnsigned* methods in util.Filewriter. I'm not even sure the current check there is correct.)
Actually, the conversions there should be totally pointless with an explicit data size (e.g., any single-byte value - 256 is going to give you the same byte as the original value)? It shouldn't be making any difference in the value written in the few places it's used (IIRC, writeLong() is consigned to only a few datatypes), so probably not worth changing.
Title: Re: Concerning v1.33b19
Post by: Taimon on April 14, 2008, 12:02:54 PM
I: params in BCS need to be signed 32-bit ints, so the conversions here won't ever break anything (not much reason to just cast to int, and it all has to be ASCIIized anyway).
I just found
Code: [Select]
// unsigned -> signed conversion
return String.valueOf((int) Long.parseLong(value));
easier to read than
Code: [Select]
long nr = Long.parseLong(value)
if (nr >= 2147483648L) {
  nr -= 4294967296L
  return String.valueOf(nr);
}
else
  return value;
So its only aesthetics.

Quote
Actually, the conversions there should be totally pointless with an explicit data size (e.g., any single-byte value - 256 is going to give you the same byte as the original value)? It shouldn't be making any difference in the value written in the few places it's used (IIRC, writeLong() is consigned to only a few datatypes), so probably not worth changing.
Yep.
That's why I wanted to remove the check, because the typecast already takes care of this. (With a possible exception with that writeUnsignedThree). But you are right: it's probably not worth changing.
Some should point me to the real problems. :)
Title: Re: Concerning v1.33b19
Post by: devSin on April 14, 2008, 12:09:04 PM
CHR->CRE conversion is disabled and broken, if you want to fix it. It basically exists to convert a CHR (where the engine puts structures that change at the bottom) to a CRE (where the toolset/editor order structures in a more ordered fashion).

There's also a bug for BAM playback when switching to a cycle with no image data when the BAM is animating (the play button gets stuck enabled and can't be disabled until you switch back to a cycle with > 1 frames) that I haven't looked into yet.
Title: Re: Concerning v1.33b19
Post by: Taimon on May 29, 2008, 06:58:16 AM
Huh? Somehow I did not see your last post until now. Will take a look at those two things.

But I actually had a question about the biff editor: Is it intended that only files from the chitin.key are listed there?
Someone may have biffed the override and you will actually delete files from that bif if you copy a single file into it.
Title: Re: Concerning v1.33b19
Post by: devSin on May 29, 2008, 10:31:21 AM
The BIFF editor (and key cleanup) is so irredeemably evil that I'd just as soon not touch it. :-)

But I thought all override files get listed in the right panel (with BIFF contents only in the left panel)?

A resource kinda has to be in the key if it's in the BIFF or else there's no real way to account for it (we're certainly not going to walk the BIFF to see if all the key entries comprise the entire BIFF).
Title: Re: Concerning v1.33b19
Post by: Taimon on May 29, 2008, 10:52:01 AM
Okay, here's the deal: Someone had installed IWD casting graphics from BG2 Tweaks but didn't like it and wanted to revert to the standard animations. He had biffed the override (Mega install or something). I don't think there is a way to get the original casting graphics from spelanim.bif with Near Infinity now. (besides undoing the override bif, which made a backup of chitin.key)
Title: Re: Concerning v1.33b19
Post by: devSin on May 29, 2008, 01:55:30 PM
If they're the same name, sure. NI (and the game) can only go on what the key says, and it now says those resources are in the custom override BIFF (as far as they're concerned, the originals don't even exist).

He could always restore the original key, grab the original files and dump them in the override, and then go back to the old key, but there's not really some way to work around the fact that the key is *the* index of BIFF contents, and we pretty much have to look where it says to look for any particular resource.
Title: Re: Concerning v1.33b19
Post by: Taimon on May 29, 2008, 02:10:55 PM
Yeah, you are right, forget it. I thought we could somehow get the names of the files in the BIFF without a KEY file, but this is obviously not the case. Thanks for your answers.
Title: Re: Concerning v1.33b19
Post by: Taimon on June 01, 2008, 05:23:41 AM
Do you have a example BAM for that playing button bug?
Title: Re: Concerning v1.33b19
Post by: devSin on June 01, 2008, 12:32:49 PM
Not offhand (you'd have to find one that has multiple cycles but no frames for later cycles). I can't remember which BAMs they were, and I'm not currently working with BG2.
Title: Re: Concerning v1.33b19
Post by: Taimon on June 03, 2008, 03:52:10 PM
Nevermind, I simply changed the frame count for one cycle to zero to reproduce.
Looks like a very minor GUI issue.
Code: [Select]
--- infinity/resource/graphics/BamResource.java
+++ infinity/resource/graphics/BamResource.java
@@ -102,11 +102,22 @@
     }
     else if (event.getSource() == bnextanim) {
       selectedAnim++;
+      // stop timer if no frames in cycle
+      if ((timer != null) && timer.isRunning()
+          && (anims[selectedAnim].frameCount == 0)) {
+        timer.stop();
+        bplay.setSelected(false);
+      }
       selectedFrame = 0;
       showFrame();
     }
     else if (event.getSource() == bprevanim) {
       selectedAnim--;
+      if ((timer != null) && timer.isRunning()
+          && (anims[selectedAnim].frameCount == 0)) {
+        timer.stop();
+        bplay.setSelected(false);
+      }
       selectedFrame = 0;
       showFrame();
     }
Title: Re: Concerning v1.33b19
Post by: Taimon on June 22, 2008, 09:38:08 AM
I did some hackery to allow undoing multiple dialog file conversations. Might have some side effects on memory usage, though.
Code: [Select]
--- infinity/resource/dlg/Viewer.java
+++ infinity/resource/dlg/Viewer.java
@@ -52,6 +52,7 @@
   private State currentstate;
   private Transition currenttransition;
   private boolean alive = true;
+  private DlgResource undoDlg;
 
   Viewer(DlgResource dlg)
   {
@@ -142,15 +143,27 @@
     bundo.setEnabled(false);
   }
 
+  public void setUndoDlg(DlgResource dlg) {
+    this.undoDlg = dlg;
+    bundo.setEnabled(true);
+  }
+
 // --------------------- Begin Interface ActionListener ---------------------
 
   public void actionPerformed(ActionEvent event)
   {
     if (!alive) return;
     if (event.getSource() == bundo) {
+      if(lastStates.empty() && (undoDlg != null)) {
+        showExternState(undoDlg, -1, true);
+        return;
+      }
       State oldstate = lastStates.pop();
       Transition oldtrans = lastTransitions.pop();
-      bundo.setEnabled(lastStates.size() > 0);
+      if (lastStates.empty() && (undoDlg == null)) {
+        bundo.setEnabled(false);
+      }
+      //bundo.setEnabled(lastStates.size() > 0);
       if (oldstate != currentstate)
         showState(oldstate.getNumber());
       if (oldtrans != currenttransition)
@@ -202,16 +215,7 @@
         else {
           DlgResource newdlg = (DlgResource)ResourceFactory.getResource(
                   ResourceFactory.getInstance().getResourceEntry(next_dlg.toString()));
-          alive = false;
-          if (NearInfinity.getInstance().getViewable() == dlg)
-            NearInfinity.getInstance().setViewable(newdlg);
-          else {
-            ViewFrame frame = (ViewFrame)getTopLevelAncestor();
-            frame.setViewable(newdlg);
-          }
-          ((Viewer)newdlg.getDetailViewer()).showState(currenttransition.getNextDialogState());
-          ((Viewer)newdlg.getDetailViewer()).showTransition(
-                  ((Viewer)newdlg.getDetailViewer()).currentstate.getFirstTrans());
+          showExternState(newdlg, currenttransition.getNextDialogState(), false);
         }
       }
       if (alive) {
@@ -323,6 +327,26 @@
         transTriList.add((ResponseTrigger)entry);
       else if (entry instanceof Action)
         actionList.add((Action)entry);
+    }
+  }
+
+  private void showExternState(DlgResource newdlg, int state, boolean isUndo) {
+
+    alive = false;
+    if (NearInfinity.getInstance().getViewable() == this.dlg)
+      NearInfinity.getInstance().setViewable(newdlg);
+    else {
+      ViewFrame frame = (ViewFrame)getTopLevelAncestor();
+      frame.setViewable(newdlg);
+    }
+    Viewer newdlg_viewer = (Viewer) newdlg.getDetailViewer();
+    if (isUndo) {
+      newdlg_viewer.alive = true;
+    }
+    else {
+      newdlg_viewer.setUndoDlg(this.dlg);
+      newdlg_viewer.showState(state);
+      newdlg_viewer.showTransition(newdlg_viewer.currentstate.getFirstTrans());
     }
   }
 
Title: Re: Concerning v1.33b19
Post by: Taimon on July 20, 2008, 03:14:24 PM
Again some hacks to further improve "navigating" in the resource tree.
Introduced "crosslinks" in scripts to quickly get to the relevant resource.
(For example right-clicking on the spell in ForceSpellRES should bring you to the SPL file.)
Title: Re: Concerning v1.33b19
Post by: cmorgan on July 21, 2008, 09:31:24 AM
Are these integrated into the SourceForge materials, or should I (beg) PM you for a copy of the tinkered-with NI in .jar?
Title: Re: Concerning v1.33b19
Post by: Taimon on July 21, 2008, 11:08:38 AM
I didn't commit anything on sourceforge. (Not sure, if I'm even allowed to do that.)
PM me your mail address or I can upload it somewhere, if you want to.

Note that these changes are only hacks and not solid code.
It's mostly usability stuff for me.

I haven't done a changelog either, so who knows what else I changed.
Title: Re: Concerning v1.33b19
Post by: Miloch on July 21, 2008, 01:27:52 PM
Well, you're just continuing the tradition of previous developers :).  I think it's GNU GPL, so you can mod and upload it as you like (as long as you include the GNU license and whatever else it requires).  Someone should probably just host this somewhere properly (on a site that doesn't have persistent latency issues, if such exists).
Title: Re: Concerning v1.33b19
Post by: Taimon on July 22, 2008, 04:15:39 PM
jar (http://www.gomf.de/taimon/NearInfinity.jar)
src (http://www.gomf.de/taimon/NearInfinity.zip)

Needs Java 1.6 (SwingWorker). No support, sorry. :)

Changes as far as I can remember:
Title: Re: Concerning v1.33b19
Post by: cmorgan on July 22, 2008, 05:53:26 PM
Thank you! Nabbed it...
Title: Re: Concerning v1.33b19
Post by: Taimon on July 26, 2008, 07:17:52 AM
Updated.

Minor changes:
Title: Re: Concerning v1.33b19
Post by: Taimon on December 10, 2008, 11:10:50 AM
Small Update.

More dialogue tweaks:
Title: Re: Concerning v1.33b19
Post by: Taimon on August 05, 2009, 07:31:18 AM
With various people adding there own stuff to NI I'm planning to push this on github to make merging easier.
Any interest in this?
Title: Re: Concerning v1.33b19
Post by: temujin_ on August 05, 2009, 07:16:21 PM
yes there is.  anything that emerges from that highly evolved, superior, german engineered, aryan brain of yours is always interesting. :)


btw, who are the various people that are maintaining NI?  so far, the only one i could see recently is Kung Fu Man (his version seems very polished and bug-free, but he doesn't have the 'crosslinking' feature and other improvements that you added).  so maybe this github could be useful...
Title: Re: Concerning v1.33b19
Post by: cmorgan on August 05, 2009, 11:57:47 PM
Big interest from me - I am having trouble on vista64 and the latest  javascript/.net upgrades, but on the XP side NI is my primary investigative tool, with DLTCEP as a crosscheck.
Title: Re: Concerning v1.33b19
Post by: Taimon on August 06, 2009, 01:26:48 AM
Besides Kung Fu Man, I think at least devSin is updating his copy to incorporate the more recent file format information.
It would probably need some convincing to get him to push his stuff on github, though. :)
Title: Re: Concerning v1.33b19
Post by: devSin on August 06, 2009, 01:20:47 PM
Word.

My formats should be pretty much up-to-date complete, but there were only a few things I stole from Taimon's build since I didn't need any of the other stuff (and won't bump the Java requirement to 1.6). I believe it also contains the final work to make it as close to Jon's b19 as possible to facilitate moving code between the two, but with Fred gone, it hardly matters. Also some bugs with funky IWD scripts that may have come after I pushed my code to Taimon, and I believe changes to script name gathering to improve it (but it's not deferred like Taimon's).

My sources are always available (but currently outdated), though, so somebody else could merge them if desired.
Title: Re: Concerning v1.33b19
Post by: Taimon on September 03, 2009, 03:52:54 AM
Sources are on github, now. (http://github.com/taimon/NearInfinity/tree/master)
(Small build script included. Requires ant, though.)
Title: Re: Concerning v1.33b19
Post by: cmorgan on September 04, 2009, 10:13:55 PM
Can you toss a link to a place you trust for a beginner who has only compiled minor weidu beta stuff using step-by-step directions from the bigg? Looking for an introduction to compiling so I can build for either Vista x64 or Win XP SP3 from your posted source. I am not afraid of diving in over my head, but would prefer not to dive into a pool filled with rocks instead of a liquid of some kind...
Title: Re: Concerning v1.33b19
Post by: devSin16Bits on September 04, 2009, 10:22:00 PM
Can you toss a link to a place you trust for a beginner who has only compiled minor weidu beta stuff using step-by-step directions from the bigg? Looking for an introduction to compiling so I can build for either Vista x64 or Win XP SP3 from your posted source. I am not afraid of diving in over my head, but would prefer not to dive into a pool filled with rocks instead of a liquid of some kind...
Ant is so ghetto 1990s.

Download NetBeans, install, create a new project with the "existing sources" template, have the "infinity" folder inside a clean folder somewhere (after downloading from github), select the parent folder (where the infinity folder is), wait for it to roll the joint, then smack the build button.

Presto. Instant .jar.

Note that I totally broke PST .gam viewing, at the least. The whole thing probably should have stayed in the oven for another year or two before I sent it out.
Title: Re: Concerning v1.33b19
Post by: Taimon on September 06, 2009, 05:51:45 AM
Ant is so ghetto 1990s.
The build.xml is just for convenience and ant is the only java build tool I had on my laptop. :)
Title: Re: Concerning v1.33b19
Post by: Sam. on September 06, 2009, 03:27:37 PM
Download NetBeans, install, create a new project with the "existing sources" template, have the "infinity" folder inside a clean folder somewhere (after downloading from github), select the parent folder (where the infinity folder is), wait for it to roll the joint, then smack the build button.

Presto. Instant .jar.

I did exactly this, and when run, the resulting .rar doesn't start NearInfinity.  Do I really want "Java Project with Existing Sources" or should I use "Java Free-Form Project" which seems to make use of the "build.xml"?  I tried both and couldn't get either to work.  Without having any kind of knowledge on this subject, my guess would be that the .jar isn't linking to the .java file that is the visual base ("main class"?) for NearInfinity.  It would be <infinity/NearInfinity.java>, right?  Any clue what I'm doing wrong?

TIA,
Sam.
Title: Re: Concerning v1.33b19
Post by: devSin on September 06, 2009, 05:02:23 PM
Not really, sorry.

Make sure you have the Java JDK 1.6 (the latest 1.6u16). (Yeah, if it compiles, you surely do.) If you right-click on the project in the projects pane and select Properties, one of the panels will be run properties (allowing you to set the name and main class and custom args and such). Ensure that the main class really is set to infinity/NearInfinity.java (you shouldn't need to change anything else).

And don't throw away the folder you selected with "pre-existing sources" (that's where your actual source code stays!). The junk in the NetBeansProjects folder is just the bytecode and build scripts and built .jars. If it still doesn't work, you should try the "Run" button from within NetBeans. This will compile the project and run it (it can run straight from the bytecode if it wants to). If it still fails, it should at least tell you why it's not starting up in the results console.
Title: Re: Concerning v1.33b19
Post by: Sam. on September 06, 2009, 07:37:16 PM
If you right-click on the project in the projects pane and select Properties, one of the panels will be run properties (allowing you to set the name and main class and custom args and such). Ensure that the main class really is set to infinity/NearInfinity.java (you shouldn't need to change anything else).
That was it, thanks.  I figured that was the problem but didn't know how to set it.

On another note, I suppose any issues that are found should now be reported on github, correct?  Or should we even bother?  Are the author(s) interested in suggestions or will they stick to working on their own agendas?

Thanks,
Sam.
Title: Re: Concerning v1.33b19
Post by: Taimon on September 07, 2009, 03:35:29 AM
As far as I'm concerned, post suggestions/bugs in this forum.
Title: Re: Concerning v1.33b19
Post by: cmorgan on September 07, 2009, 10:08:44 AM
Thank you!  8)
Title: Re: Concerning v1.33b19
Post by: devSin on September 07, 2009, 04:05:39 PM
The build.xml is just for convenience and ant is the only java build tool I had on my laptop. :)
Actually, Ant is pretty modern compared. (And apparently, it comes standard on Mac OS X or with Xcode, since it looks like I have some version installed here.)

But for somebody who just wants to compile and use it (and maybe later segue into development), we have nice IDEs to recommend (unlike years of WeiDU build nonsense with ocaml and make and apparently cygwin on Windows).

As far as I'm concerned, post suggestions/bugs in this forum.
Ditto.
Title: Re: Concerning v1.33b19
Post by: Taimon on September 08, 2009, 02:41:28 AM
But for somebody who just wants to compile and use it [...], we have nice IDEs to recommend
I don't see your point here. If ant (and jdk/jre) is already installed, I find typing one single command much easier than setting up a project in an IDE. But maybe it's just me.
Title: Re: Concerning v1.33b19
Post by: devSin on September 08, 2009, 04:03:16 AM
I'm not talking about what's easiest to build.

I'm talking about how easiest to tell people to build.
Title: Re: Concerning v1.33b19
Post by: Taimon on September 09, 2009, 12:43:03 AM
Ah, now it makes at least some kind of sense. :)
Title: Re: Concerning v1.33b19
Post by: devSin on December 18, 2009, 07:03:34 PM
And... I pushed up a small update to my source archive (should be an easy diff; still not doing git). Has a smidgeon of Planescape love to enable GAM viewing again (I actually wasn't the one to break it, turns out).

For the interested, and if you want to update the sources sometime next year.
Title: Re: Concerning v1.33b19
Post by: Taimon on December 26, 2009, 11:21:12 AM
Thanks for the pointer. Merged and pushed it to github.
Title: Re: Concerning v1.33b19
Post by: devSin on December 26, 2009, 11:45:29 AM
Ah, you beat me.

I made a small change for an issue where the history menu could hang (if you open up enough different installs, we end up with lastGamePath.size() being 6); my change is super lazy, but I couldn't see we'll ever legitimately get lastGameID.size() != lastGamePath.size(); feel free to rewrite anyway.

New sources up, now with ID2 love too (5:20 PM).
Title: Re: Concerning v1.33b19
Post by: Taimon on January 08, 2010, 08:20:11 AM
Blindly applied. I'm sure you know what you were doing. :)
Title: Re: Concerning v1.33b19
Post by: devSin on January 08, 2010, 10:26:18 AM
That actually kind of looks like an old version. :( There are some changes in there that were temporary (and embarrassing); is it from a fresh download (maybe there's a stale cache somewhere along the way)?

I should probably just give up and git, but I'm hoping this can be the last push for most the year. I'm well and truly beginning to hate the one-size-fits-all code again, which means I stop messing with it for a year or so now. ;-)

EDIT: For any concerned, fresh sources are usually here (http://homepage.mac.com/akay/NearInfinitySrc.zip).
Title: Re: Concerning v1.33b19
Post by: Taimon on January 08, 2010, 11:41:03 AM
That actually kind of looks like an old version. :( There are some changes in there that were temporary (and embarrassing); is it from a fresh download (maybe there's a stale cache somewhere along the way)?
Should have been from yesterday or the day before. Just checked that the gamePath.size() thing was there and thought it was good.

I'll check out the new version.

/Edit:
Can you give me an indication of what exactly is considered "old"? Maybe something went wrong when I cherry-picked the merge-diff.
Title: Re: Concerning v1.33b19
Post by: devSin on January 08, 2010, 11:52:24 AM
Nah, it just looks like an old archive (those are really changes that were there yesterday or the day before).

I updated it late last night (PST) with the last of the changes, and the current push is just missing most of it (and still has those nasty (De)Compiler comments).

Sometimes it can get a little tough to follow since I still diff to Jon's "official" b19 sources and toss out unnecessary differences, which leads to code changing in strange ways (appearance-wise). But it's not like he or Fred are coming back; I probably shouldn't bother anymore, but what can you do.

EDIT: OK, probably final edits up (23:40). You should probably toss the projectile arrays; I'm not really happy with them being there (nuking the one in EffectFactory is still fine tho because it had no real use). I think the best thing would be to try and extend ProRef to actually do something useful (or a more generic 'IdsRef or this static Bitmap' class), but I don't have the strength. Wouldn't make a difference in BG2 anyhow. There are still some dumb bugs in IWD scripting, but it's not my fault and I don't care anymore, (There might be another bug in the history code, but it's better than it was.)

Not really any good changes this year, I guess, but at least it got some small structure updates for the less worthy IE games.
Title: Re: Concerning v1.33b19
Post by: Sam. on January 09, 2010, 09:23:56 AM
When I try to run the latest commit on GitHub (cf1f67b) after compiling, I get the following error message in the command console:
Code: [Select]
Exception in thread "main" java.lang.NullPointerException
        at javax.swing.ImageIcon.<init>(ImageIcon.java:167)
        at infinity.icon.Icons.getIcon(Icons.java:19)
        at infinity.NearInfinity.<init>(NearInfinity.java:124)
        at infinity.NearInfinity.main(NearInfinity.java:117)

A debug with NetBeans returns:
Code: [Select]
debug:
Have no FileObject for C:\Program Files\Java\jdk1.6.0_17\jre\lib\sunrsasign.jar
Have no FileObject for C:\Program Files\Java\jdk1.6.0_17\jre\classes
Exception in thread "main" java.lang.NullPointerException
        at javax.swing.ImageIcon.<init>(ImageIcon.java:167)
        at infinity.icon.Icons.getIcon(Icons.java:19)
        at infinity.NearInfinity.<init>(NearInfinity.java:124)
        at infinity.NearInfinity.main(NearInfinity.java:117)
Java Result: 1
BUILD SUCCESSFUL (total time: 4 seconds)

It seems to build but it doesn't run.
Title: Re: Concerning v1.33b19
Post by: devSin on January 09, 2010, 10:48:54 AM
That shouldn't happen! I don't think there were even any changes I made that would get you failing way up there.

Try using the source archive I linked to a few posts back; tested to work under Vista with Java 1.6.0b17 (you can also download it pre-compiled by replacing 'Src.zip' in the URL with 'Beta.jar' when downloading, for the time being).
Title: Re: Concerning v1.33b19
Post by: ScuD on January 09, 2010, 07:19:58 PM
I've no such error building NI from the latest sources.
Title: Re: Concerning v1.33b19
Post by: Sam. on January 09, 2010, 09:12:29 PM
I'm experiencing the same error with the version linked to a few posts back.  I am compiling with NetBeans and am setting the Main Class to "infinity.NearInfinity".  Have I forgotten something important since the last time I compiled successfully?  This is my setup:
Quote
Product Version: NetBeans IDE 6.8 (Build 200912041610)
Java: 1.6.0_17; Java HotSpot(TM) Client VM 14.3-b01
System: Windows XP version 5.1 running on x86; Cp1252; en_US (nb)
Userdir: C:\Documents and Settings\User\.netbeans\6.8
Title: Re: Concerning v1.33b19
Post by: ScuD on January 09, 2010, 09:45:53 PM
Sorry, I'm using Ant to build the code. I've never used NetBeans.
Title: Re: Concerning v1.33b19
Post by: devSin on January 09, 2010, 10:06:14 PM
Were you able to compile previous versions? Did you install the JDK, and is it up to date?

It looks like you're missing some Java components (that compile isn't even getting off the ground)?
Title: Re: Concerning v1.33b19
Post by: ScuD on January 09, 2010, 10:46:35 PM
An idea - you may have JRE libraries in your classpath instead of JDK. Not sure about that though.
Title: Re: Concerning v1.33b19
Post by: Sam. on January 11, 2010, 05:13:48 PM
Well, I reinstalled my JDK and NetBeans and now it's compiling just fine.  Still don't know what the problem was.  Thanks for the suggestions anyway.
Title: Re: Concerning v1.33b19
Post by: Taimon on January 12, 2010, 09:10:56 AM
Okay dev, new merge from today's version. Could you take a quick look at the diff?
Title: Re: Concerning v1.33b19
Post by: devSin on January 12, 2010, 02:26:52 PM
Looks good. Sorry it took so much back and forth.
Title: Re: Concerning v1.33b19
Post by: Taimon on January 13, 2010, 11:44:25 AM
No big deal and thanks for checking.