I just released my version 2.4.1 of my protoed program. Here are the changes in this version: Version 2.4.1 * Fixed Bug - Forgot to reset ini file and boool value when reading in combobox header info resulting in armor not showing. * Fixed Bug - compare/combine - Due to loading description had a lot of extra lines for protos.tab file. turned off loading desc when comparing/combining. * Fixed Bug - compare/combine - field data copying in certain cases to where you had cursor before compare/combine. Tech support method didn't work in this case so changed back to the way I had it.. Version 2.4 * Added - Combobox variables for dialog files. * Added - Refresh file list box upon showing it. * Added Ability - Multiple row selection. Click(left or right) col 0 if fixed OR right clicking allows select/unslect ability. * Added Ability - Multiple col selection. Click(left or right) on row 0 to toggle OR right clicking allows select/unslect ability. * Added Ability - Unhide rows and columns via number, via right click menu. * Added Feature - Active Cell Color. Now when you have a row selected you can see where your at even easier. * Added Feature - Hide/Unhide Rows and columns from the right click menu. * Added Feature - Hide/Unhide Slected Rows and Columns from teh right click menu. * Changed - Made the memo field(variable List) have scroll bars. * Changed - Compare/Combine Code to better support other files besides protos.tab. * Changed - the way dlg files load in should be much cleaner. * Changed - the way mes files load in and save. * Changed - the way you select colors, nicer this way? * Changed - Misc graphical/design changes. * Changed - Auto num align on. * Changed - Allow to resize fixed columns. * Changed Feature - Sort by col # will now sort non numeric rows as well. * Fixed Bug - If you typed something in the selection boxes before changing them, it'd crash. * Fixed Bug - On load if you had more than 1 fixed column it'd reset to one. * Fixed Bug - Redundant unhiderows would make load process take a little longer after hiding rows. * Fixed Bug - Current cell color - If columns were hidden it wouldn't get correct column, thus wrong cell would be highlighted. * Fixed Bug - Sorting by col # - If you had hidden columns then you couldn't sort the last columns (number releveant to how many hiden). * Moved - Status message and progress bar to bottom of form. * Moved - First two column header to ini file. * Updated - Ini File
Great editor. Really like the sorting function. Makes the list more orderly and comparisons considerably easier. Here are some fields which I feel code for certain parameters. You may want to double check them before inclusion. column 158 base Reflex save 159 base Fortitude save 160 base Will save 161 Natural Armor Below are some snippets of findings supporting the above claims: Ogres have 0,6,1 respectively for columns 158,159,160 Hill Giants have 3,12,4 Trolls have 4,11,3 All values are similar to that in 3.5e SRD. Column 161 should be Natural Armor. Trolls have 7, Hobgoblins have 4 and Hill Giants have 12. Ogres should have 6 as per the 3.5e SRD but this column was blank which made the value default to 0. Since Ogres have a Dex of 8 (-1AC) and are large sized (-1AC), this makes their AC 8 which is unusually easy to hit and should be rectified. As further proof, Lubash (the Moathouse Ogre) does indeed have a 6 in this column. Thanks again for providing an easier means to go through and fix protos.tab and keep up the good work. EDIT: Many humans do not have values for columns 158,159,160. I suppose these values then default to 0? Lareth, for example, has no entry in these columns but Hedrack has a 5 in the Will column. At first I thought this could be due to the Helm he is wearing (+5 Will, IIRC) but then remembered that he also had a pair of Boots with (+5 Reflex?) and there's no similar increase in the Reflex section. Perhaps he somehow has an innate +5 to base Will save? I don't remember any races/classes giving a +5 either. Any ideas? EDIT: Was wondering what column 130 stands for when it struck me that could it be reach? 5 feet (normal) or 10 feet (extended) Noted that Ogres, Hill Giants, Trolls have 10, whereas Will o Wisps and Lizardmen have 5. Goblins, Hobgoblins and humans have no entry in this column (which I suppose defaults to a 5)? Then noticed that column 35 was defined as "target size/reach". Not sure what to make of this. But isn't reach suppose to be 5 feet/10 feet values in the game?
Zhuge: I got the target size/reach from playing with the field. make it high on a frog and go to moathouse it changes the size of the target circle around them (red circle) and thus affects the yellow circle around them as well. I'm not usre wether to call this confort zone, threat range or what. I do know with changing it up higher the froggs could hit me from afar(edge of yellow circle). Thanks for the column info both of you. Unless someone reports a major bug it'll probably be awhile before I upload a newer version all that I've cahnged so far from 2.4.1 is: Version 2.?.? * Changed - Comparison Reporting now shows column header rather than #(if you have show column nums on it'll show both ) * Updated - Ini File (the above changes)
Ah, I see now. Since DnD creatures are now squarish by 3.5e rules (correct me if I'm wrong but I believe there used to be rectangular ones, eg. 10 X 5, back in 3.0e), it makes sense to code the area that they occupy into a circular one. So I think, it is possible that: a)The area occupied by a creature is given by the red circle and is coded by column 35 as you have stated and the yellow circle which represents reach/threatened area is coded by column 130 instead which stands for the radial distance from the edge of the red circle to the edge of the yellow circle (or in other words: radius of yellow circle - radius of red circle) Or b)The area occupied by a creature is given by the red circle and is coded by column 35. The (yellow circle's radius - red circle's radius) is also dependent on this column. Column 130 has no effect on reach at all. I am not particularly keen on checking which is right (I believe that a) is correct though) currently, and would really appreciate it anyone interested could help do the testing. Looked a little more closely at column 35. It's pretty hard to understand (at least for me). First off, I see 32.000000 which is encoded by a "float?" and 25 which should be encoded by an "integer" but I also see some left-aligned "integers" in the column. Could these be erroneously coded as a "string" and therefore left-aligned instead of right-aligned as is normal for all numeric variables. There are many columns which are blank. So I suppose there must be a default value somewhere. After all shouldn't all NPCs occupy some space? Seeing many small creatures are blank in this column, I suppose the default value is pretty small. These include: {14003}{Hommlet Village Girl} {14182}{Stirge} Adult humans seem to be standard (25 or 5X5). These include: {14144}{Hostler} // Dick Rentsch {14145}{Barkeep} // Wat I noticed larger creatures at: Column 35 = 27 {14093}{Bugbear} {14159}{Air Temple Bugbear} Column 35 = 30 {14109}{Ice Lizard} {14090}{Giant Lizard} Column 35 = 32 {14309}{Gorgon} Column 35 = 35 {14111}{Salamander} ... The Juggernaut which is really big, clocks in at 70 (or 8.3666^2) for column 35 and a 10 for column 130, which I still strongly feel to be reach. The Giant Gar seems to be the biggest creature (actually the longest) at 85.0000 (or 9.2195^2) for column 35 but only records a 5 for column 130. A quick look at these 2 parameters for those who have old saved files should show the disparity quite clearly. Space/Reach in the 3.5e SRD (given as separate variables) both seem to be based off 5 foot increments but Space here in ToEE seems rather more varied whereas Reach (if encoded by column 130 maintains its 5 foot increments). Sorting, hiding and comparing is really easy and fun with your editor and it's very much easier to figure things out as opposed to mucking around with the file with Notepad. :thumbsup: Pardon me for my loose use of computing terms and my long rant. I hope we can work something out of the above. I sense we are close anyway. EDIT: Just a thought but once some of these fields are confirmed by further tests, updating the "Protos.tab fields" stickied post would be nice as well. No hurry though, we should confirm the stuff first, ideally by different people before its up for viewing.
just checked and yes col 130 effects reach, I guess it is some kind of multiplier of 35. because changing 35 will make ones reach larger. so the larger the creature the larger a reach of 5 is for them .....
Hmm... so perhaps it isn't as simple as I thought... oh well... Anyway just to clarify again, enemies are circled in red and have their threatened areas coloured and circled in yellow. I thought that while increasing column 35 will increase the creature's size (denoted by the red circle), it should have no ADDITIONAL effect on reach. Obviously a bigger creature would have longer reach if the centre of the red circle it occupies is taken as the point of reference. But what I mean is when you substract the radius of the red circle from the radius of the yellow circle, the remaining distance will still be 5 or whatever is encoded in column 130, regardless of what is in column 35. If a creature's size has an additional effect on reach as a multiplier, then it's back to the drawing board for me. IIRC, the Giant Gar had a really large red circle surrounding it to represent its body but the threatened area surrounding it did not extend by much beyond 5 feet. It certainly didn't seem too different from the threatened area of my fighters after having taken into account the huge size of the gar. Perhaps I'll open up some files to check it myself when I get back. Thanks for testing.
Ok I'll take another look and see, maybe I was just thinking it increase reach range when it didn't and was mislead by the whole thing being bigger.....
Ah, that's good news. I arrived at pretty much the same conclusion after looking closely at the Giant Gar and Sea Hag on the screen. Brought out a transparent ruler too, just in case. Giant Gar has size 80 and a reach of 5, while Sea Hag only has size 30 (which makes it a bit bigger than the average medium sized adventurer at size 25 and this indeed shows on the screen if you look closely) but a reach of 10 The yellow area is indeed bigger for the Sea Hag while the red circle denoting size is much smaller for the hag when compared with the gar. I'm currently looking at column 154 and a few others but have had no inspiration. } The occasional problems with different alignments (left or right aligned) and different notation in the same column isn't helping either. Noticed that CR for goblins is 1/4 but left aligned and the logbook reads it as -2(??) whereas the right aligned numbers for CR are read correctly. <long sigh>... Perhaps I will switch to other groups and come back to NPCs later. If they had standardized the columns a little more, it wouldn't take so long. I guess I need a few more ranks in Decipher Script to make progress faster.
