1  |   Order by default

Sep 10, 1998, 1:28pm

With your design of using the aw_instance_set method it appears as
though your API is not thread safe. Is there a reason for this?

I would imagine that in a high volume world, with lots of bots, each bot
would start reacting slower to stimulus. You could not take advantage of
multi cpu hardware so there would be no hardware rampup available.

I am sure with small greeter bots this will not be a problem but when
you start getting into your conversation bots that apply some AI
technology to make the conversation seem real you are going to see a
long delay in each event function. During this time all other bots are
lifeless, a kind of temporary bot death I guess.

An alternate design would be to pass the instance handle to each
function so that context can be managed appropriately by the API and
each event function gets passed the bots context from which it gets the
relevent bot information.

Edward Sumerfield, esumerfd at poboxes.com
http://members.xoom.com/esumerfd

Sep 11, 1998, 4:37pm

I like the Java idea but I fear it is a great deal more difficult that you are
assuming.

Certainly we can encapsulate C function calls into Java methods but you will
stumble on the aw_wait function because it is supposed to call your java methods
and it will not be able to.

One thing you might be able to do is use the sdk to write a generic server that
would export the sdk to a socket interface. Then you can write java clients to
drive it.

Each java thread would have to talk to a different generic server to get around
the threading problem. Unless you want to build a single generic server that
serialized all parallel requests to a single aw sdk thread, you know, queued up
the requests and processed them one at a time.

It would be quite a lot of work to correctly model the AW interface but once that
was done it shouldn't take long to implement the client side.

You know, the more I write, the more interesting this sounds. Wait, it will not
work, because the sdk took control of the "select" function in the aw_wait
function we couldn't even trap our own socket events.

It would be really cool to implement a few interfaces to get all the events that
are generated. Instantiate an Avatar class with a login name and priv password to
login. Call its enterWorld method to send it somewhere. Then instantiate a sign
object and call its setText method. Pass the sign object to the avatar so it can
write messages on it. That would require a standard AwTextIF for the Avatar class
to implement. Am I getting carried away yet. OO rocks. Especially Javas' interface
models.

I think I am dreaming too much. Sorry if I wasted your time.

Edward Sumerfield, esumerfd at poboxes.com
http://members.xoom.com/esumerfd

[View Quote] > Hello,
>
> I personally considere multithreading very important.
>
> For the reasons mentioned by esumerfd.
>
> In particular, multithreading would be very important if we want
> to try to interface the SDK with java.
> (which appear to me as a better language for developing bots because
> of the multithreading, the garbage collection, etc.).
>
> Note: Encapsulation of the SDK into java shouldn't be too difficult.
> Anyone interested by the idea ?
>
> Thierry Nabeth
> Research Fellow,
> INSEAD CALT (the Centre for Advanced Learning Technologies).
> http://www.insead.fr/CALT/
>
> PS:
> Any plan to have a java version of the SDK ?
>
[View Quote]

Sep 11, 1998, 6:57pm

[View Quote] > will
> methods
>
> Is it not possible at all to have C code call Java routines? Not even in
> some kludgey way? Sorry I'm not that familiar with the details of
> interfacing Java and C.
>
> If not, it may turn out that a native Java implementation of the SDK is the
> only viable long-term solution for Java developers...
>

Your problem is that you are not calling a java method, instead what you really
have to do is call the java interpreter and tell it to go run the appropriate
method. I have never done this so I can say that it is impossible.

I imagine the issues of managing context across multiple calls to a jam are
substantial. It would have to have a way to reenter the same jam multiple times.
Its time to post a question to comp.lang.java.programming.

> not
>
> Just because aw_wait() calls select() on its sockets doesn't mean that your
> code couldn't also call select() on your socket, right? Or am I missing
> something. Also, if you call aw_wait (0) it doesn't call select() at all,
> it just checks each instance's sockets individually for incoming traffic.
> This is to work around some nasty performance problems I've encountered with
> the Windows select() call under certain versions of Winsock.

In a single threaded world you can only have one call to "select" at a time
because it is a blocking call that waits for a list of events. If some boot code
also called select with a different list of events the then it would block there
and you could not receive AU events.

In a perfect request, response world on a single socket you can use two selects
because you know whether you are about to receive a request or a response, but
with multiple sockets and the AU protocol has a number of unsolicited messages
that are sent to the client, it is not going to work. Note that I am making some
assumptions here based on my knowledge of the AU browser protocol. I assume you
haven't re-engineered this too much.

You said you are not calling select. The alternative is read poll the sockets
with a very short, or zero time out. This is very inefficient especially in a
system requiring short response times because the polling interval has to be so
short to guarantee the short response time.

Maybe I am missing something. Do you see continuous of frequent CPU usage from
the boot processes?

In my unix (AIX) background I seem to remember an alternative to select called
"poll". It performed the same functionality but was a great deal more efficient.
I think it was POSIX compliant but I have no clue if this is relevant in a
windows world.

I am still in theory mode here. Its time I found a C compiler and started
implementing the sdk. I imagine the GNU compiler will work wont it?

>
>
>
> -Roland
>

Edward Sumerfield, esumerfd at poboxes.com
http://members.xoom.com/esumerfd

Sep 11, 1998, 7:14pm

[View Quote] >
> But not required. If a Java class were created to encapsualate the current
> SDK, the SDK wrapper methods could just be declared as synchronized. If the
> SDK is used in asynchronous mode (i.e. with callbacks installed) all SDK
> methods return immediately so opportunities for one thread to block others
> while in the SDK would be minimal
>

This isn't exactly true because it is the callback functions that must be
synchronied not the aw functions. Your problem is that you are protecting the
time from when a bot calls aw_instance_set and the next time that function is
called. I know you have a global in there, called aw_current_bot of something,
just waiting to be changed by another thread.

It is possible for a bot to trap an event, call aw_instance_set and then spend
lots of time saying things, changing objects, yadda yadda yadda, and no other
thread can get a look in just in case they call aw_instance_set as well.

With this architecture a good bot architect will have to implement a state
machine to track what has been said so that each time an event goes off it can
say the next thing. Though without a user event machanism this isn't going to
work either.

I should have written this in my last reponse but there is a solution to the
"waiting on AW sockets and user sockets" problem and it will allow the creation
of state machine driven bots. You must write an aw_add_event(event, function)
function that a bot can use to pass their own events to your sdk. Then you can
just wait on all of them and call the appropriate function when they are
notified.

>
>
>
> -Roland
>

Edward Sumerfield, esumerfd at poboxes.com
http://members.xoom.com/esumerfd

Sep 14, 1998, 1:10pm

Well, it appears that I was wrong. There is a way to call java methods from
a native function

http://java.sun.com/products/jdk/1.2/docs/guide/jni/spec/design.doc.html and
look at the "Access Fields and Methods" section.

So to implement the wrapper we will need to go through the following
development steps.

1. Create AW.java with method wrappers that call all the aw C functions.
2. Create AWCallBack.c with handler functions that are called by aw_wait
and intern call java methods. One of these functions must be
aw_set_callback_object( Java object ). It sets up a global object that
contains the java callback methods.
3. Create AWCallBacks.java as a standard store for all the events objects
that need to get notified. Of coarse all the callbacks are implemented as
interface to allow flexability of implementation for the developer.

So the pseudo code might look something like this:

Java:

// AW wrapper class.
class AW {
// Simple C function wrapper.
aw_init(){ call aw_init C funtion }
aw_create() { call aw_create C function }
aw_wait() { call aw_wait C function }
and so on.

set_callback_object( awcb ) {
// assign the global java callback object in the C callback
wrapper
aw_set_callback_object( awcb );
}
}

class myBotProgram {
public static void main(String args[]) {

AW aw = new AW();

aw.init()

AWCallBacks awcb = new AWCallBacks();
awcb.setAvatarAdd( new myAvatarAdd() );
awcb.setAvatarChange( new myAvatarChange() );

aw.set_callback_object( awcb );

aw.create(...)
aw.login(...)
aw.enter(...)

aw.wait()

aw.destroy(...)
aw.term(...)
}

class AWCallBacks() {

AvatarAddIF avatar_add;
AvatarChangeIF avatar_change;
AvatarDeleteIF avatar_delete;

setAvatarAdd( AvatarAddIF avatar ) {

this.avatar_add = avatar_add;
}

setAvatarChaneg and so on.
}

interface AvatarAddIF {
void AvatarAdd();
}

class myAvatarAdd implements AvatarAddIF, AvatarChangeIF ... as
necessary {

void avatarAdd() {
// do something
}

void avatarChange() {
// do something
}
}

C:

global java object;
void aw_set_callback_object( java object ) {
object = java object;
aw_event_set ( AW_EVENT_AVATAR_ADD, callback_avatar_add);
aw_event_set ( AW_EVENT_AVATAR_CHANGE, callback_avatar_change);
aw_event_set ( AW_EVENT_AVATAR_DELETE, callback_avatar_delete);
}

void callback_avatar_add(void) {
// Call the java method via the global object and the interface
pointer.
java object -> avatar_add -> AvatarAdd();
}

Edward Sumerfield, esumerfd at poboxes.com

[View Quote]




> Hello,
>
> I prefer to start a new thread to address this question about
> interfacing
> SDK and Java.
>
> However, this message is an answer to a previous message
> "Re: multithreaded would be usefull if we want to interface it with
> java"
>
> language you
>
> I do not fully agree with you, even if when there is some equivalence
> beteween different languages, you can do with another language
> all you you can do with another one.
> For me a "better" language will allow you to implement an idea more
> easily
> than with a bad one. (I do not want here to enter into a debate about
> which
> are the language that are good, and which are the language that are
> bad).
> Practically, a "good" language will allow you to represent the system in
> a
> way that reflect in a high level way your ideas, and does not impose you
>
> to enter into (irrelevant) details.
>
> For instance, if multi-threading is not mandatory, on the other hand, it
> can
> make the implementation of different objects having concurent activities
>
> (such as bots) much easier.
> The difference will be reflected by the complexity of the architecture,
> and
> therefore its capacity to evolve before becoming a maintenance
> nightmare.
>
> Anyway I did not post this message to open a "religious" debate, but to
> contribute
> to the following:
>
> into
> Active Words, several people almost immediately offered to implement a
> Java
> wrapper.
>
> I personnaly do not have the time right now to do this wrapping.
> (when I will have more time, I will see if I can do something).
> Besides, I do not have right now a C compiler.
>
> On the other hand, I had the time to look a little bit at the difficulty
>
> to do this wrapping, and my first impression is that it should really
> not be too complicate to do for a programmer having already use JNI
> (Java Native Interface).
>
> The main documentation of Jana Native Interface can be found at:
> http://java.sun.com/products/jdk/1.2/docs/guide/jni/index.html
>
> Here is the idea:
> ----------------------------
> The idea of JNI is to create a Java class with some function are tag
> as Native.
> such as:
> public native void myNativeFunction(Object[] args);
>
> Once the *.java file is compiled (javac), you have to run javah
> (http://java.sun.com/products/jdk/1.1/docs/tooldocs/win32/javah.html)
> on the *.class file to generate C stub.
>
> You then implement the C functions (in the case of AW SDK you call the
> API),
> compile them, and create a dll.
> ------------------------------
>
> Another possiblility that could appear to be even easier to implement,
> is to use the Shared Stubs Example.
> http://java.sun.com/products/jdk/faq/jnifaq.html
>
> The idea in this example is to generate dynamically the function
> that call the C-code.
> ----- example: call of the sin() function in java ----
> /* Caculate C's sin(2.0) with Math.sin(2.0). */
> CFunc sin = new CFunc(libm, "sin");
> double dres = sin.callDouble(new Object[]{new Double(2.0) });
> System.out.println("\nC's sin(2.0) = " + dres);
> System.out.println("Math.sin(2.0) = " + Math.sin(2.0));
> ----------------------
> This code is extracted from the example. (jnistb10.zip )
>
> Note:
> You still need to do a little bit of compilation to use this approach,
> but you do not need to wrap all the functions as in the previous
> approach.
>
> Well,
>
> That is all for now.
> (I have to work for the next 2 weeks on a more urgent project).
>
> I have not tried to answer the issues raised by esumerfd.
> Perhaps, the wrapping will not work, but the better is to
> try to do it, and solve the problem later.
>
> I hope that a future release of the library will be reentrant,
> since I still believe this is something very important (even if not
> mandatory).
>
> I also hope that in a not too far future, a complete java version will
> be created.
> (let me dream a little bit).
> Indeed, the advantage of a complete java version would be plateform
> independance
> and for instance the possibility to run some bots on a Unix or Linux
> computer.
>
> Bye,
>
> Thierry Nabeth (calt exec)
> Research Fellow,
> INSEAD CALT (the Centre for Advanced Learning Technologies)
> http://www.insead.fr/CALT/
>
> =====================================================
> Subject:
> Re: multithreaded would be usefull if we want to interface it with java
> Date: Fri, 11 Sep 1998 11:50:46 -0700
> From: "Roland Vilett" <roland at lmi.net>
> Newsgroups: sdk
> References: 1 , 2 , 3
>
>
> But not required. If a Java class were created to encapsualate the
> current
> SDK, the SDK wrapper methods could just be declared as synchronized. If
> the
> SDK is used in asynchronous mode (i.e. with callbacks installed) all SDK
>
> methods return immediately so opportunities for one thread to block
> others
> while in the SDK would be minimal
>
>
> I think the "better" language for bot development is whatever language
> you
> the programmer happen to be comfortable and familiar with.
>
>
> A couple of months ago when we first announced work on a C-level API
> into
> Active Words, several people almost immediately offered to implement a
> Java
> wrapper. I don't remember who they were though - are you guys still
> around,
> and if so, are you still interested? :)
>
> -Roland
>
>
>
>
>
>

Sep 15, 1998, 6:40pm

Go to win.files.com and get a product called WebDown. Point it at the sdk
web page and it will download everything you want translating the links
appropriately for local access. This is freeware.

[View Quote] > Roland:
> Will we be able to have some downloadable version of the AW SDK
> documentation?
> Maybe a Word document, text file, or simply the compressed version of
> the current pages, ready for download and read them offline.
>

Sep 16, 1998, 3:36pm

FYI, the GNU C compiler (GCC) requires a different object format to the
aw.lib so can not be used.

Roland, would it be possible to create a version of the the lib with
this compiler so that we poor people can use it. The best place to get
it is http://www.delorie.com/djgpp/ . The windows package is called
djgpp.

Edward Sumerfield, esumerfd at poboxes.com

Sep 23, 1998, 3:07pm

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML>
Thank you I will give it a try.
<P>Edward Sumerfield.
[View Quote]

Sep 30, 1998, 8:02pm

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML>
Sounds great Roland. I could use it in my next project if you hurry. Ha
Ha.
<P>My next goal was to wrap the sdk in a C++ wrapper and try to extrapolate
some class from it. I am not quite sure how to break it down yet.
<P>My first thoughts came up with the following classes:
<P>o&nbsp;&nbsp;&nbsp; ActiveWorld
<P>&nbsp;&nbsp;&nbsp; Static class responsible for concept wide information.
Will do the aw_init and contain any constants that may be necesssary.
<P>o&nbsp;&nbsp;&nbsp; Universe
<P>&nbsp;&nbsp;&nbsp; Responsible for aw_login.
<P>o&nbsp;&nbsp;&nbsp; World
<P>&nbsp;&nbsp;&nbsp; Responsible for aw_enter
<P>o&nbsp;&nbsp;&nbsp; Citizen
<P>&nbsp;&nbsp;&nbsp; To encapsulate all information necessary to define
a user.
<P>o&nbsp;&nbsp;&nbsp; Robot
<P>&nbsp;&nbsp;&nbsp; Responsible for defining a bot. Will use the aw_create,
aw_say, aw_int_set (???) and aw_string_set(???) functions necessary to
set bot position, avatar, etc.
<P>Well very rough ideas at the moment. I am thinking that you could end
up with a program that looks like this.
<P>&nbsp;&nbsp;&nbsp; ActiveWorlds.init();
<BR>&nbsp;&nbsp;&nbsp; Universe u = new Universe();
<BR>&nbsp;&nbsp;&nbsp; Citizen c = new Citizen(user id, priv password);
<BR>&nbsp;&nbsp;&nbsp; u.login(c);
<P>&nbsp;&nbsp;&nbsp; World w = new World("Beta");
<BR>&nbsp;&nbsp;&nbsp; Robot r = new Robot("Name", "Application name");
<BR>&nbsp;&nbsp;&nbsp; r.setPosition(xN, yW, zA);
<BR>&nbsp;&nbsp;&nbsp; w.enter(r);
<BR>&nbsp;&nbsp;&nbsp; r.say("Hello World");
<P>One of the nicest paybacks for doing this is not having to keep track
of the robot instance. the Robot class will keep track of that for me and
set it every time a method is called.
<P>The callback interface is going to be interesting. Much rarther do it
in Java but any way C++ does have abstract functions so I am thinking of
a single abstract callback class that will force the programmer to inherit
each function from it and implement whatever is needed.
<P>I am not planning on putting in the semaphors to make it thread safe
in this phase. Maybe down the road.
<P>Edward Sumerfield.
[View Quote]

Oct 1, 1998, 8:55pm

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML>
[View Quote]

Sep 21, 1998, 11:51am

You don't need windows unless you want to make the interface pretty. A command
line interface, like the dos prompt, is possible with a console app and is much
easier to implement if you haven't done much programming.

Your problem is the architectural design of the sdk. It is event driven so while
your program is in aw_wait it is waiting for a message from the server. It is not
able to wait for a keystroke at the same time.

An extension needs to be made to the sdk for adding user events (Roland?), such as
keyboard events. For example, aw_add_event(int, function); This would cause the aw
sdk to wait on your event as well as its own and call your function when it is
fired.

In the mean time you can use polling but it is not ideal. For example call
aw_wait(10) so it will wait for 10 milliseconds for an sdk event to occur then
drop back into your program. Then in your console app you can use the standard C
function gets() which would allow you to enter a string and press enter. You can
then do what you like based on the command entered.

The problem is that this is a blocking call. Once you have called gets it will not
return to your program until you press enter. While it is waiting for you, your
avatar will not be able to react to events.

If you want to get into some more serious programing them you can design a
multi-threaded solution which would be a little more realistic. Bare in mind that
the aw sdk is not thread safe so do not allow two different threads to call the
same api.

The design would involve one thread being dedicated to calling the aw functions
and a second thread being dedicated to accepting input from the keyboard. There
would be one common command buffer that both threads read and a lock to protect
that buffer.

So your program would start up and kick off a seperate thread to do all the aw
init, start, enter and wait(10) stuff while the first thread blocked on the gets()
function. Now the aw thread would be able to continue running even though the
gets() was blocked because it is running in a seperate thread.

In the aw thread, each time the aw_wait drops out it would check the command lock,
if it is unlocked then it would lock it, check the command buffer and act on what
ever it found before unlocking the lock.

In the gets thread, each time the enter key is pressed the lock is checked, if
unlocked then it must be locked and the new command copied into the shared command
buffer, before the lock is unlocked again.

This is a polling solution so is not as cpu efficient as the sdk change but would
work.

Good luck everyone.

Edward Sumerfield, esumerfd at poboxes.com

[View Quote] > Ive seen it done. im guessing you do it somewhere in "while (!aw_wait (-1))
> !newline! ;", but i cant get it to work
>
[View Quote]

Sep 21, 1998, 1:53pm

I am not going to be able to answer you in specific terms just yet. I don't have a C
compiler that conforms to the aw.lib object format.

It will be a while before I get a chance to do the programming myself. Find a book that
teaches you about writing threading programs and how to use locks, sometimes called
semephors.

[View Quote] [View Quote]

Sep 21, 1998, 8:16pm

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML>
That is true enough Roland. Still a polling architecture but simpler than
writing threaded apps.
<P>So, you haven't commented on the idea of adding a aw_add_event(int ,
function) funtion to the sdk yet?
<P>You mentioned in the thread about the GNU compiler that your preference
is to port to Sun/Unix machines before GNU because of your belief that
high performance bots will run on that type of machine. If performance
is important to you then why is it that you are not addressing this inefficient
polling architecture?
<P>I would even go as far as saying that a threaded API is much high priority
than having to worry about porting high powered servers.
<P>What is the reletive hardware mix of your customers at the moment? Windows/Unix/Linix?
What percentage of each would you say?
<P>Edward Sumerfield
[View Quote]

Sep 22, 1998, 2:11pm

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML>
<BODY BGCOLOR="#FFFFFF">
My apologies Roland, I must have seemed too pushy. I am a 12 year veteran
in the computer consulting field and understand totally what you are going
though. We customers can be very annoying at times. Especially what we
think we know what we are talking about. You are doing an excellent job.
Don't let us get to you.
<P>You are making the right move in solidifying the release you have and
when I get a darn C compiler I can use I will be right in there with you
trying to use your API.
<P>I would like to think that the comments we are making will contribute
to the next version of the API and so I would like to continue these conversations
if you have the time.
<P>Let me explain a little more about aw_add_event().
<P>Currently your code calls the socket() and connect() functions to create
connections to the universe and world servers. The socket call returns
file descriptors that you are adding to an array of file descriptors for
passing to the select() call. Each time data becomes available on one of
these file descriptors the select statement drops out and your code checks
the file descriptor returned to see if the event came from the universe
connection or the world connection.
<P>&nbsp;&nbsp;&nbsp; socket()
<BR>&nbsp;&nbsp;&nbsp; connect( universe )
<BR>&nbsp;&nbsp;&nbsp; socket()
<BR>&nbsp;&nbsp;&nbsp; connect( world )
<P>&nbsp;&nbsp;&nbsp; array = { universe, world }
<P>&nbsp;&nbsp;&nbsp; while (1) {
<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; event = select (array)
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; if (event = universe) {
<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Read
data from universe file descriptor
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; }
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; else {
<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Read
data from the world file descriptor
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; }
<BR>&nbsp;&nbsp;&nbsp; }
<P>OK, now we have a requirement to allow user applications to create their
own files, sockets or timers and they have to have a way to use your select
statement to do it.
<P>You can create the following function
<P>&nbsp;&nbsp;&nbsp; aw_add_event (file descriptor, function pointer)
{
<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; append file descriptor to
end of array.
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; store function pointer into
another array indexed by the file descriptor.
<BR>&nbsp;&nbsp;&nbsp; }
<P>Now change your select function as follows:
<P>&nbsp;&nbsp;&nbsp; array = { universe, world }
<P>&nbsp;&nbsp;&nbsp; while (1) {
<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; event = select (array)
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; if (event = universe) {
<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Read
data from universe file descriptor
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; }
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; else if (event == world)
{
<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Read
data from the world file descriptor
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; }
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; else {
<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; look
up function pointer using file descriptor
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
call users function;
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; }
<BR>&nbsp;&nbsp;&nbsp; }
<P>Now you have a way for the application to add its own file descriptors
to your sdks select loop. Applications can now implement their own timer
based bot functions, dynamically receive weather information from a weather
server and have their bots tell people, read random quotes from a file.
All without impacting the performance of the application. Also, when bots
get more sophisticated they will not be needlessly chewing up CPU time
while polling the event queue, instead, your thousands of deer grazing
in a distant meadow will only use CPU time when they need to be moving.
<P>I have writing a number of there types of applications before and would
be happy to add my experience to future developments. Please don't hesitate
to ask.
<P>Edward Sumerfield,
<BR>Pesky user.
[View Quote] </BODY>
</HTML>

Oct 8, 1998, 10:05am

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML>
NG = News group.
[View Quote]

Oct 8, 1998, 10:18am

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML>
Tell me more about your development environment. When IDE/C compiler are
you using. can you post your Makefile.
<P>Some theory for you.
<P>Source file called aa.c
<P>int aa() {
<BR>&nbsp;&nbsp;&nbsp; printf("In aa function.\n");
<BR>}
<P>Source file called main.c
<P>int aa();
<BR>main() {
<BR>&nbsp;&nbsp;&nbsp; aa();
<BR>}
<P>When you compile you will get main.obj and aa.obj. When you link you
can get main.exe for example.
<P>However, if I linked main.obj without specifying aa.obj I would get
<P>main.obj : error LNK2001: unresolved external symbol aa
<P>The next step is libraries. I can store the aa.obj in a library using
"ar ru aa.lib aa.obj" (unix command). Now when I link I will specify main.obj
and aa.lib. The linker is clever enough to open up .lib files and look
inside to find obj files.
<P>The functions that are failing to link are all stored in the aw.lib
file. So I am assuming that are are not specifying this library when you
link.<BR>
<BR>
<BR>My only confusion is that you still have the __imp__ prefix to the
funcitons. This prefix is usually due to C++ name mangling. This is the
process of taking a function name and attaching a prefix that encodes the
types of the arguments that it is passed. This allows C++ to do function
overloading. You should not be doing this in your C code.
<P>If you are using a C++ compiler maybe it is thinking that this is C++.
You can add code to tell the compiler the type of "linkage spec" to follow.
For example,
<P>extern "C" {
<P>&nbsp;&nbsp;&nbsp; int aa() {
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; printf("In aa function.\n");
<BR>&nbsp;&nbsp;&nbsp; }
<BR>}
<P>With the extern "C" around the function a C++ compiler will not mangle
the function name. So I guess you could add this around your code but there
is probably a simpler way. This notation is in the standard header files.
Say I assume you are including &lt;stdio.h> and not &lt;iostream.h>? That
would certainly make a difference.
<P>Edward Sumerfield
[View Quote]

Oct 8, 1998, 5:19pm

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML>
Lets say that I have my field full of deer. You remember the idea, 50 deer's
wandering around a field, grazing, walking and running away from approaching
people.
<P>All these deer will be driven by the same program but there is no way
for a program to know which deer noticed the approaching person first.
<P>The aw_event_set(AW_EVENT_AVATAR_ADD, function); allows me to set a
function to be called if an avatar approaches the bot within some distance.
The function called is not passed any arguments to indicate which bot noticed
the approaching avatar.
<P>There should probably be a "void *instance" parameter passed to the
function to indicate this.
<P>It will not look good for all my deer to run away at the same time.
<P>Edward Sumerfield.</HTML>

Nov 9, 1998, 11:03am

An interesting concept, not your dead body, but the idea of making money non financial. I
guess I would have to ask why because I can't see any in-world stuff that I would want to
purchase with it. Unless you wanted to start a poker league maybe.

Edward Sumerfield

[View Quote] > OVER MY DEAD BODY!! I WAS TALKING ABOUT VIRTUAL MONEY, NOT REAL MONEY!! THAT WOULD RUIN
> ACTIVEWORLDS!!
>
[View Quote]

Nov 9, 1998, 11:03am

An interesting concept, not your dead body, but the idea of making money non financial. I
guess I would have to ask why because I can't see any in-world stuff that I would want to
purchase with it. Unless you wanted to start a poker league maybe.

Edward Sumerfield

[View Quote] > OVER MY DEAD BODY!! I WAS TALKING ABOUT VIRTUAL MONEY, NOT REAL MONEY!! THAT WOULD RUIN
> ACTIVEWORLDS!!
>
[View Quote]

1  |   Order by default