Welcome to the Second Life Forums Archive

These forums are CLOSED. Please visit the new forums HERE

how do I get llgetunixtime to update?

Kurzweil Sleeper
Registered User
Join date: 4 Jan 2006
Posts: 12
03-12-2007 21:43
I want an object to give me the epoch seconds whenever I touch it, but llGetUnixTime responds with the same figure (apprently the time of rez of the object) instead of the time I touch it. I've tried llResetScript at the bottom of my touch event, but nothing seems to get llUnixTime to run on touch?


help?
Jillian Callahan
Rotary-winged Neko Girl
Join date: 24 Jun 2004
Posts: 3,766
03-12-2007 23:09
Lets see the code? My experiment worked fine, the number updating every second:

CODE
default
{
touch_start(integer total_number)
{
llSay(0, (string)llGetUnixTime());
}
}
_____________________
Kurzweil Sleeper
Registered User
Join date: 4 Jan 2006
Posts: 12
here's my code
03-13-2007 07:18
touch_start(integer total_number)
{
float positionx;
float positiony;
float positionz;
positionx = 125 + 45*llSin(llGetUnixTime());
positiony = 125 + 45*llCos(llGetUnixTime());
positionz = 10;
llSay (0, (string)positiony);
llResetScript();
}


and I tried simplifying the positiony = line to 'positiony = llGetUnixTime'.

but now matter how long I wait, it gives me the same epoch second.
Kurzweil Sleeper
Registered User
Join date: 4 Jan 2006
Posts: 12
here's my code
03-13-2007 07:19
touch_start(integer total_number)
{
float positionx;
float positiony;
float positionz;
positionx = 125 + 45*llSin(llGetUnixTime());
positiony = 125 + 45*llCos(llGetUnixTime());
positionz = 10;
llSay (0, (string)positiony);
llResetScript();
}


and I tried simplifying the positiony = line to 'positiony = llGetUnixTime'.

but now matter how long I wait, it gives me the same epoch second.

ps- how do I make the great little code blocks in these posts? I'm such a noob.
Jillian Callahan
Rotary-winged Neko Girl
Join date: 24 Jun 2004
Posts: 3,766
03-13-2007 17:54
Seems you've uncoverd a bug in LSL.

Its the conversion to a float that seems to be the crux here. Even if I store the value in an integer, then convert that into a float, it gets stuck!


Try this out to see this really bizzare behavior:

CODE
default
{
state_entry()
{
llSetTimerEvent(1.0);
}

timer()
{
integer timeInt = llGetUnixTime();
float timeFloat = (float)timeInt;
llOwnerSay("Integer: " + (string)timeInt + " - Float: " + (string)timeFloat);
}
}
(To do these colored code blocks, just surround the code with [ PHP][ /PHP] without the spaces I put in there to keep the board from interpreting them.)

EDIT:
Ok, just realised the size of the int llGetUnixTime() returns... Try subtracting 1173000000 from the time stamp to get a more useful number that will convert to a float.
_____________________
Sindy Tsure
Will script for shoes
Join date: 18 Sep 2006
Posts: 4,103
03-13-2007 19:58
Maybe...
CODE

float seconds = (float)(llGetUnixTime() % 60);

...would do the trick?
Jillian Callahan
Rotary-winged Neko Girl
Join date: 24 Jun 2004
Posts: 3,766
03-13-2007 20:43
From: Sindy Tsure
Maybe...
CODE

float seconds = (float)(llGetUnixTime() % 60);

...would do the trick?
Would =^.^=
_____________________
Newgate Ludd
Out of Chesse Error
Join date: 8 Apr 2005
Posts: 2,103
03-14-2007 02:29
llGetUnixTimeStamp returns the number of seconds elapsed since 00:00 hours, Jan 1, 1970 (year dot as far as computers are concerned.)

Subtracting 1173000000 brings it back up to 2003/2004 ( I cant be bothered to do the exact maths)
Kurzweil Sleeper
Registered User
Join date: 4 Jan 2006
Posts: 12
03-14-2007 07:36
so it seems it's just a float out-of-range type of thing? that's total poo.

thanks for the %60 tip, I think that'll work- I really liked llGetUnixTime straight up because it's a counting number with no roll over (until 2036 or whenever that is {thank you John Titor!}). I'm gonna have to read up more on quaterions to make a variable based on a sin function.

thank you guys oh so much for the feedback!

CODE

/me has got to make it work now
Sindy Tsure
Will script for shoes
Join date: 18 Sep 2006
Posts: 4,103
03-14-2007 08:02
From: Kurzweil Sleeper
so it seems it's just a float out-of-range type of thing? that's total poo.

Not quite out of range.. Floats get less percise as the number they store gets bigger and bigger. Don't ask me why - some big brain like Newgy can probably explain it if you're nice to him (or there's probably lots of forum posts about it if you search).
Newgate Ludd
Out of Chesse Error
Join date: 8 Apr 2005
Posts: 2,103
03-14-2007 12:23
From: Sindy Tsure
Not quite out of range.. Floats get less percise as the number they store gets bigger and bigger. Don't ask me why - some big brain like Newgy can probably explain it if you're nice to him (or there's probably lots of forum posts about it if you search).



Some one call?
Rather than try and rehash it heres what the wikki has to say:

From: Wikki
A 32-bit float is divided into a 24-bit signed "mantissa" (containing the actual significant digits) and an 8-bit signed "exponent" (representing the magnitude that the mantissa will be multiplied with). A 23-bit (1 bit lost for sign) mantissa gives a precision equivalent to approximately 7 decimal digits (more exactly log10(223)). This means values are rarely exactly stored and, often more disturbingly, addition or subtraction of two numbers of vastly different magnitudes might yield unexpected results, as the mantissa can't hold all the significant digits.

As per IEEE-754, LSL supports negative zero, there is currently no way of detecting negative zero, except by typecasting to a string.

Example:
340000000.0 + 4.0 = 340000000.0
The correct answer (340000004.0) has 9 significant digits, thus the last two digits are lost.