1168 replies to this topic

[Argent77]

It would be really convenient if the "Store purchases" list in STO files could be displayed as a panel of checkboxes instead of individual items.  I know as far as the file structures are concerned, NI typically only uses the checkboxes for bit fields, but the ease-of-use would be greatly improved IMO if something similar could be implemented for the "Store purchases" dword array as well.

The "Store purchases" items are defined as a dword array of arbitrary size (in contrast to bit fields which are always constant in size). You can freely add or remove items to/from this section and the list of item categories can be unsorted (as it's done in a couple of STO resources added by BG(2)EE).

Furthermore, the size of this section is practically only limited by the number of supported item categories (which is around 74) and can theoretically support up to 4 billion entries. That's why I don't think it is possible to encapsulate the whole section into a single data type without losing some control over it.

 

The best I can do is adding a summary of the "Store purchases" list to the View tab.

 

[The Imp]

...

The best I can do is adding a summary of the "Store purchases" list to the View tab.

Erhm, the though behind Sam's request that there has to be easier interface to add items into the store(.STO file) than the current one... so anything that can facilitate it would be good.

One idea is to build internal function that uses lists of items and using those the NI can add the files into the store( somehow).

Edited by The Imp, 19 April 2014 - 04:12 AM.

[Argent77]

Erhm, the though behind Sam's request that there has to be easier interface to add items into the store(.STO file) than the current one... so anything that can facilitate it would be good.

I know that Sam.'s idea was to simplify modifications to the "Store purchased" section. The last remark was just an independent thought what might be possible (and feasible).

 

One idea is to build internal function that uses lists of items and using those the NI can add the files into the store( somehow).

An important principle of NI is that you can modify game resources directly without the tool making any changes on its own. I would have to come up with a new way of modifying data structures to accomplish both, a more convenient method to modify data and ensuring that the original data structures will be preserved at the same time. It's not impossible, but this kind of feature would take lots of time (and a good idea how to realize it).

 

[Argent77]

Update: NearInfinity v1.35.0-snapshot-20140425

 

Changes:

• BAM Converter: Lots of bugfixes, minor usability improvements and better palette support

[Solaufein]

Does this version still corrupt the world map in the EE games? The other versions do.

[Argent77]

Does this version still corrupt the world map in the EE games? The other versions do.

Can you explain in detail what is corrupting the worldmap in EE and how to trigger it?

[Wisp]

Does this version still corrupt the world map in the EE games? The other versions do.

Can you explain in detail what is corrupting the worldmap in EE and how to trigger it?

NI corrupts certain file structures, WMP included, regardless of EE or not. In the case of a WMP, when you add an area, NI does not adjust the link structure (IIRC), and the result is an invalid file.

Aside: if you are editing a WMP with NI, you are likely doing it wrong, because the result will not be redistributable. WeiDU can add areas and links to a WMP in a redistributable manner, and it's not even difficult.

Edited by Wisp, 26 April 2014 - 10:33 AM.

[Argent77]

The WMP format is structured in a way that makes it very difficult to fix one issue without raising a number of new issues. Since adding or removing area link entries corrupts WMP files in any case, I would prefer to remove the add/remove functionality for this structure completely.
 

[Solaufein]

I was editing the links of a new area, saved it and got the null comment and was unable to read the world map.

[Wisp]

Since adding or removing area link entries corrupts WMP files in any case, I would prefer to remove the add/remove functionality for this structure completely.

I have no objections.


Solaufein, you may want to have a look at WeiDU's sc#addWmpAre function. It can add new areas, with links to and from existing areas. There's a usage example in the WeiDU readme. If you just want to add/remove links between existing areas, there's ADD_WORLDMAP_LINKS and DELETE_WORLDMAP_LINKS.

Edited by Wisp, 27 April 2014 - 12:12 AM.

[Solaufein]

That's what I'm using and I can't travel to or from the new areas in the world map without the game crashing. Which is why I was using NI to edit links to see if that would fix the problem. The areas are fine, I can console to the areas without a problem.

[Wisp]

We can try to debug the problem you are having with sc#addWmpAre, if you'd like. The code you are using and the worldmaps from before and after you've installed your mod would be helpful. (Essentially, in cases like these, you can just file a bug report and it's on me to figure it out, with your help, of course.)

Edited by Wisp, 27 April 2014 - 12:00 PM.

[Solaufein]

I believe the problem was on my part by only having one area mentioned in the "set up link variables" part. Now I am setting it up so there are mutliple areas mentioned in the directional links and go from there, for beta 2 of this mod. If it still crashes after this, I'll give you a hail.

[Argent77]

Update: NearInfinity v1.35.0-snapshot-20140507

Changes:

• Strings in View tabs additionally show their corresponding Strrefs (feature can be enabled/disabled via menu Options->Show Strrefs in View tabs)
• Fixed a bug in WAV resource viewer that prevented the "Find references..." button to be displayed
• Updated WMP resource editor to prevent corrupting files
• Some minor GUI changes
• BAM Converter:
  • "Import BAM" allows you to add new BAMs in additon to replacing old content
  • Improved BAM cycles selection
  • Improved cycle adjustments when modifying frames
  • Added a "Drop unused frames" option
  • A number of bugfixes and some GUI-related optimizations
  • (The BAM converter should now be mature enough for creating all kinds of BAM files.)

 
Important announcement:
I doubt that many of you know about this, but NearInfinity also supports the games Neverwinter Nights and Star Wars: Knights of the Old Republic 1 & 2. Support is on minimal level and the code for those games has been unmaintained for many years. Furthermore, it looks like NearInfinity isn't even on the radar as a modding tool in the respective communities.
That's why we (Wisp and I) had decided some time ago to drop support for those games. As I'm currently the only one left working on NearInfinity and adding new features is getting increasingly difficult to implement without breaking something else, I will start removing the relevant code portions. Dropping support will reduce NearInfinity's file size and increase stability as well as maintainability.

[The Imp]

Important announcement:
I doubt that many of you know about this, but NearInfinity also supports the games Neverwinter Nights and Star Wars: Knights of the Old Republic 1 & 2. Support is on minimal level and the code for those games has been unmaintained for many years.

Any idea what was the oldest last update version ? Just so we have a backup of a one we(Sam) can link to one, not that it matters much. Say like the already linked v1.33b19, or v1.32.1b24 ... hihihihihiihhhiihhiihihih.

Edited by The Imp, 07 May 2014 - 04:53 AM.

[Argent77]

The latest recorded history of any NWN/Kotor updates I could find is dating back to January 2004 (so your v1.32.1b24 is a good guess). Assuming that no one has updated the relevant code portions since, I guess it's quite safe to drop game support without anyone having serious objections.

[-Hurricane-]

Thank you so much, Argent77, for adding the StrRef option! Makes me happy. 

 

As for dropping the support for NWN and KotOR, I have no objections. There comes a point where it is better to remove obsolete features if they start hindering the development of more important functionality. I believe you and Wisp made the right decision.

[CamDawg]

• Added symbolic spell names (from SPELL.IDS) to SPL's View tab
• Added symbolic spell name support to "Find...->references to this file" for DLG and BCS targets

Excellent!

Thanks for the updates Argent77, they're very much appreciated.

[Argent77]

I just noticed that while NI decompiles (at least some) BCSs, it uses abbreviations for Global and SetGlobal, like this:

IF
	RealGlobalTimerExpired("CliffShockTimer","GLOBAL")
	CombatCounter(0)
	HasItem("cliffbz",Player1) // Bizzen
	G("CliffShocked",1)
THEN
	RESPONSE #100
		SG("CliffShocked",2)
END

Is this normal? Will it work ok in game if I'll put some changes into BCS having such abbreviations via NI interface and then tell NI to save changes?

SG() is a valid script action that is (rarely) used in place of SetGlobal(). Since both actions refer to different internal IDs, it's most likely a deliberate decision made by the creator of the script. The same is true for G() in place of Global().