2.4 plugins - first steps - eRobotPlayer
2.4 plugins - first steps - eRobotPlayer
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 ?
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 ?
Re: 2.4 plugins - first steps - eRobotPlayer
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.
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.
JeffM
Re: 2.4 plugins - first steps - eRobotPlayer
Phew, thanks. I was afraid I overlooked something obvious.Yes for some reason it is not hooked up.
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.If you update to svn sources,
Thanks.I'll see about getting it incorporated into a version of the player record when I can.
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.
Re: 2.4 plugins - first steps - eRobotPlayer
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.
Re: 2.4 plugins - first steps - eRobotPlayer
Exactly that I'm afraid. I'm using a fully other language to create the windows plugin-DLLs with.What do you mean you're not using VC?
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.and that's the only method we support for building on Windows.
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 ...
Re: 2.4 plugins - first steps - eRobotPlayer
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.
Re: 2.4 plugins - first steps - eRobotPlayer
Previously written by me:Visual C++ 2008 Express Edition is free and compiles it just fine, so I don't see your point.
I like to be able to take my compiled stuff with me to other computers. The express version won't allow that.... too tied to a single machine
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 also isn't the ONLY one that it can be built with.
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 ...It's just the only one we're going to bother supporting on Windows.
And as I mentioned, the only support I need is to figure out what the API does -- or does not -- do.
Re: 2.4 plugins - first steps - eRobotPlayer
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.
JeffM
Re: 2.4 plugins - first steps - eRobotPlayer
Strange, I got my info just a few months ago ...MS removed the runtime limits with VCee 2008
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 ... :-\ )
I'm very aware of that. Thats why I called it a hack, not a solution.Also your hack may not work on every install or build of the server
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.I highly recommend using the real API for stability, binary offsets change as the code changes.
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.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.
Re: 2.4 plugins - first steps - eRobotPlayer
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.
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.
JeffM
Re: 2.4 plugins - first steps - eRobotPlayer
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". :-\a simple google search found.... <snip>
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. :-\
Re: 2.4 plugins - first steps - eRobotPlayer
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.Beardy wrote:The second link ? It did not go anywhere again. Clicking the VC++ 2008 download just returns the same page. Cause ? Bloody JS ofcourse
Though a google search may not help, a wiki search did: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. :-\
http://wiki.bzflag.org/BZFlag_Source#Re ... stribution
http://wiki.bzflag.org/SVN#Getting_code_from_SVN_Access
Re: 2.4 plugins - first steps - eRobotPlayer
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.
Re: 2.4 plugins - first steps - eRobotPlayer
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.I really do not see what harm Javascript can do for you for all of 10 seconds worth of getting a download link.
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 ...
Shucks ... I forgot all about that wiki ... I think I'll put it in my BZF related bookmarks section.Though a google search may not help, a wiki search did: <snip>
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.
Last edited by Beardy on Sat Dec 03, 2011 3:19 pm, edited 1 time in total.
Re: 2.4 plugins - first steps - eRobotPlayer
... And the search-terms you used where ...? And why ?I searched for bzflag source code on Google and the top four results would have gotten you the information you needed.
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.
Re: 2.4 plugins - first steps - eRobotPlayer
"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?
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?
JeffM
Re: 2.4 plugins - first steps - eRobotPlayer
D*mn. And there I was, looking for a specific version of it. :-\"bzflag source code" as a search takes you right to the wiki.
That would be Assembly. Using Borlands Tasm 5.x to be exact.Also what "other language" are you using to make your DLL?
Re: 2.4 plugins - first steps - eRobotPlayer
Trunk is currently 2.4.1. Trunk refers to the latest development code in our VCS.Beardy wrote: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.
You were looking for a specific grain of sand instead of just asking where the desert is.Beardy wrote:After that please explain why the search-terms I used where wrong. Can you ?
Re: 2.4 plugins - first steps - eRobotPlayer
Beardy wrote: That would be Assembly. Using Borlands Tasm 5.x to be exact.
Good lord... why? do you like pain?
JeffM
Re: 2.4 plugins - first steps - eRobotPlayer
By what name do you than refer to the last finished version ?Trunk refers to the latest development code in our VCS.
"a grain of sand" would, for me, be more alike a specific line of code.You were looking for a specific grain of sand instead of just asking where the desert is.
I was looking for the equivalent of a specific area in that desert. It didn't work.
Re: 2.4 plugins - first steps - eRobotPlayer
That must be it.Good lord... why? do you like pain?
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).
Re: 2.4 plugins - first steps - eRobotPlayer
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.
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.
JeffM
Re: 2.4 plugins - first steps - eRobotPlayer
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 ?So let me get this straight.. After complaining to High Hrothgar and back about the open source-ness and practices of the microsoft compilers,
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.you are making a windows specific dll in a language that can not be ported to any other OS with a proprietary tool...?
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.
I can't remember having suggested you guys re-write BZFlag in Assembly. Can you ?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.
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 ...What a colossal waste of time this has been. So few servers run on windows it can't be worth it.
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
Re: 2.4 plugins - first steps - eRobotPlayer
We'd do it properly and add support for the features to the API.Beardy wrote: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.
He didn't suggest that you suggested that. He specifically mentioned writing a plugin. Please try to read all the words.Beardy wrote:I can't remember having suggested you guys re-write BZFlag in Assembly. Can you ?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.
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.Beardy wrote: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 ...What a colossal waste of time this has been. So few servers run on windows it can't be worth it.
Sounds like some advice that you should follow yourself.Beardy wrote:In short: Get off your high horse, you're not making much sense.
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.Beardy wrote: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).
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?Beardy wrote: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
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.
Re: 2.4 plugins - first steps - eRobotPlayer
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.
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.
JeffM