jastey Posted November 1, 2018 Share Posted November 1, 2018 Maybe it's the "PartyRested()" trigger which gives only true right after the rest ends so if it's at the beginning of the baldur.bcs it gives true but if it's at the end of the script the time passed might be too long already - or something. Keep in mind that other mods might add to the top after yours, so there might be a risk that the script block might not get executed in a mega mod install. Quote Link to comment
Luke Posted November 1, 2018 Author Share Posted November 1, 2018 (edited) Maybe it's the "PartyRested()" trigger which gives only true right after the rest ends so if it's at the beginning of the baldur.bcs it gives true but if it's at the end of the script the time passed might be too long already - or something. Keep in mind that other mods might add to the top after yours, so there might be a risk that the script block might not get executed in a mega mod install. What do you mean by the time passed might be too long already? Edited November 1, 2018 by Luke Quote Link to comment
jastey Posted November 1, 2018 Share Posted November 1, 2018 I meant the "PartyRested()" trigger only gives true if the script block is called the moment after the party rested, but not some instances later. Quote Link to comment
Jarno Mikkola Posted November 2, 2018 Share Posted November 2, 2018 ... trigger only gives true if the script block is called the immediate moment after ...Fixed tht for you. So if the script has any true statement before this one and that one doesn't have a CONTINUE() in it, then the rest of the script is not "read", nor can it interact with the rest of the game. That's how the games scripts work. Quote Link to comment
subtledoctor Posted November 2, 2018 Share Posted November 2, 2018 What do you mean by the time passed might be too long already? Scripts take a nonzero amount of time to process. BCS is not very efficient code, it's a bunch of IF->THEN scripting that has to run sequentially. Scripts can be triggered once per second (e.g. baldur.bcs) or triggered by external circumstances (e.g. creatures being created) etc. If a script is triggered before that last instance of it has finished processing, it can simply skip arguments at the end. Example, code up a bunch of stat bonuses that operate by script with the CheckStat trigger. The bonuses can end up blinking in and out of existence as the game tries and fails to keep up with all the triggers. That's why nobody ever modded stat bonuses in the last 20 years. This is why I'm constantly advising people to avoiding relying on scripts when it's possible to use spell effects instead. Quote Link to comment
Jarno Mikkola Posted November 2, 2018 Share Posted November 2, 2018 (edited) Scripts take a nonzero amount of time to process.This is not true. One script can run 15 timer per second(half the frames per second infact). What's not nonzero taking is the THEN --- END process, that can very well take several rounds of effect time to complete, where the effected user of .bcs does nothing else, ever, as it's action list is occupied. The IF part of a script does 1 thing, checks if variable x is true, from RAM... this is what your computer does all the time. That's why it's fast. Edited November 2, 2018 by Jarno Mikkola Quote Link to comment
DavidW Posted November 2, 2018 Share Posted November 2, 2018 No, sufficiently many IF blocks evaluated 15 times per second can slow the game to a crawl (at least on vanilla BG2) even if none of them actually fire. Avoiding that problem is a significant design constraint on SCS mage scripts, which are 10,000 to 20,000 lines long; I did fairly extensive testing on it back in the early days of SCS. Quote Link to comment
subtledoctor Posted November 2, 2018 Share Posted November 2, 2018 (edited) EDIT - stated better than I could. Edited November 2, 2018 by subtledoctor Quote Link to comment
Jarno Mikkola Posted November 2, 2018 Share Posted November 2, 2018 I did fairly extensive testing on it back in the early days of SCS. Yeah, and how much of ram did you have by then ? In allowed usage. 16Gb's ? Cause the entire game didn't take 16 Gb's. Did you even make notes on your memory parameters etc when you tested the thing by then ? + OS, .exe etc related to memory utilization. Remember, the non-EE game ran on a Windows 95. Which is why the game files can only be 8 characters long(+3 characters in the extension). And the .bif's are copied to the cache folder if it has enought allowed space. Now, there's no doubt that heavy script load put the non-EE game to it's knees, but that shouldn't be much of a problem today with EE, as the game can use the extended write space and all(Physical Address Extension).. this mean also that the game doesn't need biffing. If you have a 64 bit x86 processor. @std: As your Leopard is one. Quote Link to comment
DavidW Posted November 2, 2018 Share Posted November 2, 2018 Im not going to waste my time with this. Quote Link to comment
Luke Posted November 10, 2018 Author Share Posted November 10, 2018 No difference that I'm aware of. So they both remove the active CRE from the GAM file, right? Quote Link to comment
Luke Posted December 27, 2018 Author Share Posted December 27, 2018 (edited) @DavidW I need your help: I'd like my CRE to spam a certain SPL every (say) two rounds only if there is at least one humanoid (but RACE != mephit) in weapon range. The target of that SPL must be one of those humanoids. How can I do this? EDIT: Solved (hopefully...) Edited December 30, 2018 by Luke Quote Link to comment
Luke Posted January 9, 2019 Author Share Posted January 9, 2019 (edited) @Wisp It seems WeiDU (version 246) cannot parse things like this: !StateCheck(NearestAllyOf(Myself),STATE_STUNNED | STATE_HELPLESS) Are you aware of this bug? Edited January 9, 2019 by Luke Quote Link to comment
Jarno Mikkola Posted January 9, 2019 Share Posted January 9, 2019 (edited) 1 hour ago, Luke said: @Wisp It seems WeiDU (version 246) cannot parse things like this: !StateCheck(NearestAllyOf(Myself),STATE_STUNNED | STATE_HELPLESS) Are you aware of this bug? Yeah, that's not a scripts IF-THEN clause that can be parsed, but this is: OR(2) !StateCheck(NearestAllyOf(Myself),STATE_STUNNED) !StateCheck(NearestAllyOf(Myself),STATE_HELPLESS) You might be associating a different type of script making algorithm to the weidu's actual one, where it just takes a text coded .baf file and compiles it as a .bcs, which is the games actual script file. Edited January 9, 2019 by Jarno Mikkola Quote Link to comment
CamDawg Posted January 9, 2019 Share Posted January 9, 2019 6 hours ago, Luke said: @Wisp It seems WeiDU (version 246) cannot parse things like this: !StateCheck(NearestAllyOf(Myself),STATE_STUNNED | STATE_HELPLESS) Are you aware of this bug? In this case you're better off just directly using the numeric values here; I believe this construction is from NI's parser. STUNNED is 0x8, HELPLESS is 0x20, so you can safely use !StateCheck(NearestAllyOf(Myself),0x28) If you're going to be using it often it might be worthwhile to add it as a custom entry to state.ids. Quote Link to comment
Recommended Posts
Join the conversation
You are posting as a guest. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.