2.4 plugins - first steps - eRobotPlayer

[Beardy]

I'm not at all sure about posting this ... its so quiet here ...

Well, here goes: I'm currently trying to make a very simple plugin for BZFS 2.4.0, giving me Admin status as soon as I log-in locally (127.0.0.1). Well, that part works.

The problem is that all bots I'm starting with also get the same status. O.k. , only a cosmetic problem but not quite nice.

So I went to search if I could check if the just-joined player is a robot. Well, it does not seem to be in the record(s) supplied to the "bz_ePlayerJoinPartEvent". Bummer.

After sone searching I found the "eRobotPlayer" element in the "bz_ePlayerType" enumeration. But alas, a full search of the sourcecode both of the above names only appear in in the bzfsapi.h file, and lead to dead end

So, does anybody have a bit more info / can help me to get the tanks PlayerType ?

[JeffM]

Yes for some reason it is not hooked up.

If you update to svn sources, you can use bz_getPlayerHumanity() to see if they are a bot or not. I'll see about getting it incorporated into a version of the player record when I can.

[Beardy]

Yes for some reason it is not hooked up.

Phew, thanks. I was afraid I overlooked something obvious.

If you update to svn sources,

I'm not, as I have no possibility to compile them (I'm not using VC to create my plugin(s) ). I would need to download a new windows-binary.

I'll see about getting it incorporated into a version of the player record when I can.

Thanks.

edit
I've created a bit of a hack to grab, in the plugin, the pointer to the player-records list (and thus the player-records themselves) and am just checking it directly for that robot-setting (a byte at offset 0020h).
Will probably break (graciously) on a different build, but for the moment its works.

[blast]

What do you mean you're not using VC? That's what we compile with on Windows, and that's the only method we support for building on Windows.

[Beardy]

What do you mean you're not using VC?

Exactly that I'm afraid. I'm using a fully other language to create the windows plugin-DLLs with.

and that's the only method we support for building on Windows.

I'm not "building on windows", I'm writing a plugin. A Windows DLL. There is nothing that needs to be supported for it, apart from the documentation to the API ofcourse.

P.s.
The reason I'm not using VC ? Too expensive (pro) or too tied to a single machine (express).

I must say that I find it a bit of funny: an open-source game which can, on a windows OS, only be compiled by a closed-source, payed-for compiler ...

[blast]

Visual C++ 2008 Express Edition is free and compiles it just fine, so I don't see your point. It also isn't the ONLY one that it can be built with. It's just the only one we're going to bother supporting on Windows.

[Beardy]

Visual C++ 2008 Express Edition is free and compiles it just fine, so I don't see your point.

Previously written by me:

... too tied to a single machine

I like to be able to take my compiled stuff with me to other computers. The express version won't allow that.

It also isn't the ONLY one that it can be built with.

Pray tell ! If I can get an OSS compiler which can compile that VC8 source I probably would try. If only to see if I could.

It's just the only one we're going to bother supporting on Windows.

I can understand that in the sense that its probably the easiest to support, but still find it funny that you guys either expect us to pay big bugs for the professional version, or need to (install the compiler and) compile it for every machine we want to run it on when we use the express version ...

And as I mentioned, the only support I need is to figure out what the API does -- or does not -- do.

[JeffM]

MS removed the runtime limits with VCee 2008, you can run the stuff on any machine so there is no reason not to use it. Also your hack may not work on every install or build of the server. I highly recommend using the real API for stability, binary offsets change as the code changes. If you insist on ignoring your ability to build with a free but not OSS tool I can build a version from SVN for you.

[Beardy]

MS removed the runtime limits with VCee 2008

Strange, I got my info just a few months ago ...

But in that case (please provide link to that info), do you maybe have a download URL for me ? I hate having to search thru hundreds of pages again for the *right* download link (I've got an MS VC8 features page here (not saying much at all), but no download link ... :-\ )

Also your hack may not work on every install or build of the server

I'm very aware of that. Thats why I called it a hack, not a solution.

I highly recommend using the real API for stability, binary offsets change as the code changes.

I know and I really would have liked that. But as the current binary does not seem to have the functionality needed, and there is no binary available which has it my hands are pretty-much tied.

If you insist on ignoring your ability to build with a free but not OSS tool I can build a version from SVN for you.

I would like to look at the features of the new, not locked(?) VC8, so that I can determine if its worth my hassle. If its not -- well, I might than take you up on the offer.

[JeffM]

a simple google search found.... http://lmgtfy.com/?q=visual+studio+2008 ... n+download

http://www.microsoft.com/visualstudio/e ... ns/express

you will also need the directX SDK and maybe the platform SDK. There is a readme in the source that has links for what you would need.

I also built a set of bins this morning.
http://www.awesomelaser.com/bz/bzflag-2 ... _32Bit.exe
http://www.awesomelaser.com/bz/bzflag-2 ... _64Bit.exe

being a software developer means you will have to build software at some point.

[Beardy]

a simple google search found.... <snip>

I did do a "simple google search" before posting here (If you wonder, I always try to do my own job before asking). The difference is you used "download" where I used " buy". :-\

And I'm sorry, but that link landed me on a JS laden page that didn't go anywhere -- not even when I looked at that pages source. Yes, I have JS disabled (and I intend to keep it that way).

The second link ? It did not go anywhere again. Clicking the VC++ 2008 download just returns the same page. Cause ? Bloody JS ofcourse

It always makes me wonder : what could JS give me there which a direct link would not ...


Thanks for the binary though, I just downloaded it. I thought it would only contain the server, but it has the whole thing. Much appriciated.

One last thing: where can I find the sourcecode ? Yes, I did just google for it ('+bzflag +"2.4.1" +source +zip' and other combinations). No, I did not get any meaningfull results. Again. :-\

[SkillDude]

The second link ? It did not go anywhere again. Clicking the VC++ 2008 download just returns the same page. Cause ? Bloody JS ofcourse

The reason is they ask you for a language to download it as before providing you the download. I really do not see what harm Javascript can do for you for all of 10 seconds worth of getting a download link.

One last thing: where can I find the sourcecode ? Yes, I did just google for it ('+bzflag +"2.4.1" +source +zip' and other combinations). No, I did not get any meaningfull results. Again. :-\

Though a google search may not help, a wiki search did:
http://wiki.bzflag.org/BZFlag_Source#Re ... stribution
http://wiki.bzflag.org/SVN#Getting_code_from_SVN_Access

[blast]

Wow, you really seem to suck at search engines. I searched for bzflag source code on Google and the top four results would have gotten you the information you needed.

[Beardy]

I really do not see what harm Javascript can do for you for all of 10 seconds worth of getting a download link.

Than I suggest you take a better look. JS was intended to enhance GUI elements on a webpage for the benefit of the visitor, but has been used maliciously for ages.

On my part "I really do not see" why the links are not simply present on that page. If JS is active they can be easily hidden -- by changing the visibility of an encompassing 'div'. If its not, they can be seen and used. Simple & effective. But no, that seems to be too much trouble ...

Though a google search may not help, a wiki search did: <snip>

Shucks ... I forgot all about that wiki ... I think I'll put it in my BZF related bookmarks section.

Thanks for the links/help.

Edit
I spoke too soon. I assumed the sourcecode would be downloadable as a .ZIP (or something like it), not realizing it was still in a development state. I think I'll wait until 2.4.1 hits "trunk" status.

None the less, thanks for your help.

[Beardy]

I searched for bzflag source code on Google and the top four results would have gotten you the information you needed.

... And the search-terms you used where ...? And why ?

After that please explain why the search-terms I used where wrong. Can you ?


I've spend enough time (hours) searching for some kind of info (mostly related to programming) to know that having/using the right search-terms is quite important. And finding/combining the right search-terms is often the result of a lucky roll of the dice -- even if you know what you're looking for.

But I expect you still need to learn that.

[JeffM]

"bzflag source code" as a search takes you right to the wiki.

In my original reply I said that you need to use SVN code. We only provide zip files for versions that have been released. 2.4.1 is the number we use for the development work on 2.4.2, so all it's code is in subversion. How to use our SVN system is mentioned on the wiki page as well as on these forums.

Also what "other language" are you using to make your DLL?

[Beardy]

"bzflag source code" as a search takes you right to the wiki.

D*mn. And there I was, looking for a specific version of it. :-\

Also what "other language" are you using to make your DLL?

That would be Assembly. Using Borlands Tasm 5.x to be exact.

[blast]

I spoke too soon. I assumed the sourcecode would be downloadable as a .ZIP (or something like it), not realizing it was still in a development state. I think I'll wait until 2.4.1 hits "trunk" status.

Trunk is currently 2.4.1. Trunk refers to the latest development code in our VCS.

After that please explain why the search-terms I used where wrong. Can you ?

You were looking for a specific grain of sand instead of just asking where the desert is.

[JeffM]

That would be Assembly. Using Borlands Tasm 5.x to be exact.

Good lord... why? do you like pain?

[Beardy]

Trunk refers to the latest development code in our VCS.

By what name do you than refer to the last finished version ?

You were looking for a specific grain of sand instead of just asking where the desert is.

"a grain of sand" would, for me, be more alike a specific line of code.

I was looking for the equivalent of a specific area in that desert. It didn't work.

[Beardy]

Good lord... why? do you like pain?

That must be it.

It could also be its my shared interrest in programming and electronics (microcontrollers) and being able to do low-level stuff.

And it ofcourse gives me, when I disassembly certain programs, quite a few chuckles when I see a "higher programing language" create awfull constructions and/or wasting lots of space (code and/or data).

[JeffM]

So let me get this straight.. After complaining to High Hrothgar and back about the open source-ness and practices of the microsoft compilers, you are making a windows specific dll in a language that can not be ported to any other OS with a proprietary tool...?

Yes assembly lets you hand tweak the code, the problem is you have to hand tweak ALL the code, and you make it for the single platform you are targeting. It is a good thing to know so that a software developer knows how the guts of the CPU work, but most of the time, like say in a plug-in for a silly game, the portability and development speed of a high level language outweigh the advantages of hand tweaked assembly.

Nobody cares if you save a few bytes or cycles when most of the time BZFS is sitting waiting for input from the network.

What a colossal waste of time this has been. So few servers run on windows it can't be worth it.

If you want to learn to program learn a bunch of languages, software developers are not defined by the language they know. Learn how to think like a programer then pick the best language for the task at hand.

[Beardy]

So let me get this straight.. After complaining to High Hrothgar and back about the open source-ness and practices of the microsoft compilers,

Huh ? I said I found it funny. Open-source game v.s. closed-source development tools. Why not something like gcc or any other open-source and/or free (as in: no strings attached) available compilers ?

you are making a windows specific dll in a language that can not be ported to any other OS with a proprietary tool...?

I'm the guy who wanted to create a simple plugin for his own use. Why should I (at this moment) take portability into account ? I do not even run Linux.

But you are free to take the idea and port it to VC8. You ofcourse won't be able to, as I had to use a hack to get some info that was not exposed in 2.4.0.

but most of the time, like say in a plug-in for a silly game, the portability and development speed of a high level language outweigh the advantages of hand tweaked assembly.

I can't remember having suggested you guys re-write BZFlag in Assembly. Can you ?

What a colossal waste of time this has been. So few servers run on windows it can't be worth it.

So, why than was it written in a portable language ? Why not drop Windows altogether and make it a Linux-only game ? Oh wait, that would not have given the game the popularity it now has got ...

Funny: On one side not wanting to have anything to do with Windows, on the other hand using a cross-platform language and even generate OS-dependant binaries for that "not worth my time" OS.

In short: Get off your high horse, you're not making much sense.

P.s.
Why doesn't the plugin-interface not simply expose (copies of) the objects stored in the game (like the player object with all of its stored data) ? Whats the idea behind disallowing the (read) access to them ?
Instead of providing a skeleton to build on we are presented with a walled garden (disallowing many ideas to be developped).

P.p.s.
Just two other (afaics) non-portable plugins I found. I wonder why you where not "all over them" as well ...
jsbzflag - scripting bzfs with Javascript
Ruby Plugin

[blast]

But you are free to take the idea and port it to VC8. You ofcourse won't be able to, as I had to use a hack to get some info that was not exposed in 2.4.0.

We'd do it properly and add support for the features to the API.

but most of the time, like say in a plug-in for a silly game, the portability and development speed of a high level language outweigh the advantages of hand tweaked assembly.

I can't remember having suggested you guys re-write BZFlag in Assembly. Can you ?

He didn't suggest that you suggested that. He specifically mentioned writing a plugin. Please try to read all the words.

What a colossal waste of time this has been. So few servers run on windows it can't be worth it.

So, why than was it written in a portable language ? Why not drop Windows altogether and make it a Linux-only game ? Oh wait, that would not have given the game the popularity it now has got ...

Again, try to read all the words. He specifically said the server. The number of public Windows servers is either zero or could be counted on a single hand. We have considered dropping support for the server on Windows because it would be one less thing to support. Also, popularity? What popularity? Have you seen the player counts lately? We are not popular.

In short: Get off your high horse, you're not making much sense.

Sounds like some advice that you should follow yourself.

P.s.
Why doesn't the plugin-interface not simply expose (copies of) the objects stored in the game (like the player object with all of its stored data) ? Whats the idea behind disallowing the (read) access to them ?
Instead of providing a skeleton to build on we are presented with a walled garden (disallowing many ideas to be developped).

Because it's an API. That's what APIs do. They provide a set of features that are externally exposed in a way that allows third-party software to interface with it. Allowing direct access to the internals of the server would lead to instability and wackyness, and would make it impossible to manage plugin code across versions of the game. The API will remain somewhat stable, whereas the internal code may change significantly and could/would break your "direct access" method of plugins. So, the proper way for your idea to work is to just extend the API to expose the necessary features.

P.p.s.
Just two other (afaics) non-portable plugins I found. I wonder why you where not "all over them" as well ...
jsbzflag - scripting bzfs with Javascript
Ruby Plugin

Why are you so sure they are non-portable? The JS one appears to be usable with Linux and Windows, and probably OSX. It is written as a proper BZFS plugin and uses the V8 JavaScript engine that powers Google Chrome. So how is that not portable?

The same goes for the Ruby one. It is written like a standard BZFS plugin and ties in to Ruby to then load plugins written in Ruby.

[JeffM]

The reason we don't expose the raw objects is because they change, by putting the access into an abstracted API we can keep that abstraction layer the same even if we change the backed. Otherwise everyone would have to rebuild plugins every time we changed a structure.

There is also a windows limitation of memory access across the exe/dll boundary. You can't allocate in one module and de-allocate in another, direct access to the STL containers in bzfs could cause this to happen and would be bad (memory corruption and crashes).

This is just common sense programing.

The server shares code with the client so they are written in the same language.

You may want to review what you know about other programing languages, most of them are very portable (Visual Basic is the only one that comes to mind that isn't very portable other then assembly)

And as for your other statement about Linux only, yes I have been pondering if we should drop support for BZFS on windows, currently the only reason to keep it is that it helps people working on the windows client develop things, since they can just run a server locally for testing.

Also you should note that it is possible to build bzflag on windows using minGW (the windows port of GCC). Not many people do it since VC is free and much simpler to use, so there are open source tools available. The main windows developers just happen to use VC since that is what they are used to.