1  |   Order by index

Dec 7, 2003, 12:29pm

Hi,
I want to know what is the language in the sdk who has a lot of functions
plz ???

Java, C++ or VB ?

Thanks,
iNsAnE aXeL

Dec 7, 2003, 12:36pm

Erm... they all have the same...

I suppose VB has things like Long2IP and such... but then again C++ has the
proper stuff.

- MR

[View Quote]

Dec 7, 2003, 1:43pm

ya, and everything uses the c++ sdk, so impossible for there to be anything
the VB and java sdk can do, that the c++ one cant.

-SWE

[View Quote]

Dec 7, 2003, 1:58pm

All in all, if your going to be making little bots that do things like seed,
or respond to simple commands then you are looking at something like VB /
Java as your best choise.

However, if you are developing massive 2 or 3MB bots using complex API,
winsock for things like reverse DNS etc, C++ is your best bet, the others
can do em, but you run around the houses, and you don't get the ub3r benefit
of pointers.

- MR

[View Quote]

Dec 7, 2003, 3:30pm

Not true at all.

Writing a wrapper allows you to create new functions using the basic API
in the main SDK, so it's quite possible for there to be a lot of extra
functionality in them.

I don't know if there actually is anything extra in any of the wrappers
available, but it's certainly possible for there to be.

Using a third party wrapper though means that you will probably have to
wait until some time after a new release from AWI before the new features
become available in the particular wrapper you've chosen.

Given that AWI's beta's or alpha's or whatever are by invitation only,
I would be leery using anyones wrapper since there is no guarantee
they will be able to keep it up to date with whatever AWI is doing
with the core SDK.

Stick with the official AWI SDK, or risk everything you do breaking
on you one day with no warning.

[View Quote]

Dec 7, 2003, 3:31pm

I am agree with you but how to write a wrapper ?

Dec 7, 2003, 6:47pm

If you really need to write a wrapper, you will know what it needs to do.

Just use the AW SDK you get from AW in C++ to start out.

Cut and paste the code from their SDK docs and try it.. it works fine
usually.

If you run into trouble, you can ask about stuff here, and many people will
probably be able to help. If you use someone elses wrapper, then you are
limiting the number of people who might be able to help you out.

I'm not suggesting that any of the wrapper libraries anyone has written
are not worth using. If you are just starting out though, you should
probably
play around with the standard SDK for a little while so that at least you
know
why you might want to use another language.

[View Quote]

Dec 8, 2003, 5:49pm

[View Quote] True, however considering your writing it anyway... you might as well use
the C DLL..

> I don't know if there actually is anything extra in any of the wrappers
> available, but it's certainly possible for there to be.

Yes, mostly some conversion stuff...

> Using a third party wrapper though means that you will probably have to
> wait until some time after a new release from AWI before the new features
> become available in the particular wrapper you've chosen.

True, remember the fiasco with people demanding a VB DLL and they were
waiting months...

> Given that AWI's beta's or alpha's or whatever are by invitation only,
> I would be leery using anyones wrapper since there is no guarantee
> they will be able to keep it up to date with whatever AWI is doing
> with the core SDK.

SDK gets updated very rarley... However, I think 80% of the Alpha / Beta
team must be coders anyhow...

> Stick with the official AWI SDK, or risk everything you do breaking
> on you one day with no warning.

The other thing is, the question of support. With the C DLL you can get an
(almost) unlimitted amount of help with anything you want as C++ is the most
popular language among high-power developers in here, also being what AW is
made in it offers the best options for compatability. Examples are things
like Byte Union's to set terrain textures, MThreading on multiple bots
(using correct locking - Cheers Miles).

Personally, after trying (in quantity) with using the C and the VB SDK's, it
seems to me that the C wrapper has greater flexibility to operate, granted
multiple instances may be more difficult, but when it comes to things such
as setting which function names etc that conform to your existing code for
things like events / callbacks, C++ is the clear winner because of its
pointer capability.

Also, if you start using Visual Basic with complex GUI's, you may find your
tools racking up substantial external OCX controls that you would need to
also distribute which does not always have the same capability as DLL
Import. This means more probs client side when others try to use your tools
with VB. There is also the problem of cross-platform compatability, with VB
it near enough dosent exist, although Linux can interprit if, albit slowly.

Personally, I would say that you should never decide on functions at all, I
remember a nice argument with Shamus (or was it Grimm?) in NewAW when we
were arguing about a data system that one of them uses, they use 3rd party
code, I wrote my own dynamic XML-Style tag handling. Now while whichever one
of em it was had the point that they didnt need to write the code
themselves, and it was quicker, I would be pretty interested to know if they
could do it themselves with ease. If your coding, you might as well learn
from it and not use 'invisible code' so to speak. Hell I know a lot of the
SDK coders look even beyond the AWAPI into the actual protocol.

Consider this situation:

You want to make a bot that looks up users IP's and saves them to a log when
a person enters the world. You toodle along with the VB SDK and make it with
ease... it works fine... Until... One of your users asks you to add a
reverse DNS to this. You do, using advanced Visual Basic API. This lil
beasty.

struct hostent FAR * PASCAL FAR gethostbyaddr(IN const char FAR * addr, IN
int len, IN int type);

So ok, you use the API to put it into VB... Works fine, you trundle along...
your DNS server screws up on one IP and your bot freezes for 10 seconds
waiting for an event; then it explodes. Answer: Multithreading, VB
capabilities of (any realistic levels of) Multithreading: Zero. You end up
having to recode the entire ruddy thing into C++ anyway just to put in a
function you could have (almost) done straight off if you chose the right
language to start with.

Scenario 1: You are just going to make a seedbot, maybe a tiny bit of
complex maths to define the range with which a random number can be in.
Whalla, its a seedbot, thats what it is, never going to be anything more,
VB's ability to make GUI's kicks ass and VB is the perfect system to make it
in...

Scenario 2: Your going to be making a system handling winsock connections,
huge databases, thousands upon thousands of lines of code, 5+ bots (Andras's
Hunt bot must be capable of supporting at least 36,000 of em?). You start
with VB... you make it... by the *counts* 11,000th line mark... Everythings
screwed because your having to use rediculously shite code (hell look at
collections in VB... vs the C++ equivilent). Everything dies, open up C++
and get on with it again when you should have used C++ in the first place.

Its a matter of chosing what, nothing wrong with developing in multiple
languages if you know them.

- MR

Dec 9, 2003, 1:02am

Very excellent summary of the many different choices Mark

[View Quote] <SNIP>

> Its a matter of chosing what, nothing wrong with developing in multiple
> languages if you know them.
>
> - MR
>
>
>

Dec 9, 2003, 1:07am

Of course.. as in woodworking.. if you just spent the rent money
on a shiny new tool.. by all means use the shiny new tool somehow
even if you don't strictly need to ;-)

[View Quote]

1  |   Order by index