1168 replies to this topic

[Sam.]

The dos command prompt screen flashes too quickly for me to see what the problem is exactly, but after multiple times proving that it's faster than the eye, I did see something that looked like it couldn't find the .jar, or didn't recognize the file format or name of the beta 20 NI .jar file. I have Java 6 update 27 installed, so I'm not sure what the problem is. [edit] It's definitely not Java as I can run various versions of NI fine as long as I launch the .jar file itself; just can't get the HideNI app or any .bat files to launch them.

Ok, it sounds like you haven't set up the correct path to NearInfinity in Hide NI DOS. To do this, create a .bat file in the same folder as "Hide NI DOS.exe" and add the following lines:

"Hide NI DOS.exe" -config
"Hide NI DOS.exe" -about

Then run it. On the config menu, select the path to your NearInfinity Java ARchive (*.jar). You can change the other settings here as you please. (It did explain all of this in the provided readme, but I keep forgetting no one actually reads the readme...)

Does it work now?

[Ithildur]

It works now, thanks! I had manually set the path to the correct directory previously (via editing the config file) and it wasn't working...

@Jarno: Thanks for the Dos command reminder. Yes, the jar files and the batch and exe files were in the same folder. Seems like the problem is the batch file/dos can't find/recognize java or javaw exe file for some reason.

Regardless, the above method did the trick; thanks again.

[Sam.]

I am glad you got it working Ithildur.

I have updated Hide NI DOS to v1.02 and uploaded it to the first post. The changes are as follows:

• Replaced writing, running, and hiding .BAT files with corrupt?s CMDret function. (NI seems to load faster now.)
  
• Fixed input parameters so that ?-about? and ?-config? can be used at the same time.
  
• Added option to enable logging of console output (disabled by default).
  
• Added support for specifying additional custom parameters only via editing the config file manually. See the readme.

If a few people could try it and tell me if it works, that would be great. If everything seems OK I will delete the old version from the first post.

[i30817]

I don't suppose there is a way to get this to work with Generalized Biffing right?

Because, currently, i can't even compile a script (in both DLTC and NI)..


And i don't suppose no one thought to try the drag and drop in linux, because it is not working (i've done some java apps in the past and i know some Dataflavors mimetype can fuck up, varying by platform).

Edited by i30817, 18 October 2011 - 08:30 AM.

[Sam.]

I don't suppose there is a way to get this to work with Generalized Biffing right?

Because, currently, i can't even compile a script (in both DLTC and NI)..

I don't understand what the problem is... How would the Generalized Biffing mod affect NI's ability to compile scripts? It doesn't on my system, anyway (or do I misunderstand what you are talking about?).

And i don't suppose no one thought to try the drag and drop in linux, because it is not working (i've done some java apps in the past and i know some Dataflavors mimetype can fuck up, varying by platform).

I don't have linux, so there's no way for me to test it.

Keep in mind, though, that all I am doing here is compiling NearInfinity from the source code. Any problems with how it is compiled should be addressed here. If there are bugs/problems with the actual programming of NI, they should be reported to the official NearInfinity forum at PPG.

[i30817]

The reason it wasn't reading the biff files is the case sensitivity. Being java, it uses the native filesystem capabilities to read the files - if NI is reading lowercase files while the game has a uppercase letter, it works on windows due to the windows case insensitivity and fails on linux due to it's sensitivity.

If you're trying to make a portable program, make sure that you data is not unportable.

(ToEE circle of 8 patch has the same problem).

[Wisp]

If you're trying to make a portable program, make sure that you data is not unportable.

(ToEE circle of 8 patch has the same problem).

The Bigg already submitted a patch for that a couple of years ago. For one reason or another it hasn't gone into the main development. I've attached a build that includes it (built from my fork).

Attached Files

•  ni.zip   746.02K   659 downloads

[i30817]

Thank you.

[Turambar]

The Bigg already submitted a patch for that a couple of years ago. For one reason or another it hasn't gone into the main development. I've attached a build that includes it (built from my fork).

Wonderful, thanks! It works perfectly on lowered installations; I had been looking for it for ages. Could you please add it to the first post of this topic?

[Sam.]

If you're trying to make a portable program, make sure that you data is not unportable.

(ToEE circle of 8 patch has the same problem).

The Bigg already submitted a patch for that a couple of years ago. For one reason or another it hasn't gone into the main development. I've attached a build that includes it (built from my fork).

Am I correct in my reasoning that you started with taimon's build from Dec 19, 2010 and then made your own changes/improvements, then you added the Bigg's patch to correct the case issue? I am trying to make sure that if I add your build to the 1st post here that there won't be any regression (only progression) from taimon's latest build (as this is the one I consider to be the "main", authoritative branch).

[Wisp]

Am I correct in my reasoning that you started with taimon's build from Dec 19, 2010 and then made your own changes/improvements, then you added the Bigg's patch to correct the case issue? I am trying to make sure that if I add your build to the 1st post here that there won't be any regression (only progression) from taimon's latest build (as this is the one I consider to be the "main", authoritative branch).

Yeah, the only thing that differs from Taimon's branch is the case patch.

[Sam.]

The 1st post has been updated with the latest version. Thanks Wisp.

[Vazeron1]

Quick and probably stupid question - what are the main differences between NearInfinity and Infinity Engine Editor? I'm aware that NI is newer; at least, that's the impression I have, but a more detailed list of differences would be appreciated.

[i30817]

To whoever maintains NI right now:

The implementation of JFilechooser was always a little bit shit, especially in linux.

The "especially" is because Java respects a part of the gnome desktop specifications that GNOME probably forgot long ago.

It's a setting that controls the time to edit the file name after a single click on a file without moving in the filechooser.

Needless to say, the value that is in that file (that is not used anymore, since the behavior is now, "don't do that insane thing"), is rather short.

1 second. That's why if you click on the wrong place in JFilechooser it is always trying to make you edit files.

This can be disabled before you start up swing.
UIManager.put("FileChooser.readOnly", Boolean.TRUE);

JFileChooser will never try to make you rename a important file again.

Edited by i30817, 04 November 2011 - 03:48 PM.

[i30817]

BTW, anyone has acm2wav for linux? (and does it work with NI)?

Since i think NI can't open some wav files in linux because of that (strangely, only some).

Edit: it's a delphi project

Not going to download a 600mb obsolete ide just to compile a 23 kilobytes program...
Edit2: damn, i just did.
Edit3: oh joy. A compiler with a compatibility mode for a older version of the language, trying to build a 32bit program in a 64 bit machine, that uses a language i don't know, and that is full of unnecessary pointer arithmetic.


Edit4:
Ok, 100 easy edits later it built full of warnings like:
"FILLERS1.PAS(74,22) Warning: Converting pointers to signed integers may result in wrong comparison results and range errors, use an unsigned type instead."
or
"FILLERS1.PAS(130,17) Hint: Conversion between ordinals and pointers is not portable"

Yeah whatever. It is 64 bit built so it's probably useless for 32 bits.

But then i find that NearInfinity is calling acm2wav with "acm2wav.exe" instead of "acm2wav" (the ONLY civilized way to call a commandline command from a supposedly portable language).

Anyway, attached exe, don't even know if it works
 acm2wav.zip   203.12K   572 downloads

Use services like http://www.virustotal.com/ to quiet your mind if you're afraid it has a virus.

Attached altered project source:
 acm2wav1.32_86x64_src.zip   338.66K   564 downloads

Edited by i30817, 04 November 2011 - 09:13 PM.

[i30817]

Is there any reason that NI absolutly has to search in both the NI folder and the game folder for the acm2wav exe file Wisp?

It would simplify the code.

And why not distribute the file itself with NI, so those checks for the existence of the file go away?

[Wisp]

Is there any reason that NI absolutly has to search in both the NI folder and the game folder for the acm2wav exe file Wisp?

It would simplify the code.

And why not distribute the file itself with NI, so those checks for the existence of the file go away?

Looks like a bit of a kludge.
I imagine the best thing to do would be to reimplement the acm->wav functionality in Java and eliminate it as a consideration entirely. Or at the very least port it from DLTCEP (C++).

Edited by Wisp, 05 November 2011 - 04:13 AM.

[i30817]

Yes, that would be best. To be honest, just compiling acm2wav was a horrendous experience with pascal version of Delphi IFDEF compatibility patches, removing things that were creating a pointer to immediately dereference it, PointerToUnsignedInteger "compatibility" hacks (officially recommended).

I'm not at all confident in it not introduced errors due to all the warnings and my inexperience with this language (first pascal file i opened).

Although it could be worse... it could have a gui component.
DLTCEP would be best. Although i'm not experienced in porting native apps, the code in acm2wav looked like a "reverse engineer" dump. Variables names like ebx and such.

Edited by i30817, 05 November 2011 - 06:13 AM.

[i30817]

Bad luck; it still doesn't work ok in all cases.

For instance try to open EFF files. It will say it didn't find them. Or open a save game. Some of those internal files it will find, some it will not.

I didn't debug it.

BTW, the file i compiled above will not work without code work in NI by itself (but it works from a linux cmd line).

This is because the environments are quite different, and the way they are being called (from the command line as exe, with '\', on a strange directory) is not working ok.

There is a way in java of calling the cmd line that is "portableish" for posix (the Process object, using only the filename without extension), but i couldn't get it to work on the first try).

Edited by i30817, 30 November 2011 - 05:58 AM.