Jump to content

Fillo Farber

Resident
  • Content Count

    55
  • Joined

  • Last visited

Community Reputation

0 Neutral

About Fillo Farber

  • Rank
    Advanced Member
  1. I'm working on a script that requires a weighted number generator between 1 and 118. The attempts I've made have used llPow but do not produce a sharp enough distribution curve. I need something that allows me to plug in a final "weight" value at the far end of the curve such as specifing that the odds are 1000 times greater of the number 1 being generated then the number 118. llLog? Any suggestions? Any suggestions?
  2. I'll admit I am a bit a-nal (wow that got bleeped?) about making things as foolproof as possible. There's a bone in my head that makes me that way. I should probably get that taken out some time... Anyway I like the fake DNS idea. I looks like it is explained well in that link that Kaluura posted. Thanks a bunch for the great info folks!
  3. I need to make an update server to support a product I'm working on and I don't want to go through a website to do this. The obvious problem with rezzing a server in world that its UUID is subject to change by accident or other event. It seems reasonable to use a backup server that could send the products a new primary server UUID if required. I'm interested learning any methods some of you have used to provide a stable support server (without use of an external link). Also I was also considering Linden Lab's magic box hosting service as a secure location for the server. Has anyone ever inquir
  4. Yes I believe it was llSetStatus... I'll try that, thank you!
  5. It seems I saw a function some time ago that was used to keep an object at a fixed rotation during an llMoveTo. I don't remember what it was or how it was implemented - anyone got a clue what it was I might have seen?
  6. I guess my only option on this path is to append the info to the object name. I did get my base 64 compression working with 4 chars up to 10.00000 flawlessly btw. For some reason the lsl base 64 functions wouldn't give me nearly that kind of resolution - I had to make my own. The 4 chars don't include a sign so I'll have to add a 5th. Anyway, if I keep my object names short enough I can append a 35 char base 64 to them. A small revision to my compression script should make this possible. I can always fall back on llSetPos/Rot if I have to - I just don't like the delays for my purpose and I'll
  7. Today I'm working on a script that rezzes various objects relative to the rezzer pos and rot. Since there would be lots of different items to rez I didn't want to put all those vectors and rotations in my rezzer script. I wrote a couple snippets of code that calculate the rotations and positions to rez at then writes them in the description of the object to be rezzed. The problem is I can't find any way to read an inventory object's description with my rezzer script. Is there a way? If not, any suggestions other then use of notecards or llSetPos/Rot? Also, question regarding llGetInventoryKey:
  8. Doing some tests with the base 64 function. An output range of base 64 chars that is AAAAAA== to AA///w== represents integers 0 to 1048575 . Within that range I can strip the leading AA and trailing == to reduce them to 4 char representations of the inputs. Above 104875 we need 5 chars and so on. I can work within the range of 4 chars for my purpose. Unless there are some other issues, I should be able to store 254/4 floats in an object name and description combined, correct? Too bad about the base 256 issues because that would have been very compact. I really appreciate the help from both o
  9. "and not all the characters in that series are 1 byte " ewww, I didn't realize that... I was just working on casting to string as you mentioned which did work. I found another issue though - when we reach the number 98 we seem to hit a problem with that char in the char set. It doesn't pick it up for some reason. Yes, Kaluura's is workable but since that script is using the full 256 char set as well I'll have to reserve at least 2 bytes memory for each char. (also the issue as with the 99th char) Do you know of any issues using llIntegerToBase64?
  10. You said they have leading zeros and trailing digits. There are both? Can we strip those to format the reconstituted float to match original input value? I understand that this does not save memory. The purpose of this function is to store up to 85 floats in an object description - which is pretty cool
  11. Well I'm glad I found a challenge for you folks! I've come up with my own method which "appears" to work with floats as high as10 using 3 base256 chars with no loss. I was getting losses in the least significant digit so I manipulated that one as a string before converting to an integer. The weird thing is that when I added a comparison of the input vs output variables it reports that they are different although they seem to be identical. i.e. it is telling me that 0.000010 does not equal 0.000010 . Here's the script that includes the test routine. Excuse my kindergarten methodology but I fin
  12. * Update * Not sure if you read before this edit but here's an update: I'm finding errors still. The first two examples show that the 2nd function returns the same results for 00w & 00x, then in the next two examples the 1st function seems to put out just two chars at times. Hope this is enough info for you to spot the problem. I really appreciate your assistance... Thank you! Input = : 0.000031 Flt2Str Result = : 00w u256Str2Flt Result = : 0.000031 Input = : 0.000032 Flt2Str Result = : 00x u256Str2Flt Result = : 0.000031 Input = : 9.913982 Flt2Str Result = : ÜÝê u256Str2Flt Res
  13. Void Singer wrote: it isn't pretty but this should work for ranges 0.0-15.99999 string gStr256 = "0123456789abcdefghijklmnopqrstuvwxyz!\"#$%&'()*+™-./:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\\]^_`{|}~¡¢£¤¥¦§¨©ª«¬­®¯°±²³´µ¶·¸¹º»¼½¾¿ÀÁÂÃÄÅÆÇÈÉÊËÌÍÎÏÐÑÒÓÔÕÖ×ØÙÚÛÜÝÞßàáâãäåæçèéêëìíîïðñòóôõö÷øùúûüýþÿĀāĂ㥹ĆćĈĉĊċČčĎďĐđĒēĔĕĖėĘęĚěĜĝĞğĠġĢģĤĥĦħĨĩĪīĬĭĮįİıIJijĴĵĶķĸĹĺĻļĽľĿŀŁłŃńŅ"; string uFlt2Str256( float vIntFlt ){ integer vIntTmp; return llGetSubString( gStr256, vIntTmp = (integer)(vFltNum * 16), vIntTmp ) + llGetSubString( gStr256, vIntTmp = (integer)(vIntNum * 4096) & 255, vIntTmp ) + ll
  14. Kaluura, I can not get that script to work properly. I fixed one line to read "f -= (float)k;" as I assume that's what you intended. I put the base 256 char set in a notecard because it can't be read properly after compiled within the script. With these changes it appears to work with inputs up to 99.000000 then something goes wrong. Except for the integer portion of the input number, it appears that your script compression is limited to an output that represents a range of up to 99 per position - using only the first 99 chars of the 256 char set. (there's that number 99 again - hmm) Just gue
  15. Yes I want to compress the text and the only example I could find was this base 256 function. Thought I had it working but I found an error. What did you have in mind Void?
×
×
  • Create New...