23 réponses à ce sujet

[ToM_Hex]

Hi everyone, got a question/issue which I hope someone is able to answer.

We introduced some custom skills on our server a while back. It worked perfectly in itself and the players now get the skills and are able to use them IG.

But we received a strange bug in our server as well. All locked doors and chests started to act up. Usually when you click on a locked door or chest you move up to the door and try to interact with it in whatever way possible. Now the game started to tell the players "You can not use this skill." and they don't even try to move up to the door.

After some experimenting it become clear that the players avatars defaults to try and use the Open Lock skill, even if they don't have skill points in the skill. This behaviour seems to overrule everything else atm when it comes to all locked doors and chests. Even if they receive the keys to the object it still won't let them click the door to open it.

A workaround is to right click on the object and from there chose "Use". So the function itself still works, it's just that it's overruled.

I managed to locate the possible cause to the add-on of custom skills on the server. Around the time this behaviour appeared our skills.2da moved to above 41 rows. If I take the skills.2da and put it in a clean module without anything else added this appears in this one as well. If I remove the new lines to exactly or below 41 it works. But of course a lot of creature blueprints stop working.

I have been searching on the web for the last few weeks for a fix to this, or information if anyone else experienced this behaviour. But with no luck. So anyone that have heard of a similar trouble or possible someone that knows what could be the issue?

The skills themselves work perfectly as mentioned before, the game recognize them and our players can use them IG. Maybe there is reserved lines in the skills.2da?

I have run out of ideas sadly.

Modifié par ToM_Hex, 01 novembre 2010 - 05:33 .

[The Fred]

It's possible the 2da is somehow looping around until it overwrites the Open Lock skill, so to speak. Basically you get weird behaviour if you go above a certain number (if the index of the open lock skill plus some power of two, probably 32, that would make sense). Something like that happens with baseitems.2da, I think it is (and shields and stuff), or at least did in NWN1. Just a possibility, though.

[c i p h e r]

IIRC, there was a limit to the number of rows the game recognized in skills.2da. Have you searched around the old forums? It might give you a clue as to what your problem might be.

[ToM_Hex]

The limit was said to have been raised from 29 rows to 100 in one of the updates to nwn2, I guess some other more hardcoded limit could exist. I did read about the old problems from nwn1 about custom skills, among them there was a note that in three locations in the old nwn1 code there was some hardcoded limitations.



I haven't experienced any of the noted bugs from before the 100 limitation upgrade to skills.2da though. Mainly a complete crash of the server if fighting monsters with DR in areas or entering areas with monsters having the wrong skills (I think).

[BigfootNZ]

I dont think theres a problem with the limit, my own skill 2da has 47 entries and works fine from what i can see.

Have you altered all the class_Skill .2das to have references to your new skills?.. that could cause issues if not done correctly. Although I dont think thats your problem.

It could be old characters not gaining the new skills in their save files (bic?)... ie when leveling up and looking at the skills pages they see the skills since their in the 2da's but the characters only have the same number of skills pre-custom skill additions in their characters data... ie when you open a blueprint in the the toolset after making a custom skills.2da the toolset seems to save the new blueprints with all new skill entries if you remove any entries from the 2da reducing the number of rows and try to load those blueprints after a save, they bug out. Something like that could be happening with the servers characters save files possibly?

It might not be causing a crash but messing up how skills are operating ingame instead.

Modifié par BigfootNZ, 03 novembre 2010 - 05:10 .

[ToM_Hex]

BigFootNZ, did you create your skills.2da from the toolset or from a external program?



I have tested both new and old characters from the server live and from the toolset and they all experience the same issue.



I followed the steps as I have found which is:



Edit:

skills.2da

The servers custom.tlk file

nwscript

cls_skills_* to include the skills



Most of this I did from the toolsets own tools. Did find a mentioning yesterday this might not been the best of ways.

[BigfootNZ]

I used TlkEdit

I dont think it would make any difference however... granted my skills.2da isnt being used for a persistant world just my own project so it maybe an issue with persistant worlds?

If it was id assume thered be more people complaining about it, if it was wide spread since im sure most such game servers would have their own set of skill changes.

Also have you tried seeing if it works ok with a brand new character on the server completely fresh made from the start since given how the toolset can bork if it finds the total number of skills (and it seems that total number includes skill entries that are blank or unused as well) in a blueprint differing from the 2da it might have similar things with characters that have have been saved with X number of skills compared to the Y number found in the new skills 2da, with the Toolset it seems that any new skill entries you add to skills.2da get appended to the end of the blueprints when you load or make a new one (dont qoute me on that im simply basing that on observation ), but it might not do this for preexisting characters loaded within the game... ie the game recognises 50 skills but the old character save file contains only 20 entires for skills and it doesnt allow other new ones to be added to the file.

Modifié par BigfootNZ, 03 novembre 2010 - 10:29 .

[ToM_Hex]

Been trying several things this last week to try and find a way around this. But I keep coming back to that the moment I add a line above line 41 the game UI start behaving as if the open lock option is possible.



I even tested making a completely new module and made several gibberish lines of skills. They added perfectly to the game and I could subtract and add them without much trouble when creating or loading characters.



But whenever the game loads with more than 41 rows all locked doors and chests defaults to try and use open lock even if I have no skills in it. I think I will test to disable the skill on line 41 and 42. Make them only possible to use trained. See if what The Fred said might be valid for this as well.



Have you actually loaded a local module with locked doors on your machine BigfootNZ with your custom skills in it and tried to open a locked door?

[ToM_Hex]

Funny, it worked. I made the line require training and it works again. So it would mean the game UI actually starts over on the .2da file after line 29. And open lock just happened to be on the same line again as my new skills.



....



lol

[BigfootNZ]

ToM_Hex wrote...

Have you actually loaded a local module
with locked doors on your machine BigfootNZ with your custom skills in
it and tried to open a locked door?

Umm nope.

Ill boot my NWN2 PC up and try that right now to see if I get a similar problem...

Edit:-Hmm bugger me, It does happen for me also. Although if the character has skill points in Openlock it works as it should. Rather disapointing when i think about it, considering that it'll never get fixed

Its not such a big issue since a character that cant openlocks would be unable to use such doors any way although I could see in some situations it being something that could make a player scratch their heads. Interestingly this morning I sort of recollected a similar thread about this on teh old BIoware boards, no idea where it would be but I think it was talking about this issue.

Thinking about it I dont think its a problem with the Skills.2da itself, but how the engine is handling the interaction on objects requiring the use of the Openlock skill with a modified Skill list. Looks like Disarm traps also has a similar issue, a character who hasnt got any skill points in it gets a gold rather than greyed out icon over traps and can open the disarm sub menus but when clicking on the trap or any disarm menus it pops up the you dont have the skill message.

Edit2:- I wonder if removing Openlock as an Activated hotbarable skill would make a difference?, after all it shouldnt really be like that from a mechanic stand point really since you only use the skill from interaction.

Edit3:- None of that seems to make any difference it seems, by the way I hope I didnt lead you down the wrong path I dont know why I thought mine was working alright, although I tend to bug test with rogue characters so that could have been my issue. Its not a very annoying bug thankfully.

I wonder if having padding in the Skill.2da between custom and original skills does anything... it shouldnt but who knows it could be anything really.

Modifié par BigfootNZ, 07 novembre 2010 - 10:53 .

[The Fred]

It seems a long shot, but might it be that if you left whatever line the engine is getting confused with the Open Lock skill black it could work (assuming this is what it's doing). For example, there was a problem with baseitems.2da where after a certain number (255, I think) it would sort of loop around - mostly harmless, but when it got back to lines which were shields the first time around, it got confused and started treating whatever this item was a bit like a shield, or something like that, I forget. I'm just wondering whether this might be something similar and whether removing a specific line might fix it.

[ToM_Hex]

Well, considering that open lock is number... 10 on the list of skills in skills.2da and my bug appeared at line 42 (since we got line 0, count this in both instances). And thi with the removal of no disabled skills.

So that means the list ends at line 32 and from there starts over.

So custom skill
# 3 will "break" Disarm Trap
#12 will "break" Open Lock
#14 will "break" Perform
#16 will "break" Sleight of Hand
#17 will "break" Set trap
#18 will "break" Spellcraft.
#21 will "break" UMD
#23 will "break" Tumble

After that it will start over again after a while...

Modifié par ToM_Hex, 08 novembre 2010 - 05:24 .

[BigfootNZ]

Im not sure what this 'wrapping' you two are talking about is, its making me confused I understand The Freds example with baseitem 2da since if I understand it the 255 number is special and the game can only store that number of entries for some 2das so it resorts back to 0 for row numbers higher than that (the old NWN weapon models had a similar limit to their numbering resulting in a limit to how many you could have in total).



Another thing you could try is duplicate the Openlock skill and place it further down the list of skills so it sits beyond number 42 and see what happens? and leave the old Openlock disabled or blank.



Although you'd have to alter the class_skill 2das so that the row number for Openlock were correct or that could cause issues.

[BigfootNZ]

Well I might have fixed your problem Tom_Hex...

I went through and tested every skill entry all the way up to row 100 (101 if you count 0) and found that as long as you have the following rows filled with blank (ie all **** and 1 for 'removed'_ all doors, traps and placeables work as they do with a non-modifier skills.2da.

The Rows to leave as blank are as follows...

32, 34, 41, 62, 66, 73 and 96

Now I dont know if any other skills are effected, I tested slight of hand and healing and they all seemed to work as intended.

As far as I can see theres no real pattern to the rows that have to be blanked except for the first one 32 which ties in with Disable Device if you start to loop back after row 29, if row 32 and 34 are not left blank it breaks Disable Device the same way locked doors get broken with Openlock. Row 41 sort of corresponds with Openlock but most of the other rows in that list effected disable Device I think 66 breaks openlocks. Cant remeber didnt bother to write what each row brok sorry

Hope that helps you an lots of others useing custom Skill 2das... now I have to go back and redo my own Skills 2da and class_Skill 2das due to this

ToM_Hex wrote...
So custom skill
# 3 will "break" Disarm Trap
#12 will "break" Open Lock
#14 will "break" Perform
#16 will "break" Sleight of Hand
#17 will "break" Set trap
#18 will "break" Spellcraft.
#21 will "break" UMD
#23 will "break" Tumble

Is this list actual or just theory?.. ie do those skills get broken also.


Edit:- UMD and Set Traps works as intended, Although I just realise Slieght of Hand is showing up as useable as a context menu when right clicking on NPC's for characters who havent got it trained (unlike the unmodified Skills.2da), so ill have to go through and find which lines are causing that to happen... poop

Modifié par BigfootNZ, 09 novembre 2010 - 03:03 .

[BigfootNZ]

Hmm well I went back and found the first line that was causing issues with Slieght of Hand appearing in drop down menus for characters that didnt have that skill trained, but in doing so it changed some of the required blank rows... which is weird to say the least.

So I went back through and rechecked for disable, openlock and slieght of hand and the new list of rows to make blank are:-

73, 41 (Fixed Openlock)

77, 45 (Fixed Sleight of Hand)

32, 34, 66, 96, 97, 98 (Fixed Disable Device, odd how just adding the 2 sleight of hand blank rows removed 1 row and added 2 new for Disable)

I think I noticed a discrepancy in how Set Trap was working for those who didnt have the skill trained compared to normal and I think ill have to set up a test situation for Parry (not that anyone would miss that skill being bugged ) and Taunt. Might have to test Tumble and Spellcraft also.

Anyone else notice a pattern in those numbers though because ill be damned if i do, and if fixing a new issue rearranges them to a degree then this might take a while

I dont think Perform will be  affected since its only used in Spell Scripts for Spells and Feats and in those instances its just grabbing a value, which i think is working fine.

EDIT:- Ive tested, Set Traps, Parry, Tumble and Taunt and they all work as they should when comparing the normal and modified skill.2da. I believe that the only skills that where causeing issues where ones that automatically activated when interacting with other things, such as Disable, and Openlock (although Sleight of Hand throws that out the window but it was more the fact it is a 'requires training' skill that should only appear in the right click drop menu if you have skil points in it).

So apart from some other unforsen issues that could arise... id say that SHOULD fix your problem completely

Modifié par BigfootNZ, 09 novembre 2010 - 04:51 .

[dunniteowl]

Wow, guys. I honestly have to say I do my best to read all the new topics, even ones I have little to no interest in (like build discussions, I hate those) and this one just shows me how dedicated and determined some of you are to fix issues that crop up during customization.

I'd just like to say 'thanks' on behalf of the many, many others who will possibly never even know how much work you've put into doing this sort of stuff.

Thanks.

dunniteowl

[ToM_Hex]

Comparing your notes with mine BigfootZ I'd say that the lines in the skills.2da repeat at a set number of 32. Open lock for example broke at line 73 and 41 and is line 9 originally.

9+32=41, 41+32=73

Sleight of Hand repeats the same:

13+32=45, 45+32=77



Why we notice open lock, disable traps and sleight of Hand is because these work toward the object in the game and run trough the skills.2da to check if the options to display for the PC in the drop down menu depends on if the skills require training or not. Which they all do.

[ToM_Hex]

Thanks dunniteowl.

[BigfootNZ]

ToM_Hex wrote...

Comparing your notes with mine BigfootZ I'd say that the lines in the skills.2da repeat at a set number of 32. Open lock for example broke at line 73 and 41 and is line 9 originally.
9+32=41, 41+32=73
Sleight of Hand repeats the same:
13+32=45, 45+32=77

Why we notice open lock, disable traps and sleight of Hand is because these work toward the object in the game and run trough the skills.2da to check if the options to display for the PC in the drop down menu depends on if the skills require training or not. Which they all do.

Heh im a stinker at maths (well not really but im fuzzy headed at the moment). Although what about Disable Devices... its pattern is an odd one and doesnt follow 32 loop and I found that it changed when I stuck in the Sleight of Hand changes.

By Disable Devices breaking I mean in an unmodified 2da if you have no skill ranks in Disable Devices and you click on a spotted Trap its icon is grey and your click ignores the trap, when it breaks it acts just like the Openlock issue where you are told you havent got the skill and the trap captures your click stoping you from moving to teh location you clicked and the Disable Trap icon is gold and you can bring down the trap disable device menus with disable, examine, recover although none of them work with out any ranks. Works fine if you have got ranks though.

Not sure what it would do for doors that are locked AND trapped or just trapped if bugged since I didnt test a trapped door, but id assume it would do what the openlock bug was doing and just refuse to make you interact with the door also. Although with the numbers I supplied Disable Device is not an issue anymore thankfully.

Also just incase this is relevant, I also have lines 0 (animal empathy) 3 (discipline) and 28 (ride) blanked out and removed, the original 2da has them simpley flagged as removed, ive filled them with **** since I like to clean up such pointless rows that way (saves a few bytes). Not sure if me having those blanked out would change anything since I know that there are some 2das that still recognise rows if they are blank but have a Label column entry or are all blank save a tlk number, ie im not sure if a flagged as removed unblank row is handled differntly  from a fully **** row also flagged as removed.

NWN1/2 has some odd discrepancies between how various 2das work compared to others... its quite annoying sometimes

At least we got this sorted...

dunniteowl wrote...

I'd just like to say 'thanks' on
behalf of the many, many others who will possibly never even know how
much work you've put into doing this sort of stuff.
Thanks.
dunniteowl

Yeah I took it at face value that after they patched in the ability for us to go over the Skill limits way back when that it would work just fine and as they said it would and I thought it was all fine and dandy, I mean I could add new skills and they all worked (to a degree) as far as I could tell which was great.

Was rather miffed when I realised what Tom_Hex was on about was real, you think your making some progress after adding a heap of skills and setting up oodles of 2das to work with them, then you find out that theres a glaring issue you never noticed.

Maybe these rows numbers should be stuck up on the NWN2wiki with an explanation for people making their own Skill.2da changes. I wonder what happens if you flag as removed any of the OC skills (sicne some people might want to remove skills like UMD or the crafting ones etc for their own skill.2da), does it break the Rows we worked out... think ill try that today.

Modifié par BigfootNZ, 09 novembre 2010 - 10:50 .

[0100010]

I would suggest that you do in fact go to the wiki and place this issue on the reserved 2da page. If those rows are "bad" then that is the one of the additional good places in which we can let people know about it.

Modifié par 0100010, 10 novembre 2010 - 04:20 .

[The Fred]

Wow, nice work, guys.

[0100010]

Skill.2da has been added to the NWN2 Wiki

http://nwn2.wikia.co...da_Reservations

Modifié par 0100010, 14 novembre 2010 - 03:00 .

[ToM_Hex]

Nice!



A summary on this bug would seem that there could be a limitation in the UI code that reads the skills.2da to 1 byte. (32 bits, I believe this is what a byte is in nwnscript). If the skills.2da takes more space it will start looping in this memory, giving odd results to all skills that interact with the UI.



The workaround is to make sure that the rows that cross with a UI skills have identical values as the base skill. I.E: A active skill in the first 32 rows means that whatever skill you put 32 rows after that one need to be active as well.



BigfootZ mentioned that disable device is acting up on his tests outside this pattern and I haven't had the opportunity to double check that. If anyone is able to reproduce this it would be great to know since there might be more things working behind this than what we have found so far.

[BigfootNZ]

ToM_Hex wrote...

BigfootZ mentioned that disable device is acting up on his tests outside this pattern and I haven't had the opportunity to double check that. If anyone is able to reproduce this it would be great to know since there might be more things working behind this than what we have found so far.

In a way it doesnt fully break disable traps, it just causes a difference in the way its handled compared to a regular OC 2da with no skills added. With the original OC 2da if a person without disable traps skill ranks tries to click on a revealedttrap trigger the icon is grey and the click passes through the trigger to the terrain underneath and the player moves to the location of the click as if it was just a click to move situation.

With the altered 2da if they click on a discovered trap trigger the icon is gold and they can open up the disable traps options, they cant use any of them and if they click on the trap  or select recover or disable it says 'You dont have the required skills for that' the same as the Open Lock issue... in a way its actually kinda good since it means a player with no disable trap skills clicks on a revealed trap by accident their character doesnt go off running to the trap and triggering it as it does with the OC 2da.

Unfortunately if disable devices is left unaltered it would throw off the number orders of the broken 2da lines we've fixed I think, and we'd have to go back through and test them all again

So its best I guess to get the custom 2das working as much like the OC version with all skills as possible, which our list of 'to be left blank' lines do as far as we can tell in testing.

The odd thing is the disable device skill get effected by a large number of lines and it doesnt seem to follow Hex's 32 line loop theory at all. Not saying you wrong Hex since you are right about open lock and slieght of hand using it, it just doesnt seem to be the case for all problem skills.