acr_tools_i

AcadiusLost · Post by **AcadiusLost** » Thu Mar 01, 2007 6:32 pm

Worked out what was failing with the RandomFloat(fMin, fMax) function in the acr_tools_i package, so I can try commiting a new version of that file this evening. The function was using IntToFloat(Random(MAX_INT)) / (IntToFloat(MAX_INT)) , with MAX_INT defined as the maximum possible integer, but accoring to the lexicon, Random(nInt) can't generate anything larger than 65,000 or so, so the RandomFloat() was always producing values in the range of 0.0005 or so.

Anyone have any objections to adding an ACR_GetIsPlayerOrDMinArea() function, modelled off the ACR_GetIsPlayerInArea() we already have in there? Would be handy to have if we want the spawn system to respond to DM avatars (though I could juts handle it within the spawn system code if necessary).

ç i p h é r · Post by **ç i p h é r** » Thu Mar 01, 2007 6:47 pm

Will this be your first commit? I'll put some champagne on ice.

No objections, although you could pass the existing function an argument to key on, for example, TYPE_PC, TYPE_DM, or TYPE_BOTH. Default to TYPE_PC for backward compatibility. The function uses the term Player, not PC, which in the NWN vernacular means DM or PC.

AcadiusLost · Post by **AcadiusLost** » Thu Mar 01, 2007 7:01 pm

The acr_tools_i.nss will be my first commit, yes, and a pretty minor one at that- I suppose as such it'll be an easier introduction to the process.

I did the adjustment of the Seamless AT scripts last week, but found a minor bug in the process, regarding arriving into an area amidst overlapping Seamless ATs- haven't had time to wrap that up amidst the spawn system work. Seems the spawn system is a higher priority currently anyway.

I'll have a look at modifying the existing function as you recommended- if I'm confident I can do it without breaking compatibility, I will- otherwise I'll leave it alone and handle the DM avatar case separately.

ç i p h é r · Post by **ç i p h é r** » Thu Mar 01, 2007 11:12 pm

Sounds good. BTW, I edited my post above for correctness. I realized I mixed my PCs with my Players in one spot.

AcadiusLost · Post by **AcadiusLost** » Fri Mar 02, 2007 8:42 am

Committed. As it turns out, I didn't need a different function to do what I was trying to do with regards to getting IsPlayerOrDMinArea. So, the only change is the minor one that fixes RandomFloat.

Once I remembered which password I used for my sourceforge account, it went very smoothly.

AcadiusLost · Post by **AcadiusLost** » Mon Mar 05, 2007 7:11 am

Got another commit for acr_tools_i ready, I think. Just need to clear out a few debug messages on it.

The GetIsIntegerInWindow(nNum, nStart, nEnd) function didn't seem to be behaving itself, so I wrote a new one that seems to function in the way that seems right to me. The trick of this one is to allow a "circular" window so you can do things like spawn in hour 20, spawn out at hour 7 (for a nightime spawn). The previous version worked fine for that case, but was misfiring sometimes in the normal "between 8 and 17" style cases.

Should have the commit up tonight before bed, got a few more things I'm hunting down, there may be the odd chance one will point back to something in acr_tools_i again.

AcadiusLost · Post by **AcadiusLost** » Mon Mar 05, 2007 5:43 pm

Just as well that I waited on the commit, noticed my RandomFloat() was only really producing values in the lower half of it's given range, so had to tweak it again. Not sure why Random(nInt) is having trouble generating numbers > 33,000, but it seems to be, for whatever reason.

Committing in a few min, changes to RandomFloat and GetIsIntegerInWindow.

ç i p h é r · Post by **ç i p h é r** » Mon Mar 05, 2007 5:47 pm

AcadiusLost wrote:The GetIsIntegerInWindow(nNum, nStart, nEnd) function didn't seem to be behaving itself, so I wrote a new one that seems to function in the way that seems right to me. The trick of this one is to allow a "circular" window so you can do things like spawn in hour 20, spawn out at hour 7 (for a nightime spawn). The previous version worked fine for that case, but was misfiring sometimes in the normal "between 8 and 17" style cases.

Would you say this was intended or unintended behavior? If the latter, then you should definitely fix the function rather than introduce a new one. Avoid creating duplicate functions with identical purpose; That'll just bloat the code and cause confusion.

Thanks.