Displacer Posted November 1, 2017 Author Posted November 1, 2017 Well that's about it. For some reason, some of the switch statement code was out of order so I skipped over most of them, there weren't many but there are a few I didn't check. So there you have it. Let me know if you need the parameters hunted down, or any other info. Quote
Avenger Posted November 1, 2017 Posted November 1, 2017 (edited) Opcode 319 (the usability opcode) is empty in all of the regular effect methods. But just because an empty method is similar or optimized to be exactly the same, just an empty stub, it doesn't always mean the opcode is dud. Opcode 319 is absolutely not a normal opcode, it never gets pushed onto any object's effect queue, it never gets applied. It is even completely ignored in a spell. It just sits in the extra usability flag list of an item. Other opcodes, like Knock, are kinda similar, totally empty, yet when they are getting applied on an inanimate object, they might do something. Show creatures/retreat from (opcode 110) are empty and don't even have any 'special' function. Though retreat from has a function in PST(EE). Edited November 1, 2017 by Avenger Quote
kjeron Posted November 1, 2017 Posted November 1, 2017 Opcodes 182/183 have been documented, they just haven't been updated in IEDSP. 183 is "Use EFF file if/while item type equipped". (If or While) depends on the opcode used in the external EFF. 182 would be "Use EFF file if/while item resource equipped", except that its resource field does not work, so it cannot restrict itself to a specific item, and its EFF resource is specified in Resource2, so it must be used in V2 effects. Free action removes Opcode 126's that SET VALUE less than normal(normal = INI move_scale). Free action suppresses(~1 Round) Opcode 176's that SET VALUE less than normal. 312 has worked for some time in the EE's, just not updated in IESDP. 112, 274, 313, 338, and 360 are all correctly documented in the IESDP, despite any difference you see in their code. My understanding is that 322 was abandoned in favor of 324, it does not work in-game. Quote
Displacer Posted November 2, 2017 Author Posted November 2, 2017 Opcode 319 (the usability opcode) is empty in all of the regular effect methods. But just because an empty method is similar or optimized to be exactly the same, just an empty stub, it doesn't always mean the opcode is dud. Opcode 319 is absolutely not a normal opcode, it never gets pushed onto any object's effect queue, it never gets applied. It is even completely ignored in a spell. It just sits in the extra usability flag list of an item. Other opcodes, like Knock, are kinda similar, totally empty, yet when they are getting applied on an inanimate object, they might do something. Show creatures/retreat from (opcode 110) are empty and don't even have any 'special' function. Though retreat from has a function in PST(EE). Yea, I'm almost positive the Show creatures are just there to prevent crashes. 110 was just the first one I found, most likely fixups from EE. As for 319, I didn't go further into the code, what I posted was from the switch statement, they're just setup code but the call after setup is to detect traps, that doesn't mean it works however. I did no checking into parameters, or the calls themselves from the setup code so its entirely possible they're broken in another area of code, that's why I added to some that it should be tested. If you need, I can trace through any of them to their completion Quote
Displacer Posted November 2, 2017 Author Posted November 2, 2017 Opcodes 182/183 have been documented, they just haven't been updated in IEDSP. 183 is "Use EFF file if/while item type equipped". (If or While) depends on the opcode used in the external EFF. 182 would be "Use EFF file if/while item resource equipped", except that its resource field does not work, so it cannot restrict itself to a specific item, and its EFF resource is specified in Resource2, so it must be used in V2 effects. Free action removes Opcode 126's that SET VALUE less than normal(normal = INI move_scale). Free action suppresses(~1 Round) Opcode 176's that SET VALUE less than normal. 312 has worked for some time in the EE's, just not updated in IESDP. 112, 274, 313, 338, and 360 are all correctly documented in the IESDP, despite any difference you see in their code. My understanding is that 322 was abandoned in favor of 324, it does not work in-game. Not disputing that some opcodes are correct, as I said what I posted was just setup code and the call, I didn't check the parameters or how they are used, or the actual calls so they may very well work as described, the call altered via the parameters so I'm not disputing that, just posting the differences I found while I was in that section. I can always trace back to see how the parameters are used, or trace forward from the setup code if needed. I may do that anyway because now I'm curious how they're used So I saw a lot of unknowns in the parameters of the opcodes, are they still unknown and just not updated in the database? Or do they still need to be explored? Quote
Avenger Posted November 6, 2017 Posted November 6, 2017 (edited) So I saw a lot of unknowns in the parameters of the opcodes, are they still unknown and just not updated in the database? Or do they still need to be explored? If you see any undocumented parameters that are not written in the unprocessed forum threads, then sure. Especially if you have some idea how they work. There could be still some special, parameter3 or parameter4 fields that are unknown. Edited November 6, 2017 by Avenger Quote
Displacer Posted November 17, 2017 Author Posted November 17, 2017 112, 274, 313, 338, and 360 are all correctly documented in the IESDP, despite any difference you see in their code. That's not how software works... Quote
Displacer Posted November 17, 2017 Author Posted November 17, 2017 So I really don't know how to proceed with this. I'm getting the usual "you're wrong and a tool to boot" and other random nonsense, even though I'm posting the actual code that differs from what you're arguing I'm wrong about. I stated clearly that some things may be modified by parameters, and should be tested because obviously the code has been changed in the EE version, which is what I'm documenting. I could traceback through all the code after the setup code, but I suspect I would get the same arguments, so I don't know if I really want to do that and have to argue through it. It's also a pain knowing things have been discovered and just not updated in the database. That doesn't bother me as much, I just see it as double checking. At any rate my opinion is they should be rechecked to see if they match up to what I've found, not just blown off as incorrect. I'll give you the offset to the switch statement to all the opcodes and you can see them for yourself. I've also found the "Actions" switch statement and I don't know if it would be worth the trouble of going through them, considering what I'm getting here I mean do you want to know how these work or not? Quote
Displacer Posted November 17, 2017 Author Posted November 17, 2017 Found the Apply Effect section. This appears to be after all the setup has been done and the actual effect is applied. They range from a few lines of code to several hundred lines for different effects. Some of them have switch statements, I'm assuming this has to do with the parameters. For example CGameEffectAC::ApplyEffect contains a switch statement with 17 different switch statements, meaning (I assume) 17 different outcomes can be had with this effect. Quote
lynx Posted November 17, 2017 Posted November 17, 2017 my guess would be one of the big ones is a timing mode switch. 112 didn't change with the ees, it's even the same in all engines. So it'd be easy to check the actual behaviour rather than argue over labels in code. One thing I'm interested in is what range the Help action uses. Quote
argent77 Posted November 17, 2017 Posted November 17, 2017 (edited) One thing I'm interested in is what range the Help action uses. Based on some tests in BGEE Help() has a range of 1152 (horizontal) and 864 (vertical) in map coordinates. Effective range will most likely vary depending on object specifier used for trigger Help(O:Object*). Edited November 17, 2017 by argent77 Quote
Displacer Posted November 17, 2017 Author Posted November 17, 2017 One thing I'm interested in is what range the Help action uses. Ugh, I have to find the actions section again, forgot to mark it Quote
Displacer Posted November 17, 2017 Author Posted November 17, 2017 One thing I'm interested in is what range the Help action uses. I'm in the Execute Action switch statement. The switch is loaded with 413 cases, which lines up with the number in the database, yet Help is not one of them. I cannot find 17 anywhere in the switch statement. I have no idea what's up with that. This is the EE version of BGII, maybe it got changed to another number? I know Help was kind of flaky in PS:T. I may have to traceback to AI Decode, see if it got changed. If not, I have no idea where it's processed. I can say it's not in with the others Quote
Avenger Posted November 18, 2017 Posted November 18, 2017 (edited) One thing I'm interested in is what range the Help action uses. Based on some tests in BGEE Help() has a range of 1152 (horizontal) and 864 (vertical) in map coordinates. Effective range will most likely vary depending on object specifier used for trigger Help(O:Object*). In the EE Help() has the range of "visualrange" * 48 ( *3 / 4 in the vertical ) Where visual range is adjusted by opcode 262 and the '48' can be set by the 'Audible Range' game option in baldur.lua Don't ask me, why a blind person can only whisper. Edited November 18, 2017 by Avenger Quote
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.