33 réponses à ce sujet

[kevL]

goodLuck, ( see my last 2 posts for personal sentiments )

[Lance Botelle]

Hi All,

RESOLVED - See first post.

Lance.

[kevL]

Houston, we're comin in!!

Modifié par kevL, 11 mai 2012 - 06:47 .

[Lance Botelle]

kevL wrote...

Houston, we're comin in!!

Hi KevL,

EDIT/UPDATE: Actually, I believe I have found a way to get around this problem *if* you set up the database with empty placeholders for the variables that will be updated in a module. It seems that updating a variable that is already in the database does not harm the transitions (as far as I can see). It's early testing yet, but this would be the simplest way around the crashing issue, as it would mean either:-

a) Supplying the player with a database already to update, or ....
Have the database setup on initial play and have the player reload the game from afresh only once. (This is my preference.)

I will test this further, and no news, means good news and that will also be a good workaround.

Lance.

[painofdungeoneternal]

Or set up the DB initially, then if the player crashes he can just try again and it won't crash again. Less than perfect but it does mean at least its not frustrating. Think there is a loadmodule command in nwscript as well.

[Lance Botelle]

painofdungeoneternal wrote...

Or set up the DB initially, then if the player crashes he can just try again and it won't crash again. Less than perfect but it does mean at least its not frustrating. Think there is a loadmodule command in nwscript as well.

Hi Pain,

I can confirm that setting the database up first does sort out the problem. So, as long as the database is already in place and module scripts are only updating exisiting entries, then there are no crashes!

I will give that loadmodule function a go. If it reintializes all dat (including the database function), then this will be the perfect solution, as the player will not see what is going on! Once setup, data can be written to and from the database without causing future transition crashes.

Cheers!
Lance.

[kevL]

Lance, get a load of what 34 had to say in the Broken Functions List:

Get/SetCampaign**
Does not perform string length checking of the variable name for saving and retrieval
Workaround: Use Better Names or Globals instead

also, i noticed when reviewing the Universal Companions add-on that Alan truncated his strings at 17 (16?) characters. What are your string-lengths like ...?

[Lance Botelle]

kevL wrote...

Lance, get a load of what 34 had to say in the Broken Functions List:

Get/SetCampaign**
Does not perform string length checking of the variable name for saving and retrieval
Workaround: Use Better Names or Globals instead

also, i noticed when reviewing the Universal Companions add-on that Alan truncated his strings at 17 (16?) characters. What are your string-lengths like ...?

Hi KevL,

Yes, I recall this problem from the early days of NWN1. I recall being involved in a discussion on the boards when this was first discovered. Definitely worth recalling though! In this respect, I do check that all my camapign variables are being set and returned correctly. So far, that side of the function has not caused me any problems.

The "transition crash" after setting a new campaign variable was definitely an issue though. However, as you can read above, I found the ideal solution that removes all instances of crashing and is easy to implement, is to make sure that the database is initialized prior to the game being played! i.e. Have a routine set up the database for the player on their first entry and have them restart the game on the first start up. This then sets up the database and the restart prevents any further access to or from the database from causing the crash.

EDIT: I am in the process of renaming some of the database variable names to make them more generic and easy to use in the rest of the programming. This allows for flexibility as well.

Cheers!
Lance.

Modifié par Lance Botelle, 14 mai 2012 - 12:34 .

[kevL]

Sounds decent.