So far for 1.05
While the 1.04 patch is about to come out for NWN2, the 1.05 patch isn't too far off either. Rather than make 1.05 a big patch like 1.04 is, we want to release a small, quick patch to try and quickly resolve some issues the custom content community for NWN2 is running into.
I recently revamped the auto-updater to allow for incremental patches. This means that if someone had 1.02, the patcher would patch them up to 1.03, then to 1.04 (once 1.04 is released). While this may seem like it doesn't offer anything to the end-user, it makes it several times faster to make patches on our end, which means the end-user will see more frequent, smaller patches, instead of the periodic large patch.
The following is a list of the items that have gone in so far for 1.05:
armorrulestats.2da will no longer be capped at 255 rows
DisplayGuiScreen() script function now has a new parameter that allows the script to define the *.xml file if the 'screen name' can't be found in the gui INI files.
Appearances.2da had the NWN2_Scale column changed to NWN2_Scale_X, NWN2_Scale_Y, NWN2_Scale_Z, allowing all 3 dimensions to be scaled seperately.
The chat boxes will no longer clear their text on area or module transitions.
NWN2_Deities.2da can now be overridden correctly, without having to stick it into the override directory.
NWN2_Deities.2da's description column can now work with hard coded strings in place of STRREFs. Simply enclose the string in " marks.
GetIsPartyTransition() script function will now correctly return TRUE or FALSE. Before it would always return TRUE, which would cause the default transition scripts to jump the party even if the trigger was flagged as not being a party transition.
A bug has been fixed that was preventing mouse clicks from going through the screen space occupied by the quickspell menus even if the quickspell menu wasn't visibly blocking that part of the screen.
There's a number of 2DAs that should be fixed in the toolset with regards to respecting the Label Column if the STRREF column is blank. I'm out of the office this week, so I'm not 100% sure that this had made it in at this time, but it is my goal for the 1.05 patch for it to be there.
Also going in is Multiselect for the DM Client and in the normal game mode. This will allow you to drag-select any party members not being actively controlled by another player and issue simple commands like move, attack, talk, and even unlock/disarm. The game will pick the character with the highest score for picking and disarming and have them do the action. This is our first pass at multi-select support, there will be more features going in with regards to this over time.
Anyway, that's all I can think of off hand and after looking over my notes from last week. I expect 1.05 to be released early Feb.
6 comments:
Hey Rich.
I love the blog, lots of great info. I was wondering if the changes to DisplayGUIScreen() were also going to filter through to the other GUI script functions?
I've been working on GUI stuff lately and having the .xml file looked up instead of the constant in the ingamegui.ini would be really helpful as well for the GUI functions like DisplayMessageBox() (I'd like to design my own message box styles), CloseGUIScreen() (if we can open it by xml file name we should be able to close it) and so on.
Basically, once we can call up a GUI screen by xml file name we pretty much need the other GUI script functions to be able to refernce the xml file name as well.
Thanks.
While it won't be a problem to add that ability to GUI functions that load files (DisplayGUIScreen, DisplayMessageBox, etc), script functions that perform operations on existing GUIs should stick to using the Screen Tag you specified when you opened them.
For example, if I use
DisplayGUIScreen( "My_Custom_Screen", "mycustomscreen.xml" );
I can then use
CloseGUIScreen( "My_Custom_Screen" );
and it will work fine.
Since you define the Screen Tag for your custom GUI, you should be able to perform the rest of the operations on it via the Screen Tag.
If that doesn't seem like it would work out, let me know and I can explore other options, but it seems like it would be fine to me.
Oh!, cool.
No, that looks great. I didn't realize that by calling DisplayGUIScreen() using an .xml filename that I could also assign a screen name tag. I thought it was an either/or case where if I specified an .xml filename then there would be no screen name tag available for that GUI object.
These are great additions, thanks again.
Hey again, Rich.
I've had a chance to play with 1.05 beta a bit and there's a problem with the toolset reading the label column in placeables.2da, at least:
It does read the label column but it doesn't display what it has read in the dropdown list of available appearances. That is, the label column text shows for a placeable under its appearance tab if that appearance was already chosen for the placeable. But if you open the dropdown appearance list it's not shown on the list and therefore can't actually be chosen.
At first I thought the label column wasn't being read at all, but when I switched a placeables.2da over to remove the temporary sttref's I was using I realized that it is being read but is just not appearing on the appearance listing.
Not sure if there's supposed to be full functionality for this feature yet, but I figured I would let you know.
Thanks.
Thanks for mentioning that. We actually found out about that internally regarding the 1.05 beta. I've confirmed with QA today that we have fixed that issue for the final version of the 1.05 patch, which should be coming out soon. :)
Excellent. Looking forward to 1.05 final -- your efforts are greatly appreciated.
Thanks again.
Post a Comment