Jump to content

SFO: bugs/questions/curiosities


Recommended Posts

Posted (edited)

@DavidW

I noted a some inconsistencies about something you're not using (as of now!), i.e.: "make_creature".

  1. There's no default value for "Maximum HP – offset 0x26" (CRE_build)
  2. Is there a particular reason why you don't launch "CRE_enforce_hp" when launching CREpostbuild? I mean, Hit Points depend on Class/Kit and Levels just like "Thac0" and "Saving Throws"...
  3. CRE_enforce_hp: Unlike the other "CRE_enforce" functions, the string "arguments" is not initialized to "" (empty string)...
  4. Your INI file (stratagems.ini) lacks the entry "hitpoint_percentage=100" (it's checked by "CRE_enforce_hp"). As a result, it gets set to 75% as per "CRE_enforce_hp". I think the most noticeable effect is that "enforce_hp=>at_worst" will return unexpected values...
  5. I'm not sure if "enforce_hp=>only_if_new" works as expected or not... I mean, if I write 
    LAF "make_creature"
    STR_VAR
    	"editstring" = "level=>5 animation=>FIGHTER_MALE_HUMAN class=>THIEF race=>HUMAN kit=>ASSASIN"
    	"creature" = "GTTEST"
    END

    Thac0 and Saving Throws are correctly pulled from "THAC0.2DA" and "SAVEROG.2DA", but Hit Points remain at 0/0... I've already tried adding "CRE_enforce_hp" to "CRE_postbuild", still nothing... What's the issue here?

Edited by Luke
Link to post
Posted (edited)
9 minutes ago, DavidW said:

Since as you say make_creature isn't code I'm using (or I think have ever used), I doubt I ever debugged it after initial coding.

 

OK, so you're ignoring it for now...? Guess that the HP issue can be "fixed" via using "clone_creature", but it's kinda ugly...

Anyway, you might want to check points #3 and #4, since "enforce_hp=>at_worst" is used a lot...

Edited by Luke
Link to post
Posted (edited)

Another one:

power is located at 0x10, not 0x18. You also need to fix the related functions "CRE_power", "CRE_powerGT", "CRE_powerLT", "CRE_read_power" located in "stratagems/sfo/SFO_autofunc.tpa"...

Edited by Luke
Link to post
37 minutes ago, Luke said:

power is located at 0x10, not 0x18.

No it isn't. This is a CRE v2.0 EFF field, not an ITM/SPL v1.0 field.

37 minutes ago, Luke said:

You also need to fix the related functions "CRE_power", "CRE_powerGT", "CRE_powerLT", "CRE_read_power" located in "stratagems/sfo/SFO_autofunc.tpa"...

SFO_autofunc is autogenerated. Just delete it, it'll be rebuilt. (But don't do it to fix the above)

Link to post
48 minutes ago, Luke said:

OK, so you're ignoring it for now...? Guess that the HP issue can be "fixed" via using "clone_creature", but it's kinda ugly...

Anyway, you might want to check points #3 and #4, since "enforce_hp=>at_worst" is used a lot...

I'm not just ignoring it 'for now'. I thought I made clear that this was a tool for my own use, not something I'm supporting. Bits of it I haven't in fact used probably have all manner of problems. 

Using the default value for hitpoint_percentage is intentional. (Though the ini was originally supposed to be exposed for power players' use.) The missing arguments field is a bug that needs fixing.

Link to post
1 minute ago, DavidW said:

enforce_hp is working as intended. (Or at least: what you describe is intended behavior.)

Yeah, if I add something like "enforce_hp=>default" (or any other string but "at_worst", "at_best", "only_if_new"), then "make_creature" works as intended... "only_if_new" => SET new=current = 65535 ? possible : current. Since I didn't specify anything, current is not equal to 65536, thus HP are set to %current%, i.e.: 0.

Link to post
Posted (edited)
1 hour ago, DavidW said:

I thought I made clear that this was a tool for my own use, not something I'm supporting.

That's why I said "for now". If someday you use it, then you'll fix it...

Anyway, as I've realized afterwards, "enforce_hp" is working as intended. I apologize. It didn't behave as I expected because:

  1. the INI entry "hitpoint_percentage=100" is missing
  2. you don't launch it when launching "CRE_postbuild"
  3. unlike the other "CRE_enforce" functions, the string "arguments" is not initialized to "" (empty string).

I'm glad I can use it in the end...

Edited by Luke
Link to post
Posted (edited)
2 hours ago, DavidW said:

No it isn't. This is a CRE v2.0 EFF field, not an ITM/SPL v1.0 field.

OK, so both "power" and parameter2 are located at 0x18...? That's clearly not possible...?

Edited by Luke
Link to post
1 hour ago, Luke said:

OK, so both "power" and parameter2 are located at 0x18...? That's clearly not possible...?

I can't argue with that.

Looking more carefully, the first 8 bits of the EFF 2.0 format are left out when it's used internally to a CRE file. So although IESDP lists Power as 0x18, it's 0x10 on a CRE file. I obviously remembered this when I originally coded this section, but forgot it at some later stage when I added that entry. Thanks for catching it.

Link to post
1 hour ago, Luke said:

That's why I said "for now". If someday you use it, then you'll fix it...

Anyway, as I've realized afterwards, "enforce_hp" is working as intended. I apologize. It didn't behave as I expected because:

  1. the INI entry "hitpoint_percentage=100" is missing
  2. you don't launch it when launching "CRE_postbuild"
  3. unlike the other "CRE_enforce" functions, the string "arguments" is not initialized to "" (empty string).

I'm glad I can use it in the end...

I have it set to 75 rather than to 100 by default because hitpoint_percentage determines where a creature's hp lie in the range minimum-to-maximum, and my default choice is to put them about 3/4 of the way along (higher than the 50% you'd expect from random die rolls, but short of being maxed out). That's an SCS design choice (SFO isn't always careful about separating out SCS design choices from tool functionality). The ini value should probably be included (my current local codebase sounds a warning if a nonexistent ini is checked, but that's not backported to SCS yet).

I don't remember why I don't launch it in CRE_postbuild. Possibly because hitpoint spread is an active design choice; possibly just by mistake. Like I say, it's not code I use.

Not initialising it is sloppy (in my ideal world, WEIDU would fail or at least sound a warning if you call a function with arguments it doesn't have) but I think harmless.

Link to post
On 6/25/2020 at 11:28 PM, DavidW said:

(higher than the 50% you'd expect from random die rolls, but short of being maxed out)

Yes, I agree that Hit Points should be somewhat randomized (as per D&D rules). However, I think it's reasonable to expect the possibility to max them out...

Link to post
Posted (edited)

This seems to be another bad initialization... If you print it, you get (on an EE install): %scsroot%=stratagems&%tutu_var%=.

You probably meant scsroot=stratagems&tutu_var= (there's a mismatch between "%" and the variable "percentage"...)

Edited by Luke
Link to post
Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...