Doesn't 13*128 protect against freezing death, in 7eyes?
Direct script triggers for specific bits of stats, yeah, there is no way to do this at the moment. You might want to do an applyspell (which is not a blocking action). This spell has 324/318/326 (something with splprot). This spell then can set a variable which you can access from scripting.
Doesn't 13*128 protect against freezing death, in 7eyes?
Your right, wrong issue. It was Gore-OFF and "Disable Permanent Death" that interfered. Using spellstates 272/273 could bypass some of the issues (as they were only ever active while the creature was a statue), but still not all of them. So it was never ideal.
Wait so this change doesn't only affect opcode 335? This affects scripts too?
So basically you guys decided to completely invalidate everything established here?
So that means two of my mods will be rendered non-functional by the 2.5 update, and it will be utterly impossible to fix them. Wonderful.
Did you guys think of maybe adding some kind of function or facility to do this kind of thing, to replace the functionality you are removing? There have been feature requests logged in redmine relating to this stuff for two years now.
Or if the Android platform is so flaky that is can't handle reading information that other platforms have no problem with, what about just applying this restriction to the Android version of the game?
God damn it.
What was established there was never official. I wrote in several notes earlier, that it isn't safe. Reading into random fields by index overflow is never a 'functionality', it is a bug. It was working only because in release mode assertions are disabled and i (of course) tested this only in debug mode. This is the same as using negative scripting states in vanilla IE (which was also removed a few years ago). Anytime we add a new field into the creature, you would have to recalculate those offsets, so it was never compatible with anything either. "Utterly impossible" is a big statement, though.
2) My specific concern is a mod already in existence, which uses dialogue to arbitrarily extend the flexibility of how and when characters can gain proficiencies. This has been in the wild for several months:
CheckStat doesn't cut it here, because any mod that uses proficiencies in any other way will totally ruin this one. And, proficiencies being some of those scarce resources I mentioned, people should be using them in other ways. If there was a CheckStatBit trigger the associated spellstates wouldn't be necessary.
They did add 3 new script triggers to check effective Proficiency level, which you should be able to substitute here. It appears to correctly detect only the active proficiency value (first 3 bits), ignoring the inactive/original class bits(dualclass) and the upper bytes.
But i guess, yours is more like a core engine change, if anything. I don't know of any change that might affect you, unless it is the spell state fix. Gimme a hint about what opcode/action you suspect to be different.
Comments
Direct script triggers for specific bits of stats, yeah, there is no way to do this at the moment.
You might want to do an applyspell (which is not a blocking action). This spell has 324/318/326 (something with splprot). This spell then can set a variable which you can access from scripting.
It was Gore-OFF and "Disable Permanent Death" that interfered. Using spellstates 272/273 could bypass some of the issues (as they were only ever active while the creature was a statue), but still not all of them. So it was never ideal.
and there: http://blog.beamdog.com/2018/05/baldurs-gate-ii-enhanced-edition-25.html
But i guess, yours is more like a core engine change, if anything.
I don't know of any change that might affect you, unless it is the spell state fix.
Gimme a hint about what opcode/action you suspect to be different.