FO12_critters_editor_1.4.6.11
A few points on issues and experiences I had, and some suggestions to improve it.
-The reader only shows the base resistances for “normal DT & normal DR”, it does not for all the other damage types (laser etc.), there it only shows the "extra/bonus" stat.
[Note: I also tried to edit the base value (for laser etc.) but the reader reset them to 0. I then checked the file in ProtoManager v1.2.1 and it did save the changes I've made, so it seems that FO12_critters_editor_1.4.6.11 just doesn't display them.]
-The reader does not show Poison & Rad resistance. Not that important, though. Although Poison resistance may get used w/ critters (maybe?). Not sure, haven't poisoned many critters yet.
Advanced:
[The following is more a collection of experiences I had with problematic proto files, as well as experiments I made to figure them out.
However, they can be used to "improve" proto-readers.]
First,
-The reader does not take max values into account.
This creates two issues: First, not knowing if the values in the proto actual apply in-game (so a tool-tip of some sort would help), and, secondly, the reader gave me wrong values as it calculated the skills based on "10 base SPECIAL + 10 bonus SPECIAL", i.e. a total of 20. Which I'm pretty sure is wrong. When I checked that in-game [using code, see below], a critter with all SPECIAL stats on 20 had only 45% Small Guns (i.e. based on AG 10), not 85% (as it would be with AG 20).
So the reader calculating skills without taking the max (for SPECIAL) into account should be an error.
For the rest (i.e. the secondary/derived stats), I made a check in-game (using F12se & a clean 1.02d US version [no sfall (at first), later using 4.3.6]) and it seems the following are the max and min:
Age: 101 [minimum is: 16]
Exp.: seems to have no max, went up to 1.000.000 for a critter kill and can probably go higher. Can also get displayed in character menu correctly, only player level seems to max out at 99. [minimum is: 0 (skips XP message)]
Special: 10 (ST, PE, EN, CH, IN, AG, LK) [minimum is: 1]
HP: 999 [minimum is: 0 (death & kills script (obj_dude))]
AP: 99 [minimum is: 1]
AC: 999 [minimum is: 0]
Unarmed: UNUSED, and seems to have no max, went up to 101.000 and can probably go higher. [minimum is: 0]
Melee Damage: 500 [minimum is: 1]
Carry weight: 999 [minimum is: 0]
Sequence: 60 [minimum is: 0]
Healing Rate: 30 [minimum is: 0]
Critical Chance: 100, aka 100% [minimum is: 0%]
Better Criticals: 100 [minimum is: -60]
Skills: 300, aka 300% [minimum is: bizarre (skills can be reduced by -128 (max) and -256 (max) if tagged), so the min should be "skill base-128" & "skill base-256" if tagged, not sure if there is a wall (like -300%) as I couldn't figure out how to reduce a skill base that low, the lowest I could manage was -252%.]
DT: 100 (Normal, Laser, Fire, Plasma, Electrical, EMP, Explode) [Note: EMP is immune to bypassing armour.] [minimum is: 0]
DR: 90% (Normal, Laser, Fire, Plasma, Electrical, Explode) [minimum is: 0%]
DR: 100% (EMP) [Note: EMP is immune to bypassing armour.] [minimum is: 0%]
Poison Res: 95% [minimum is: 0%]
Radiation Res: 95% [minimum is: 0%]
As hinted above, I got these by setting my character stats to 1000 & -1000 (using F12se) and then checked in-game my character screen & inventory to see how the engine adjusts.
For those numbers I couldn't get a visual I used code:
Code:
procedure look_at_p_proc begin
display_msg("I have " + (get_critter_stat(dude_obj, 10)) + " Unarmed Damage!");
display_msg("I have " + (get_critter_stat(dude_obj, 16)) + " Better Criticals!");
display_msg("I have " + (get_critter_stat(dude_obj, 21)) + " Electrical DT!");
display_msg("I have " + (get_critter_stat(dude_obj, 22)) + " EMP DT!");
display_msg("I have " + (get_critter_stat(dude_obj, 28)) + " Electrical DR!");
display_msg("I have " + (get_critter_stat(dude_obj, 29)) + " EMP DR!");
end
Anyway, not sure what you'd want to do. You could prevent incrementing a stat when the total has reached the max. Or reset the total to the max when it exceeds it. Or both. However, that may confuse.
Maybe it's better to highlight such "totals" in red (to alert the user) and then it could just add (or pop up) a tooltip saying "This value will become "x" in-game." or "If exceeding "x", this value will become "x" in-game." etc. Which is "possibly" (?) best as it reflects the truth (i.e. I can set the proto to any value, but the engine then reduces them to the max).
Only exception should be the calculation of derived (aka secondary) stats (like HP, AC, AP, carry weight etc.) & Skills (Small Guns etc.). Those should take the max of 10 (for SPECIAL) into account before the reader calculates them. Otherwise a total of 20 ST may also just get highlighted red and pop-up a tool-tip saying that it will be 10 ST in-game.
[
Note: I did check this a little (set a villager proto to 8+10 ST and a dude to 1000+1000 and all the numbers I saw in-game (carry weight, melee damage) were based on 10). So a reader emulating the max of 10 for SPECIAL when calculating values should be true throughout. I only found one bug: when setting "base ST or EN" above or below the max/min it did bug out HP (failed to take min/max into account). Anything else I saw did reset correctly. That said, for simplicity, I would ignore this one engine bug. It's an outlier anyway.]
Secondly,
-Then I had a lot of trouble with "corrupted proto files" (or rather "manually (and incorrectly) edited proto files"). These are mostly proto files from the 2000's that are not properly set up (that means they edited the base rather than the bonus/extra stat and/or did not adjust the derived values after editing the primary ones (aka SPECIAL). It seems that Proto Readers (in general) can fail to correctly display such proto files, as their own "proper" calculation comes into conflict with the manually edited values. [Example; +3 ST should also increase HP by 3, and readers display it as such, but as the proto is edited manually, the HP is actually unchanged. Another example; a proto with a manually edited base HP of 49 will be displayed by readers as having a base HP of [
example] 34 which is calculated correctly (i.e. based on SPECIAL [
in this case ST 7 & EN 6]), but in-game it will be 49 HP, not 34. (
Note: both examples are taken from the tests below, see those for details)] These display errors are problematic as the info by the reader is not identical with how the proto file behaves in-game. Which is a massive headache when trying to locate bugs or reasons for in-game behaviour. However, I found that FO12_critters_editor_1.4.6.11 is better than ProtoManager v1.2.1 in this regard, as the displayed total seems always "true", only the base values are incorrect (i.e. it displays 16+34=65, so the base is wrong, but the total true), while ProtoManager displays it as 16+34=50 (which is not true in-game).
Anyway, these display errors were confusing me for a long time, but I think I got this figured out now...
Still, it may be that I made an oversight or error so the following (in quote) are my "test & figuring out" notes.
These tests are also step by step examples, which may be helpful if needing to clarify something or wanting to reproduce the behaviour.
After that is the summary of what I believe the issue is... and how to improve it.
Tests:
The most common issue was that values sometimes did show up and sometimes not (overwritten by the reader calculating the value itself). This could then create an odd mix of "unedited" values and "reader calculated" values which simply would not add up.
The following are my notes on this.
Test example:
I was testing the NPC_Mod by TeamX and part of this is switching into Power Armour (giving +3 Strength).
This showed the following behaviour while browsing:
[Note: I added examples (proto ID #), which should be reproducible if you use this with Fixt 0.81a (Full). And "possibly" also with any version of the TeamX mod.
It should also be possible to just edit any proto (using "edit in text format" [alt-t] of ProtoManager) to recreate any of the following. I added some example notes on how to set it up.]
First example,
-When I moved from a non-P[ower]A[armour] proto (319) to a PA-proto (320) it adjusted “base HP” to 37 (because of the +3 ST) but did not recalculate “total HP”, remains at 50. [edit: I believe the modders did manually add +3 ST, but did not recalculate the derived stats (like HP), which is still an unedited 34. So what happens here is probably that the reader recalculates the derived stat (based on ST 7+3), but the total uses the "unedited" proto value of 34, so it is still 34+16=50 (which is also what you'll get in-game; so good thing the reader does not overwrite the total with its own calculation) which would be 37+16=53.]
-When I then moved to the next proto (via arrow keys from a PA proto (320) to another PA proto (321)), it reset “base HP” back to 34 (i.e. it resets “base HP” to the unedited base value rather than calculating it [would be 37, if it did]). Only when I move from a proto without “extra Strength” to one with “extra Strength” does it adjust base HP again (in this case to 37). [edit: this was
really puzzling me for a long time, but as a wild guess I'd say the reader checks if the primary stats (aka SPECIAL) have changed, and if they didn't, it skips the calculation of the derived stats, which in this case has the reader call the proto's "unedited" HP of 34. However, this is a guess on how the reader works, not sure if I'm correct here... anyway, I don't know why else it would ignore the extra ST?]
[Note: I did check the proto in text format using ProtoManager v1.2.1 and the base HP of the proto is 34. So adjusting that to 37 (as the reader does) is how it should be (ST +3), but (as the proto is manually edited) the "true" base HP is 34 (i.e. the unedited value), which is also what will be used in-game.]
[
Side-note: ProtoManager does not show bonus stats to SPECIAL, you need to open the proto via text format to see it. Not sure why ProtoManager blocks it? As far as I can tell it does apply "correctly" in-game (?), which, btw, includes that it doesn't adjust HP (i.e. a bonus/extra to ST & EN behaves like drugs (Buffout), Power Armour etc. and does not change max HP). Something to keep in mind. In fact, your reader adjusting HP when giving a critter +3 extra/bonus ST or EN should actually be false. And could be fixed.
Which, btw, also means that whenever I said that +3 bonus/extra ST should add +3 HP, as I do above repeatedly, is actually also not correct. 
]
Second example,
-Carry weight behaves similar. When I move from a non-PA proto (319) to a PA-proto (320) it only adjusts “base carry weight” but does not recalculate total carry weight (if you check you'll see that base carry weight is 275 and extra carry weight is 75, but the total is only 275, which means something here is wrong (275+75=275). [edit: as above, I checked the proto in text format and the base carry weight is 200. So the reader's calculation for the base carry weight overwrites the unedited base value of 200, but the total then uses (correctly) the proto's unedited base which results in 200+75=275.]
-When I then move (from a PA proto (320) to another PA proto (321)), it resets base carry weight (using the “base Strength” only, i.e. ignoring the +3 extra ST) and the total adds up (75+200=275). [edit: should be the same as above, reader skips calculating the derived stat (as SPECIAL didn't change) and defaults to the proto value which is the "unedited" 200 (based on ST 7).]
...
[To recreate the above (First & Second example): set Ian (or a proto w/ ST 7, EN 6 & bonus HP 16 [all set properly]) to +3 bonus ST and +75 bonus carry weight via "text format". Then copy it to have two identical files in succession (example; proto 4 & proto 4 - copy). Do note that you'll have to do the editing of bonus ST in text format to avoid the automatic adjustment of the secondary stats (HP & carry weight). Anyway, after this, it will behave identical to the examples above, tested and confirmed w/ proto 4 (female villager).]
Addition:
The reader's behaviour of skipping the calculation of derived stats when the primary stats did not adjust also causes issues when editing.
Example, I click on proto 320 and replace the +3 ST with +3 ST. The reader recalculates all derived stats (HP, carry weight, melee) based on ST 10. Then I click on proto 321 (so the primary stats don't change) and then replace the +3 ST with +3 and the reader fails to recalculate the derived stats (HP, carry weight, melee). To get the reader to recalculate the secondary (aka derived) stats, I need to click on a non-PA proto (example 319) first, and then click on 321. [edit: or toggle ST around a bit, that gets it to adjust too, however, it needs some rattling to get it going either way.]
So it's probably a bad thing that the reader skips the calculation of derived stats sometimes.
Third example (but it won't show up in Fixt, I think),
-Ian (proto 322) has a total of 65 HP, and the base is 49. However, when browsing (w/ arrow keys from proto 321 to 323 and back) that base changes from 49 to 34 and back again. However, I don't think this will show up in Fixt proto files, but only in those of the enhanced version I pulled from pyran's database (and probably older versions of the TeamX mod, too (i.e. the files in questions are dated 2006)). I think this is an "edited base stat" (set from 34 to 49). I checked the proto in-game and there Ian will adjust to 65 HP (if in leather jacket) [that's 49+16=65] and drop back to 50 (if wearing anything else). There are some more proto files in the enhanced version that behave like this (those are (322, 331, 350, 359, 376 & 385). But as said this seems fixed in Fixt. [edit: same as above it seems, the proto has an edited base HP of 49 (which is used), however, the reader occasionally* recalculates the base (in this case to 34 according to SPECIAL), but displays a "total HP" (of 65) as it uses the "edited" base HP (of 49) to calculate the total... and that is also what will be used in game (16+49=65).]
*whenever SPECIAL changes
...
[To recreate the above (example Three): set Ian (or a proto w/ ST 7, EN 6 & bonus HP 16 [all set properly]) to 49 base HP (you'll have to use "edit in text format" for the base HP). Then copy it to have two identical files in succession. After this it will behave identical as described above, tested and confirmed w/ proto 4 (female villager).]
Another example (Fallout2),
In Wasteland Merc 2 are several proto files with edited base stats. For example, the 36 proto has a base HP of 995 (which the reader shows incorrectly; it calculates it based on SPECIAL), but it does show the total correctly (999 HP). This seems true for all WM 2 proto files.
In detail; proto 36 has an edited base HP of (995), plus extra HP (4) = 999 HP. Which will be displayed as base HP (30), plus extra HP (4) = 999 HP. However, the total is what will be experienced in-game, so it's a good thing the reader shows it. Still, it can be confusing until understood.
Btw,
you can easily reproduce the "calculation skip" with this one. Just make a copy of 36, then read the files. You should now have a 36 proto followed by a 36 (old) copy, which are both identical. When you move from any proto to a 36 one, it will recalculate the base HP (etc.) but when you move back and forth between the 36 and 36 (old) copy, it will skip that and show the value as it is in the proto (which is the edited 995).
And that's the observations & experiences I had with troublesome proto files [lots of time & headaches]. And how I eventually interpreted them (i.e. figured it out). And I think I got it all down now. Well, at least it started to make sense and has become predictable (i.e. I know what's going on now... generally).
At least, the interaction between “calculated values” and “base values (confirmed in text format)” as described above should prove correct whenever tested/replicated.
Summary:
-
First, it may be a good idea to add a "show proto in text format" option. So whenever something seems fishy, one can check what the "raw values" are in the proto (i.e. without having been processed by the reader). This can help a lot.
-
Secondly, the reader needs to recalculate the secondary (aka derived) stats each timer I click on a proto. [
Note: THIS IS A GUESS, if wrong than the following should be understood as an "example" of how it behaves.] The tests above show that if proto files have the same primary stats (aka SPECIAL) the reader seems to skip the step of calculating the derived stats, which causes minor issues with "manually edited proto files" [
note: base values can change without any rhyme or reason, see tests above] and, more importantly, it causes errors with "editing proto files" [
i.e. the skip causes a failure with the "adjustment of secondary (aka derived) stats after editing SPECIAL", that means I add +3 ST, and it does not change HP, carry weight etc. as it should, see also tests above]. [Note: The "editing bug" is arguably rare, and mainly caused by using extra/bonus stats for SPECIAL (i.e. editing w/o the +/- toggle), but it does happen, and fixing this will make it smoother in regard to "manually edited" proto files, as they will stop to switch around their base values. Although, the next (and, imo, more important) point would fix that, too.]
-
Thirdly, it may be a good idea if the reader, after calculating the secondary (aka derived) stats, could make a check if the calculated base value is identical to the base value in the proto, if true (display value), if false (overwrite calculation, show raw proto value and highlight it blue [a soft colour] to mark it as a "manually edited" base value, this means the value is "not correct" but "will be true" in-game). This way there should be less confusion with "corrupted" (i.e. falsely set up) proto files.
Basically, just skip the calculation if the base values are not identical and highlight it in blue (or something) to alert the user.
[
Note: this should only apply to the base value of secondary stats [HP, AC, AP, carry weight etc.], and not skills [Small Guns etc.], as those have no base value, it seems. With Skills it only matters that they are calculated based on the max of 10, as mentioned above. Actually, any reader calculation needs to take the min/max for SPECIAL into account, as mentioned above.]
[
Note II: To combine min/max and manually edited values, I thought it could highlight the total (if above/below the min/max) and the base (if manually edited). I think that may be best (i.e. there would be no overlap).]
-
And Fourthly, do note the small underlined side-note I squeezed into the "Tests" where I mention that +3 bonus/extra ST giving +3 HP should actually be incorrect (i.e. Power Armour/Drugs (aka bonus to ST/EN) do not adjust HP). Only base ST & EN do adjust HP: However, that's another detail. Not sure if you want to mess with it. But, as it is, the reader is currently not handling the editing of bonus/extra ST & EN correctly.
I think that's it... although there is probably more (to add, check & clarify), there usually is, but overall it should be correct. [I hope... although, there's probably an error somewhere. There always is.] However, I did run a lot of tests and it did confirm itself.
Still, it may be that I did a flawed test or overlooked something... so the best (as always) is to "Assume that everything I said is true, but double-check to confirm it anyway."
That's usually true with any bug report, in my experience, i.e. whatever it claims, it's true, just missing on a detail.
Anyway, it would make me feel better if you could.
For Modders:
Do check proto files with FO12_critters_editor_1.4.6.11. It shows the values more accurate than ProtoManager v1.2.1. Especially old proto files can be bizarre at times and have values of (example: AP has a base of 10, an extra of 2 and equals 30). Which, of course, is absurd, but in-game it will be 30 AP. ProtoManager v1.2.1 does not show this correctly (claims it to be 12 AP, which is not what you will experience in-game). It also hides values (like bonus to SPECIAL, edited base stats and so on). Which makes bug fixing much harder (i.e. figuring out what's going on). [I had to double check the proto as a text file to get the actual stats. So do that (if using ProtoManager) rather than relying on the UI. Or use Cubik's reader, which shows the values as they are, well, at least the total will be correct.]
Saves a lot of headache when trying to figure out why a critter with "allegedly" 12 AP, is acting in-game as if it has 30.
ProtoManager v1.2.1 also struggles with the max of values. It seems to have some arbitrary settings, which are not in accordance with the engine as far as I can tell. It can also force to change a value if it doesn't accept it as within the set range (example, I had a melee damage of 200 getting changed to -100 (first only displayed as such but then it got also saved as -100; so beware & edit in text format), the reason for this appears to be that ProtoManager v1.2.1 has set the max for melee damage at 180, which, as far as I can tell, should be an arbitrary number, as the actual max seems to be 500).
However, all "reader issues" aside it also helps to just set up proto files properly.
The majority of "issues" I found (see above) are caused by proto files that did not let the derived stats "update" themself after editing a proto w/ +3 ST etc. or edited the base values of secondary stats. Such "manually edited" proto files can fail to adopt or even get reset in-game (see note below). In general, it seems best to never change the "base" of secondary stats other than through "SPECIAL". Tbh, I don't even know why secondary stats even have a base value. I really think they should function like Skills which are always (SPECIAL + Skill bonus). If wanting to tweak a secondary stat best do it via "extra/bonus". Basically, just like Skills work. I have not found anything to the contrary yet, and in fact, can't think of any reason to ever edit the base of secondary stats. Unless you want them to reset themselves (more or less) frequently... as that is what will happen.
[Extra Note on "edited base values"
: it should always be possible in-game to reset a "manually edited" base value to the "correct" base value by feeding a critter SPECIAL changing drugs (like beer, buffout etc.). Doing so causes a recalculation of derived stats based on SPECIAL [HP does too, but skips any bonus to SPECIAL]. The secondary stats then stay that way until a map enter resets them back to their default (i.e. the values in the proto). So these "manually edited" base values are "true" (for the most part) but can be made to glitch (temporarily) in-game. Which shows the flaw in editing the base of secondary stats - too volatile.
Anyway, this is not really a proto reader issue. It only could add a tool tip maybe. Something like (for example) "Warning: this proto file "may" reset (the base values of secondary stats) in-game. Do use "bonus/extra" if wanting a value to be permanent." or "This base value is manually edited (i.e. not based on SPECIAL). Do note that such values "may" get temporarily reset by the engine (e.g. drug-use) and stay that way until a map enter resets them. If you don't want values to glitch, adjust them via extra/bonus.") or something similar, which could pop up when the proto file has "manually edited" secondary stats (like HP, AP, AC etc.). But most important, imo, is to show values as they are, plus maybe alerting the user to "edited base stats" (i.e. highlight such values). Both helps when reading a proto file. The actual rules of how all this behaves in-game is secondary as far as readers go.]
Graphic suggestions for FO12_critters_editor_1.4.6.11
-”ID number” could be renamed to “msg ID” (or "ID (pro_crit)") that may help to explain what it is (i.e. [as I understand it] this “ID” is the line in pro_crit.msg the proto calls upon if anything else (script, scrname) fails). Usually identical to proto number, but can be different. [example, the TeamX NPC mod did not adjust the ID for Ian, Tycho & Katja. So adding "ID (pro_crit)" may help people to understand it better. Especially, why it can be identical for different proto files.] But detail... I think it's called "message ID" in ProtoManager.
-It would be nice if I could update critters.lst (from data/art/critters) as well as the “aa” FRMs. [Note: it is possible that I can already do this, somehow [maybe I could edit "gif_critters.lst" and add the new AA frms after converting them into GIFs...?], and just haven't figured out how, yet. However, if not it would be a nice touch if "frm_critters.zip" could be expanded. Maybe even much easier (i.e. I just copy critters.lst and the AA frms (from the mod) into the folder) and done. Maybe combined with the Titanium FRM Browser 1.3 (en) if it needs a way to display frm models. Idk, if this makes sense, but it would be nice if I could add all the AA FRMs (once) and then just swap the critters.lst (in "frm_critters.zip") whenever I swap mods...]
-Side-note: I also had other graphic issues, however, I recently had to switch PCs (which had me also switch from 32 bit to 64 bit) and those issues went away. So if something comes up, and it can't be reproduced, it could be system related. Anyway, those old issues were:
-When in Fullscreen mode (aka maximized), the end of the proto list can be reached, but is outside of the window. This is caused by needing to use the slider on the right to move down all the way, but in full screen mode that slider isn't there. Fixed... can reach end of list no problem, no slider at the right at all times... 32 bit issue?
-TOO VAGUE-And I get often error messages like (“ is not a valid integer value) when using mods. These usually go away and cause no real issue, but still... Not sure what this is either? Maybe failure to adjust the FRM? Or some other conflict reading the proto. Could also be an error in my set up tbh... not sure. Needs more observing. 32 bit issue?
-When selecting the option "edit base values" under tools, it only allows to edit the base values for damage resistances, and nothing else (i.e. the base values of secondary stats (HP, AC etc.). Skills and SPECIAL are fine as they are (i.e. SPECIAL works via the +/- button and Skills don't have a base that can be edited, as far as I know).] Edit: Nvm, after all the tests I did, I think the reader is handling this perfectly fine, i.e. editing the base of secondary stats seems like a really bad idea, as it's possible to "reset" base values (of secondary stats) by giving a critter drugs (example; a base of 999 HP would get wiped after a single beer, while adding the 999 through bonus HP, should make it permanent). That said the reader's handling of this (only allows to edit the base values for damage resistances) seems already best as it is... so nvm.)
