1  |   Order by index

Aug 4, 2003, 11:48am

Is there a 'reserved' cit number that can be used to 'lock' objects using
a bot that we can count on never being used as a real cit number?

i.e. "1" is probably a good guess... but it *may* actually be used.

I'd like to ask for a 'reserved' cit number for the purposes of marking
objects as 'infrastructure' so that it will be easier to use bots to filter
things etc.

It would be like marking files as owned by 'root' in UNIX.

It would be nice if such items could not be deleted by anyone but the
world owner, but that anyone (even tourists if you enable them to build)
could build in cells that have items owned by 'root'. This would allow you
to make public areas that have infrastructure that can't be changed, but
that anyone can still build on.

I'd settle for just a reserved cit number though...

Aug 4, 2003, 12:41pm

Use a world cit, and no registry.

[View Quote]

Aug 4, 2003, 12:48pm

What do you mean a 'world' cit?

The main reason I want this is for using bots to filter things..
not for the purposes of restricting building.

I want a cit number that will *never* be a valid citizen.

If I use a cit number of someone who actually might build in
a world, then I cannot filter that persons objects using a bot.

I do this now using a cit number I don't *think* will ever be
used by anyone in my world, but I would like a sure thing.

[View Quote]

Aug 4, 2003, 2:30pm

[View Quote] I suppose you could use ED and place AWLD owned objects owned by citizen
number 1 all over the world. Of course, anyone with ED could delete it.

--
--Bowen--

No of SETI units returned: 62
Processing time: 51 days, 22 hours.
(Total hours: 1246)
www.setiathome.ssl.berkeley.edu

Aug 4, 2003, 9:35pm

Or choose a very high number like 888888.

[View Quote]

Aug 5, 2003, 3:06am

[View Quote] Yeah but there's a chance it'll be valid and they'll come rape your
world. AWLD can already do that, and no one but AWI can get on it.
Might as well give them some sort of legalized power.

--
--Bowen--

No of SETI units returned: 62
Processing time: 51 days, 22 hours.
(Total hours: 1246)
www.setiathome.ssl.berkeley.edu

Aug 5, 2003, 6:37am

ROFL..considering the current average of 300 new cits/month it will take 100 years to
get 360000 cits registered, 360000 + the current 354600 = 714600.
That's still far from 888888.

[View Quote]

Aug 6, 2003, 4:45am

If you made a bot that would not allow objects to be deleted from that
citizen number from the world you have in essence created root for your
builds. This could be done by having a spare citizen account, or your own
(the world owner) and building your "infrastructure" of the world. Unless
the person trying to delete the object that is of the infrastructure is the
correct citizen number, do not allow the object to be deleted; have the bot
re-build it in the same location.


DM

[View Quote]

Aug 6, 2003, 12:17pm

Some programmer once said... geez.. two digits is plenty to use
for the date.

Another programmer once said if I use the number of seconds since
Jan. 1 1970 as the time, it will be good forever. In 2038 we will find
out how long forever is.

And of course AW is just about to reveal their new marketing plan
and the number of cits a month registered will shoot up to 10,000

[View Quote]

Aug 6, 2003, 4:10pm

[View Quote] That wouldn't surprise me at all. It just wouldn't anymore.

--
--Bowen--

No of SETI units returned: 62
Processing time: 51 days, 22 hours.
(Total hours: 1246)
www.setiathome.ssl.berkeley.edu

Aug 7, 2003, 9:40am

"codewarrior" <pete at accelr8r.com> wrote in news:3f310dfa$1
at server1.Activeworlds.com:

> Some programmer once said... geez.. two digits is plenty to use
> for the date.
>
> Another programmer once said if I use the number of seconds since
> Jan. 1 1970 as the time, it will be good forever. In 2038 we will find
> out how long forever is.

It will be good forever. It just isn't forever with 32 bit integers, that's
all. There's a bunch of 64 bit systems out there now, mainly servers. Won't
be that long until most people are going to get them too. With 64 bit I
believe the UNIX timestamps will have a range beyond the remaining lifetime
of the sun. So don't worry :-))

KAH

Aug 7, 2003, 9:41am

[View Quote] Maybe I want to know when my sun goes super-nova now. ;)

--
--Bowen--

No of SETI units returned: 62
Processing time: 51 days, 22 hours.
(Total hours: 1246)
www.setiathome.ssl.berkeley.edu

Aug 7, 2003, 2:46pm

In 5 milliard years eh..

[View Quote]

Aug 7, 2003, 6:04pm

You're assuming that the little computer in the gas pump will be
replaced with a new one by then and that somone will actually
remember that it uses a 32 bit processor, or that it even has a
processor in it.

Servers are only one little tiny application for computers, and
embedded computers.. well.. they are *embedded* in things.
They don't get routinely swapped out, and they are not designed
to go obsolete in a year either.

It's likely that most embedded systems will have been replaced
by then, but who knows.

[View Quote]

Aug 7, 2003, 7:57pm

[View Quote] You don't pay gas with cash? That's a bad practice, using a credit of
sorts for gas. :P

--
--Bowen--

No of SETI units returned: 62
Processing time: 51 days, 22 hours.
(Total hours: 1246)
www.setiathome.ssl.berkeley.edu

Aug 7, 2003, 11:00pm

I didn't mention payment of any kind in my post.

> You don't pay gas with cash? That's a bad practice, using a credit of
> sorts for gas. :P

Aug 7, 2003, 11:02pm

[View Quote] Well, then computer chips keeping track of the date in a gas machine
have no purpose other than keeping time. What is the point of a 32 bit
chip in a gas station's pump?

--
--Bowen--

No of SETI units returned: 62
Processing time: 51 days, 22 hours.
(Total hours: 1246)
www.setiathome.ssl.berkeley.edu

Aug 8, 2003, 12:07am

A UNIX timestamp is a UNIX timestamp wether implemented on an
eight, 16, 32 or 64 bit computer.

And it is the same wether you pay by cash or by credit card.

You're an expert at missing the point.

[View Quote]

Aug 8, 2003, 12:44am

[View Quote] You've adequately evaded the purpose of my point. Why do you need a
timestamp in a Gas station pump for cash? Why, no, I'm not missing the
point, why do you need to record cash? You can't, it's just silly and
stupid to keep track of who's paying you by cash (and then timestamps
serve no purpose for cash payments which brings me back to my original
comment). I'm sure that certain someone(s) will chime in with the link
to pictures, of course.

You can't keep track of who's paying you by cash unless you have book
keeping skills that would shame the Roman publicani, anyways.

I need proof where a timestamp is useful for cash payments, that's all I
asked for originally and you've still yet to answer me. So, I'm going
to consider any retort, such as my "missing the points," as you having
no answer for me. But hey, your hostility to me wouldn't happen to have
to do with earlier comments -- I can beat a dead horse too.

--
--Bowen--

No of SETI units returned: 62
Processing time: 51 days, 22 hours.
(Total hours: 1246)
www.setiathome.ssl.berkeley.edu

Aug 8, 2003, 4:18am

I'm ignoring your point, not evading it.

You made it up to imply that I said anything about cash to begin
with. You have this notion that keeping track of anything having to
do with timestamps involves cash somehow and it's totally missing
the point.

And I don't post in the newsgroups to engage in long winded pointless
debates with you. Find someone else to annoy.

Aug 8, 2003, 4:41pm

[View Quote] You only ignore things you can't deal with. You just have no answer for
the fact why there'd be _any_ reason to have a timestamp in a gas pump.
Speculation has brought me to the reason that the gas stations you've
been to accept credit cards and the reason for the timestamp was to keep
track of the payments (and if you can no longer add seconds on a 16 bit
system it's going to think you're from 1900 or some weird date like that
and charge you insane late fees). So, back to my original point and
question, why would a gas station need a timestamp for pumping gas?

--
--Bowen--

No of SETI units returned: 62
Processing time: 51 days, 22 hours.
(Total hours: 1246)
www.setiathome.ssl.berkeley.edu

Aug 8, 2003, 6:24pm

*this* is your original *question*.

"You don't pay gas with cash? That's a bad practice, using a credit of
sorts for gas. :P"

It is *not* a question.. it is an insult... flame bait.

It is worth ignoring, even if you try to change it into a question after the
fact.

You may become a veteran newsgroup poster someday, but you
currently lack the subtlety and refinement in your posts needed to
disguise the bait properly. Work on your non-sequiturs.. they are way
too blatant.

Aug 8, 2003, 8:46pm

[View Quote] Smilies at the end of statements denote a joke.

--
--Bowen--

No of SETI units returned: 62
Processing time: 51 days, 22 hours.
(Total hours: 1246)
www.setiathome.ssl.berkeley.edu

Aug 9, 2003, 10:17am

"codewarrior" <pete at accelr8r.com> wrote in news:3f32b0db$1
at server1.Activeworlds.com:

> You're assuming that the little computer in the gas pump will be
> replaced with a new one by then and that somone will actually
> remember that it uses a 32 bit processor, or that it even has a
> processor in it.

Remember y2k? Everyone got quite aware of that date problem... Anyway, I
think it's *very* likely that the little computer in the gas pump is going
to get replaced (several times most likely) over a period of 35 years...

> Servers are only one little tiny application for computers, and
> embedded computers.. well.. they are *embedded* in things.
> They don't get routinely swapped out, and they are not designed
> to go obsolete in a year either.

I just gave the servers as an example, to show that the 64-bit platforms
are actually ready for mass-deployment.
Embedded systems aren't designed to go obsolete in a year, more like five
or ten years. 35 - 10 = 20. Whoops, looks like they'll go obsolete long
before y2k38.

> It's likely that most embedded systems will have been replaced
> by then, but who knows.

Yes, it is. Those that aren't replaced probably aren't that important.

KAH

1  |   Order by index