821 replies to this topic

[Salk]

I thought of something now. I know you have a option to have pickpocket not go out of stealth immediately. There is a similar problem with opening containers (which makes a thief stealing things much harder than it should imo, especially considering that sanctuary apparently bypasses that).

This is actually a very good suggestion which I second fully.

[Sasha Al'Therin]

BTW, is STATE_DISEASE fixed?

I don't fix it. I need someone else to tell me why its broken though.

I think he means STATE_POISONED which does not work at all in a simple script like (Note: tested on BG:ToTSC needs confirmed for BG2)

I haven't tested it yet, but i'm pretty sure i meant STATE_DISEASE in bg 2
This post by Kevin Dorner explains it.

never saw that before (yet I don't dig thru posts from eons ago), but i do recall similar about STATE_POISONED.... I didn't think there was disease in any of the BG series. Thought that was an IWD thing to be honest.

[i30817]

It may very well be

They don't specify. Easy to check though.

[GeN1e]

The problem with this is that you lose information because of when you are affected by more than one stat - you only know the last one, because the stats are overwritten.

Not overwritten, but overlapped, so that only the highest value is read.

I can implement. However, I don't think anyone is going to update Detectable Stats since so many mods already depend on it.

There're Ascension, Rogue Rebalancing, SCS/SCS2, Questpack, Oversight, Kelsey, Kiara-Zaiya.

But I think it's not about updating DS in all mods, but a matter of compatibility between ToBEx and non-ToBEx versions of DS. E.g. DavidW prefers to stick to vanilla stats - else SCS would be unusable without ToBEx installed, - but if somebody wants to take advantage of it, then they can check masks for better precision.

[i30817]

But I think it's not about updating DS in all mods, but a matter of compatibility between ToBEx and non-ToBEx versions of DS. E.g. DavidW prefers to stick to vanilla stats - else SCS would be unusable without ToBEx installed, - but if somebody wants to take advantage of it, then they can check masks for better precision.

Incredibly stupid diatribe about something GeN1e already thought of:

Spoiler

Thinking of updating the original DS stat.ids values to support masking?
I don't think that that would work.


Unfortunately, CheckStat itself would start not work when you installed a tobex mod that changed the original stats with the Mask option in the effect.

Because then there could be multiple values and

!CheckStat(Myself, WIZARD_SHIELD_MASK, SCRIPTINGSTATE5)

would be meaningless and only

!CheckStatMask(Myself, WIZARD_SHIELD_MASK, SCRIPTINGSTATE5) would work.

However, this can be avoided if tobex doesn't allow Masking in the original stats. I suppose CheckStatXX would work the same too.

!CheckStatGT(Myself, WIZARD_SHIELD_MASK-1, SCRIPTINGSTATE5) is just as good as
!CheckStatMask(Myself, 1, SCRIPTINGSTATE5)


State 0 shouldn't be used too, so in effect it's only 31 values if 32 bits of storage (shouldn't be used because we need a empty marker) binary maths fail.


However, what's the point? Using the same ids values as DS for a DS2 that uses TobEx expandable Stats or something?

Edit 2: I just realized that this, is in fact the point. I should try to read with more attention.


Edit: I changed my opinion 9 times while writing this post. Sorry for the edits.

Edited by i30817, 01 December 2011 - 09:11 AM.

[i30817]

Wait. Gen1e, are you suggesting to change the DS expanded stats range in the CheckStat function itself to "transparently" support masking checks if TobEx is installed and changing their ids values be "masking compatible"?

That could work, as long as the DS using mods were updated to start to use ids files instead of hardcoded numbers (if they do)

( except for CheckStatGT(Myself, 0, whatever) variants that can still stay).

That's a audacious idea...

However, i think DS_2 that only uses tobex would be preferable?
I don't think anyone will ever use SCSII without TobEx again, all things considered? And the mods would need to be edited anyway to remove the use of hardcoded numbers.

Edited by i30817, 01 December 2011 - 08:42 AM.

[Galactygon]

How about CheckStatBit() instead of CheckStatMask? The stats can be broken up into 8 bits, you just need the opcode and a new trigger to handle bits.

I personally think it's irrelevant since we can now use unlimited number of stats, and either way you end up having to force ToBEx onto people.

-Galactygon

[GeN1e]

Well, okay, this

I should try to read with more attention.

clearly applies to me as well.

What I was thinking about was to have a way of telling SI:Ev from SI:Nec without touching scripts and spells.
Apparently, it wouldn't work, because SI:Div, Ill, Inv and Nec consist of a mix.

I don't think anyone will ever use SCSII without TobEx again, all things considered?

Not anytime soon, I believe. Not everybody likes ToBEx.

I personally think it's irrelevant since we can now use unlimited number of stats, and either way you end up having to force ToBEx onto people.

Agreed

Edited by GeN1e, 01 December 2011 - 08:50 AM.

[i30817]

If i'm reading you right, you'd still want to use the original stats. See my second post. Though Galactygon objection applies; you'd need TobEx to actually set/check a mix. And you'd need to change the mods using hardcoded stats to ids.

I find it a bit horrible to suggest behavior modification like that (hacking CheckStat to behave differently on a range).
I should do penance at the lambda monastery.

Edited by i30817, 01 December 2011 - 08:54 AM.

[i30817]

How about CheckStatBit() instead of CheckStatMask? The stats can be broken up into 8 bits, you just need the opcode and a new trigger to handle bits.

I don't see much difference?

CheckStatBit(WIZARD_SHIELD)
CheckStatBit(WIZARD_ARMOR)
instead of
CheckStatMask(WIZARD_ARMOR|WIZARD_SHIELD)

?
With the penalty you couldn't then use
CheckStatGT(WIZARD_SHIELD-1) or with the same ids too, which in my mind, it's the "feature" of overloading stats like this (to make the scripts fail fast (!CheckStatGT(0) would still work though)

Only 8 bits?

Edited by i30817, 01 December 2011 - 09:28 AM.

[i30817]

I've noticed that there are more data than just int's that can be saved.

SaveLocation(S:Area*,S:Global*,P:Point*)
SaveObjectLocation(S:Area*,S:Global*,O:Object*)


Pity they don't seem very useful without a Object.

Could we have:
RunAwayFromLocation(S:Area*,S:Global*,I:Time*)
RangeLocation(S:Area*,S:Global*,I:Range*)
Location(S:Area*,S:Global*,P:Point*) //to check invalid/marker values
?

Full disclosure, i think it might be useful to deal with area effects spells without a creature eating cycles. Add this to them: save the point on the globals with a known name, start a timer, add something to zone of sweet air that resets the timers and points.
This may be a dumb idea.

Edit: on that point, now that i've skimmed the Effects list, i don't suppose a effect to run a arbitrary script is possible?

Spell Effect: Execute Script cut250a [298]

seems like it was abused for far too long.

Edit 2: oh wait, you've already did it .

Edited by i30817, 01 December 2011 - 03:17 PM.

[phordicus]

force ToBEx onto people.

How is this a bad thing? If people don't want a mod that requires ToBEx, then they don't have to get the mod. If they like a mod that's incompatible with ToBEx, they don't have to get ToBEx. In both cases it would still be possible to alter ("update" is almost derogatory to the antedeluvians) a mod to be compatible. All I see is Progress walking hand in hand with Choice. To say they can't be a couple confuses me.

[i30817]

Eventually i expect we'll have to update the requirements again, to require either TobEx or GemRB. I don't think WeiDU has that option yet.

[DavidWallace]

Just to clarify (since it's come up): I don't want to incorporate ToBEx Expanded Stats into SCS DS because:

(i) I don't need it. I'm not feeling meaningfully constrained by having to work within the existing set of states.
(ii) I generally don't like to change working bits of code unless there's a clear, concrete reason to do so. Given that rigorously playtesting SCS before each release is impractical, and that releases can be months apart, the risk of introducing subtle bugs isn't worth it.
(iii) I try to avoid using ToBEx to do something that can be done another way, and I try to make sure any incorporations of ToBEx don't meaningfully reduce functionality for people who disable it. The reasons for this are practical, not principled: Ascension64 is perfectly up-front that ToBEx is and will remain beta, and that means (a) I don't want to rely on it more than I need to, and (b) I want the mod to remain functional if for a certain period players have to disable ToBEx to avoid some bug.

I have no monopoly on DS (most of the code isn't even mine). Anyone who wants to produce an expanded, ToBEx-utilising version is welcome to. But I'm going to make a plea for people to preserve backwards compatibility. Add as many new stats as you like, but don't change the allocation of the existing stats to spells, or their IDS references.

[i30817]

Spoiler

Actually, that thing about the mask for stats, it would also be useful for Globals.

SetGlobalMask
GlobalMask

Why? Preventing buffs being scheduled to be casted when a equivalent or more powerful spell is already in queue. It would reset at the top of the script.

Notice that DS only works AFTER the spell is cast.
The alternative appears to be a explosion of LOCALS (haste, str, shields, etc)

Are globals 32 or 64 bits in BG2?

Edit: never mind the "explosion" doesn't seem so bad now that i'm doing it.

Edited by i30817, 02 December 2011 - 08:09 AM.

[phordicus]

But I'm going to make a plea for people to preserve backwards compatibility. Add as many new stats as you like, but don't change the allocation of the existing stats to spells, or their IDS references.

I'll join you in that plea. If there's a way to expand without completely breaking everything that's come before it, that path is the preferred one, I'd think. Is it more of an issue of keeping it a Tweak rather than Core? I'm trying to imagine a situation where a player/modder would need Expanded Stats while simultaneously using an AI mod like yours.

[DavidWallace]

But I'm going to make a plea for people to preserve backwards compatibility. Add as many new stats as you like, but don't change the allocation of the existing stats to spells, or their IDS references.

I'll join you in that plea. If there's a way to expand without completely breaking everything that's come before it, that path is the preferred one, I'd think.

And I'd probably add, "if there isn't a way to expand without completely breaking everything that's come before it, don't expand". The current ecosystem of BG2 mods doesn't seem to justify that shift. (By contrast, if back in 2002 it had been possible to significantly improve DS while accepting that backward compatibility was going to be broken, it would have been worth it.)

Is it more of an issue of keeping it a Tweak rather than Core? I'm trying to imagine a situation where a player/modder would need Expanded Stats while simultaneously using an AI mod like yours.

To be honest, anyone who's happy to break compatibility with enemy-AI mods like SCS probably doesn't need Expanded Stats. The existing number of stats is more than enough for any half-way-realistic player-AI mod I can think of.

But in any case, I think this is pretty moot. If some spell is assigned a new stat via opcode 318, it's not going to get in the way of the old stat it was assigned via existing methods. The only way that problems are going to happen (I think) is if someone takes it into their head to remap the existing set of stats.

[i30817]

Never mind that about state diseased Ascension64. I misread iesdp:

0x80000 STATE_DISEASED
This state indicates whether the creature is "active" (as set by Activate/Deactivate actions).

So, it's completly another thing than what it says in the can


As for the discussion above, forgive me if i'm wrong (likely), but i gathered that the TobEx expandable stats are different from the normals ones in one particular:

They are timed, and don't get unset when spell/effect is dispelled (ended) prematurely.

Now it may be that every single stat is like that, but i didn't see that info anywhere, and was proceeding in the assumption that there were no "false positives"

Edited by i30817, 03 December 2011 - 08:18 AM.

[i30817]

But what about extending the Object identifiers?

Unlikely, the object identifiers fit into a discrete Object class with no room to move.

Ascension64, about this...

I was just told that [] constructs only return not dead Objects...

STATE_DEAD is a state. So to distinguish they may have put in a filtering check for it.

Find the right offset, inject a value and

[STATE.EA.FACTION.TEAM.GENERAL.RACE.CLASS.SPECIFIC.GENDER.ALIGN]

Voilà?
You'd have to be careful to specify the REALLY_NOT_DEAD in the bitmask when using it though.
Edit2 (changed my mind):
Mmmm they probably check like this:
(flags & STATE_DEAD) != STATE_DEAD

It wouldn't work very well for selection, since it's a filtering check. But it could probably be augmented to what we "don't" want to select.

(flags & STATE_DEAD|HELPLESS|ETC) != STATE_DEAD|HELPLESS|ETC

etc.
Which seems what we want in filtering?

Edit3: It's probably easy to find the place if you know where the code for the function is, since it is checking for a known mask (STATE_DEAD|STATE_INVISIBLE|STATE_IMPROVEDINVISIBILITY probably) or a sequence of these.

Edited by i30817, 04 December 2011 - 01:55 AM.

[i30817]

Oh god.

http://forums.gibber...showtopic=23610

Any chance of making DialogueSetGlobal work as in dialogs in AI scripts? Or even better, something like
Now(Action) trigger.

To use with sendtrigger, setglobal, timers etc.

Something that executes the action in the trigger phase if as i suspect the engine is aggregating all actions and then doing them all at once, which is incompatible with actually using their changes in the current AI script execution.

Though variable substitution that works in the trigger phase would possibly be almost as good (except in the case of Timers timers can be worked around with a checking a variable OR the timer and reseting the variable in the next round)

Edited by i30817, 10 December 2011 - 03:31 PM.