There seems to be a bug in the way the game handles class IDs. I created a new class which for reasons that I'll explain in a moment I gave ID=10000.
In the EVENT_TYPE_CHARGEN_SELECT_class event in sys_chargen the classID is coming through as 26 (nclass = GetEventInteger(ev,0)). I am wondering if this has been hard coded somewhere so the IDs are always sequential (the last Bioware ID is 25).
The reason I wanted to use ID 10000 is so that the formula in Chargen_GetEquipIndex still gives a unique lookup number (this needs to match the number in the chargen_defaults 2DA table):
return nRace * 1000 + nclass * 100+ nBackground;
integers less than 10 work, as do multiples of 10000 (for example - I chose that because it gives plenty of space) but numbers like 26 don't work (note that Bioware playable classes are 1, 2 and 3 so they never encountered this issue).
A temporary work around is to use class ID 26 and just modify the formula to work with it. I would rather not use a number so close to Bioware's classes though since that will mean more difficulty integrating with any additions that Bioware make. I could also put a few dummy non-playable classes in to give it some buffer I suppose but that solution is hardly ideal.
Would someone from Bioware care to comment?
Bug in class IDs
Débuté par
stuntpope
, déc. 14 2009 11:54
#1
Posté 14 décembre 2009 - 11:54
#2
Posté 14 décembre 2009 - 08:28
It would seem like the code that deals with this 2da reads it sequential for a reason, which is bad as it would cause all kinds of issues with future content. I'll file a bug.
#3
Posté 15 décembre 2009 - 12:44
Thanks for that Georg.
I don't suppose you could comment on the way the formula is structured too? As far as I know that formula is not used outside of Chargen_GetEquipIndex, in which case it's no big deal to change it if we need to (or otherwise use some method of assigning class IDs that still guarantees a unique lookup ID). But could you confirm that this formula is not used anywhere else (ie especially in the code that we can't change).
The thing that seems odd to me about that formula is that it allows up to 99 backgrounds (which generally need to be overwritten on a module by module basis anyway so 6 would probably suffice) but only 9 core classes (the IDs of which are all already taken by Bioware for core and non-core classes).
I don't suppose you could comment on the way the formula is structured too? As far as I know that formula is not used outside of Chargen_GetEquipIndex, in which case it's no big deal to change it if we need to (or otherwise use some method of assigning class IDs that still guarantees a unique lookup ID). But could you confirm that this formula is not used anywhere else (ie especially in the code that we can't change).
The thing that seems odd to me about that formula is that it allows up to 99 backgrounds (which generally need to be overwritten on a module by module basis anyway so 6 would probably suffice) but only 9 core classes (the IDs of which are all already taken by Bioware for core and non-core classes).
#4
Posté 23 décembre 2009 - 05:20
A small bump to clarify the formula question.
Is there any chance that the formula will get changed so that the backgrounds and classes are switched? I suspect we will see a lot more classes/specializations than backgrounds.
Is there any chance that the formula will get changed so that the backgrounds and classes are switched? I suspect we will see a lot more classes/specializations than backgrounds.
#5
Posté 13 mai 2010 - 06:29
Bump! Can we get an answer to the two issues posted in this thread?
#6
Posté 14 mai 2010 - 11:15
Specializations don't use it anyway, but some kind of change is needed.
#7
Posté 14 mai 2010 - 11:19
sign me up as interested on whats happening on this.





Retour en haut






