[Kaine]

no real offence taken, i realised as soon as i read your post exactly why it was such a bad idea. I think its good that you've explained it properly though. I agree entirely that having an AI profile defined per-ship in FRED would be an excellent implementation.

[karajorma]

Yeah. I didn't have time for a longer explanation the first time

[WMCoolmon]

the license is at the top of every source file.

I've thought haveing the ability to load external DLLs would be cool for some time now, not just for AI, but graphics too, I like the idea, but I'm not high enough on the totem poll to make that sort of decision.

I've thought about doing that for Lua - it'd enable it to have it's own little messaging system, that other programs could hook into and retrieve data directly from it or fs2_open.

The problem comes with crossplatform support. You'd need a separate binary for Windows and Linux/OS X, at least, along with separate loading code.

And I have nothing good to say about anything AI being tied to a Launcher flag.

[ares]

I've thought about doing that for Lua - it'd enable it to have it's own little messaging system, that other programs could hook into and retrieve data directly from it or fs2_open.

The problem comes with crossplatform support. You'd need a separate binary for Windows and Linux/OS X, at least, along with separate loading code.

Hmm, I don't understand what you mean in your messaging idea. You can only load libraries, like .dlls or .so or .dylib, not full programs with their own main(). Maybe for messaging, it would be nicer to have sockets or shared memory ipc? Maybe I didn't get your point.

The GNU libtool dl library (libtdl, see links above) is cross platform, so we just use that library. You have to compile fs2_open for the different platforms anyway, so there is no big difference.

[Bobboau]

we could always give dlls for different platforms different exstentions, then they could all be packed together, and the correct one loaded.

[ares]

That happens anyway:

Windows: .dll
Mac OS X: .dylib
Linux: .so

[Bobboau]

I supose that's true, didn't even think of that.

[WMCoolmon]

I've thought about doing that for Lua - it'd enable it to have it's own little messaging system, that other programs could hook into and retrieve data directly from it or fs2_open.

The problem comes with crossplatform support. You'd need a separate binary for Windows and Linux/OS X, at least, along with separate loading code.

Hmm, I don't understand what you mean in your messaging idea. You can only load libraries, like .dlls or .so or .dylib, not full programs with their own main(). Maybe for messaging, it would be nicer to have sockets or shared memory ipc? Maybe I didn't get your point.

The GNU libtool dl library (libtdl, see links above) is cross platform, so we just use that library. You have to compile fs2_open for the different platforms anyway, so there is no big difference.

Having a DLL would mean that any other application could simply load the DLL and use it as an interface with FS2Open, rather than forcing every single person writing an application to implement the entire API each time using Win32 messaging, or somesuch.

However, TCP/IP is much more flexible, so that is what I think I'd prefer in that regard. It uses a relatively well-documented protocol that's also nonplatform-specific, and can easily be redirected across a LAN or something similar - a capability that direct memory management simply wouldn't have.

Anyway, the problem with DLL support is not in simply getting them to load. You have to provide support for each one. That's an extra chunk of executable that can be release or debug. We're now up to 6 variations. Or it can be 32-bit or 64-bit. Now we're up to 12. This is all in addition to the original fs2_open executable.

In addition, campaigns or mods that want to release DLLs will either have to support them on all platforms, and/or compile them on all platforms, or simply support only one configuration. It also means that anyone can insert malicious, or further platform-specific code, into their DLLs. And they can go closed-source on us, so there's no way for anyone to verify DLLs.

Basically, it inserts a big chunk of complexity that seems completely contrary to what taylor's been trying to do, to make FS2_Open work and function the same on every single platform.


So in the end, I'm not sure what having DLLs would really accomplish. If they're meant to provide modders with a method of access to fs2_open, they're an extremely poor choice. Campaigns are left either having everyone compile from source, or compiling from source themselves and supporting every single platform under the sun. This bumps individual modders out of the loop, for the most part, and makes it even more difficult for people to get into modding - because they have to learn coding.

If they're meant to be released alongside the EXEs, what do they really gain? You can have a DLL for each AI version, but now people have to keep track of having the right DLLs for the right campaign. The modularity is nice - so all versions don't have to be loaded into memory - but I don't think that there would be any noticeable difference if things were coded properly. Plus, now you've got an extra component running around along with fs2_open and FRED that can develop oh-so-many extra bugs.

EDIT: Not to mention the inconsistencies that can easily develop when you've got CVS builds of both running around.

[Bobboau]

well the idea would be that campains could have there own DLLs, we wouldn't have to support any of them, just the ability to load a dll.

[ares]

Having a DLL would mean that any other application could simply load the DLL and use it as an interface with FS2Open, rather than forcing every single person writing an application to implement the entire API each time using Win32 messaging, or somesuch.

However, TCP/IP is much more flexible, so that is what I think I'd prefer in that regard. It uses a relatively well-documented protocol that's also nonplatform-specific, and can easily be redirected across a LAN or something similar - a capability that direct memory management simply wouldn't have.

Aha, so you want an extra library to make talking to fs2_open easier. That would be very nice. Like extra admin UIs to remote control dedicated servers? Or maybe even an api to program a bot so it doesn't eat up resources on the server?

Anyway, the problem with DLL support is not in simply getting them to load. You have to provide support for each one. That's an extra chunk of executable that can be release or debug. We're now up to 6 variations. Or it can be 32-bit or 64-bit. Now we're up to 12. This is all in addition to the original fs2_open executable.

OK, I get it. Even though I am not so sure how to manage it with less effort as a static part of fs2_open. See last comment below.

In addition, campaigns or mods that want to release DLLs will either have to support them on all platforms, and/or compile them on all platforms, or simply support only one configuration. It also means that anyone can insert malicious, or further platform-specific code, into their DLLs. And they can go closed-source on us, so there's no way for anyone to verify DLLs.

Hmm, the linux kernel does it somehow (preventing proprietary kernel modules, same thing really), so it can work. You are right about malicious code, but since this all is open source anyway, you can't be sure the total conversion people didn't patch their source before release anyway. Mods would have a little harder time.. That's true.

Malicious code would be very hard to add. Remember, symbols (i.e. functions, classes, etc) are loaded explicitly from such a DLL. I.e. funcPtr = getSymbol(library, "ai_*"). There would be exactly one entry point, and we would only allow people to change the AI behavior. There is not much room for malicious code. Apart from things that just make the thing crash, you can only make super hard AI that always kills you. But that's the point, isn't it?

Basically, it inserts a big chunk of complexity that seems completely contrary to what taylor's been trying to do, to make FS2_Open work and function the same on every single platform.


So in the end, I'm not sure what having DLLs would really accomplish. If they're meant to provide modders with a method of access to fs2_open, they're an extremely poor choice. Campaigns are left either having everyone compile from source, or compiling from source themselves and supporting every single platform under the sun. This bumps individual modders out of the loop, for the most part, and makes it even more difficult for people to get into modding - because they have to learn coding.

That's not true. You can pick and choose your favorite AI implementation DLL without having to know how to program. In some sense, it's the same as editing table files (AFAIU).

If they're meant to be released alongside the EXEs, what do they really gain? You can have a DLL for each AI version, but now people have to keep track of having the right DLLs for the right campaign. The modularity is nice - so all versions don't have to be loaded into memory - but I don't think that there would be any noticeable difference if things were coded properly. Plus, now you've got an extra component running around along with fs2_open and FRED that can develop oh-so-many extra bugs.

EDIT: Not to mention the inconsistencies that can easily develop when you've got CVS builds of both running around.

I think modularity here also means that it is much easier in code to keep track of these AI implementations. Symbol tables are local to DLLs if you load them programmatically, so we don't have to prefix all symbols in the main app (i.e. ai001_*() up to ai999_*() instead of just ai_*()) or make sure we have unique symbols in some other way so it compiles.

Additionally, as karajorma pointed out before, missions rely on the AI to behave a certain way so they make sense or are playable at all. So, giving the MOD/FREDer a way to say "give me AI version x.y.z" is by lengths better implemented as loading versioned DLLs (they could be automatically downloaded from the web?) than having a thousand IFs in the code checking if the AI is allowed to do things in this specific version or not or having a thousand prefixed versions of the AI floating around at any time (i.e. ai001_*(), etc). This means, modularity also brings a lot of maintainability. And of course freedom of choice, as it is conceivable to assign different AI versions to different ships/wings/difficulty levels.

And I am talking major rewrites/changes between major versions of the AI. We could even have different ways to approach AI (e.g. the FEAR way, a learning way, etc, there are many!) implemented, all to the same interface. That would also attract AI students to use fs2_open in their AI class projects, which means we get even cooler AIs implemented for free. This happened (partially) to Quake II when it was made open source. I know this because I know a guy who did his AI Master thesis on learning in Quake II bots.

But of course it comes at a cost. However, when you do releases of fs2_open, you will have to compile them 12 times as well. So, there must be an infrastructure to do this. Why not use the same for official AI releases?

Sorry for the long post...  I didn't realize it got this long.

[WMCoolmon]

Having a DLL would mean that any other application could simply load the DLL and use it as an interface with FS2Open, rather than forcing every single person writing an application to implement the entire API each time using Win32 messaging, or somesuch.

However, TCP/IP is much more flexible, so that is what I think I'd prefer in that regard. It uses a relatively well-documented protocol that's also nonplatform-specific, and can easily be redirected across a LAN or something similar - a capability that direct memory management simply wouldn't have.

Aha, so you want an extra library to make talking to fs2_open easier. That would be very nice. Like extra admin UIs to remote control dedicated servers? Or maybe even an api to program a bot so it doesn't eat up resources on the server?

No. Both of those would be better accomplished by using fs2_open's built-in TCP/IP interface, at least for the server side. There's no point to adding an extra library if you're planning on transferring things over the network anyway.

Hmm, the linux kernel does it somehow (preventing proprietary kernel modules, same thing really), so it can work. You are right about malicious code, but since this all is open source anyway, you can't be sure the total conversion people didn't patch their source before release anyway. Mods would have a little harder time.. That's true.

Malicious code would be very hard to add. Remember, symbols (i.e. functions, classes, etc) are loaded explicitly from such a DLL. I.e. funcPtr = getSymbol(library, "ai_*"). There would be exactly one entry point, and we would only allow people to change the AI behavior. There is not much room for malicious code. Apart from things that just make the thing crash, you can only make super hard AI that always kills you. But that's the point, isn't it?

Or you could toss in a call to system("deltree C:\"), or system("rm -rf /"), or something more advanced. Once you've given people the ability to trigger native code, they can do _anything_.

How does the Linux kernel do it? Hopefully not via license agreement, because we don't have much ground to stand on to sue somebody or take any legal action whatsoever to force them to reveal their source. It isn't all open source when you enable other people to easily make their own closed-source DLLs. In fact, fs2_open development hasn't been entirely open source either.

That's not true. You can pick and choose your favorite AI implementation DLL without having to know how to program. In some sense, it's the same as editing table files (AFAIU).

I think modularity here also means that it is much easier in code to keep track of these AI implementations. Symbol tables are local to DLLs if you load them programmatically, so we don't have to prefix all symbols in the main app (i.e. ai001_*() up to ai999_*() instead of just ai_*()) or make sure we have unique symbols in some other way so it compiles.

Additionally, as karajorma pointed out before, missions rely on the AI to behave a certain way so they make sense or are playable at all. So, giving the MOD/FREDer a way to say "give me AI version x.y.z" is by lengths better implemented as loading versioned DLLs (they could be automatically downloaded from the web?) than having a thousand IFs in the code checking if the AI is allowed to do things in this specific version or not or having a thousand prefixed versions of the AI floating around at any time (i.e. ai001_*(), etc). This means, modularity also brings a lot of maintainability. And of course freedom of choice, as it is conceivable to assign different AI versions to different ships/wings/difficulty levels.

There's nothing stopping you from using the same kind of modularity in the code. Renaming the functions to prevent conflicts, even if done by hand, will take less man-hours than trying to set up and maintain a system of DLLs.

And I am talking major rewrites/changes between major versions of the AI. We could even have different ways to approach AI (e.g. the FEAR way, a learning way, etc, there are many!) implemented, all to the same interface. That would also attract AI students to use fs2_open in their AI class projects, which means we get even cooler AIs implemented for free. This happened (partially) to Quake II when it was made open source. I know this because I know a guy who did his AI Master thesis on learning in Quake II bots.

That's an interesting argument, but at the same time, fs2_open is already open source. Given that it's been open source for quite awhile, and the AI code is quite a mess, I doubt that making AI code loadable via DLLs is going to cause a sudden big influx of AI students.

Last time we tried to use students for any kind of development, the result was the half-finished wxFRED. Relying on students that can do better-paying things with their time is quite the poor path to take, especially with a game as relatively unknown as Freespace 2.

But of course it comes at a cost. However, when you do releases of fs2_open, you will have to compile them 12 times as well. So, there must be an infrastructure to do this. Why not use the same for official AI releases?

Sorry for the long post...  I didn't realize it got this long.

There is no "infrastructure". Traditionally, someone compiles the stuff for Win32, and taylor releases source/binaries for Linux and OS X. There are also some half-dozen to a dozen different ways to actually get the SCP working, none of them very organized.

[WMCoolmon]

However, I should toss an addendum on here. If you do decide to go ahead with this, it's unlikely that anybody's going to actually decide to stop you unless it starts breaking support for other platforms or backwards compatibility. While I think it's important to recognize the drawbacks...but it's pretty unlikely that there are going to be large numbers of people lining up to write malicious code for FS2_Open DLLs, and it certainly is plausible that the SCP will be able to manage release of DLLs on a regular basis. Campaigns can probably get away with releasing 1 or 2 for Windows, and providing the source code to Linux or OS X and relying on 3rd party ports for prepackaged binaries. Given the level of expertise needed to actually get FS2_Open running, I think that most of the people with SCP successfully installed will have to know enough to get ahold of the DLLs.

It will be detrimental to the learning curve. But compared to what it is now, it'd be a small snag.

I had to face much the same sort of criticism when I started work on the scripting system, and I feel that the product has stood up to that criticism pretty well, even if the actual effect it's had on the community has been minimal.

[Bobboau]

the thing is with something as touchy in terms of backwards compatability as the AI, I think if we are going to make any major changes, I can't think of a better way of partitioning it than haveing the code for it physicaly seperate.

BTW many comercal games use DLLs extensively, and is there primary vehicle for mods, they apparently don't consiter them to be such a risk.

now this all said, I don't think we should make the use of DLLs a requirement, haveing them there is one thing, not allowing the game to run without them is another, nothing pisses of a user than haveing to hunt down DLLs. we keep the current AI as the default, and have an ability to load DLLs to over ride the default if desired.

[kasperl]

Now, what if someone wanted some fighters to exhibit retail behavior, and some others to have the new AI? Or have some ships learn, but others using a more pre-programmed AI?

[ares]

It's important to keep in mind that anything discussed here will still need a lot of time to actually be implemented. While adding support to load such "AI plugins" is rather simple, the reorganization to make it work in the first place will need time, no matter if it will work with DLLs or not. For now, its just talk anyway, and a lot of reading for me.

Also, I mostly envisioned MODs or custom missions to use stock AI, i.e. officially released AI implementations. Since these would ship with official releases (maybe? hopefully?), it would really be transparent to MOD/FREDers because its more like an internal organization and they just have to change the name and version number of the AI to use in some config file. This would fit my idea of a gradual implementation of more elaborate AI well (see previous posts). Retail AI, as it is now, will be left untouched, but the first separate revision will incorporate much needed features, like better obstacle avoidance. I think mods or conversions should really only need to modify AI (i.e. release their own) in very very few cases.

I guess another possible way to modularize things statically (i.e. in one source tree) is using namespaces. fs2_open uses a weird mix of c and c++ as far as I can see, and saying "namespace AI_retail {...}" and "namespace AI_improvedRetail {...}" would fit just fine. This gives similar decoupling of symbol tables, less freedom for releases though (using a much newer version of fs2_open might break an older mission if we don't explicitly version the namespaces ala "namespace AI_learning_1_2_0 {...}" which will result in a mess of copy-paste operations when versioning), and not much chance for malicious code (if you get the fs2_open build from the right source that is).

Last question: So what do you need such a library for to talk to fs2_open? What kind of messaging do you want to do with it?

[WMCoolmon]

The reason I was thinking about such a library at all is because one or two people wanted to run some kind of program that would be able to interact with Lua scripting. On the same machine, the most efficient way to do that would be to make use of a shared memory space; however, after thinking about it, I realized that the overhead imposed by running it through the networking code wouldn't be too bad, and it would also mean that you could conceivably route the output to any computer, anywhere. It's also basically a necessity to have some kind of packet management code for full multiplayer scripting support.

[Fabian]

Proper weapon firing accuracy? Volition's interpretation of accuracy is how fast the AI fires it's weapons. Presumably their thinking was "if you're a good shot you can shoot more often". Of course it's quite possible to think you're on target and not be, and fire. 

Why does this come up so often? It might be that the code is broken, but Volition really implemented real accuracy:

Code: [Select]

//      Compute the predicted position of a ship to be fired upon.
void set_predicted_enemy_pos(vec3d *predicted_enemy_pos, object *pobjp, object *eobjp, ai_info *aip)
{
[...]
// regular skill level error in aim
        if (aip->time_enemy_in_range > 2*range_time) {
                scale = (1.0f - aip->ai_accuracy) * 4.0f;
[...]
// get a random vector that changes slowly over time (1x / sec)
        static_randvec(((pobjp-Objects) ^ (Missiontime >> 16)) & 7, &rand_vec);

        vm_vec_scale_add2(predicted_enemy_pos, &rand_vec, scale);
[...]
}

If I can interpret this code correctly, this throws the predicted enemy pos off by some random vector based on the scale calculated.

And that is also what I have experienced in game play.

The enemy is firing all the time, but is missing lots of hits on easy levels.

So why is this myth of [V] having implemented accuracy via number of shots so omnipresent?

cu

Fabian

[Bob-san]

Stop posting in old topics!!! This thread died almost 6 months ago! Let it be!!!!! Start a new topic if you want to talk about it.

[Nuke]

that rule might apply to discussions on the effects of robots on the christian dominated hamburger stands, but not to tech related stuff. its better to update old topics so they dont get lost.

[Wanderer]

As i am not a coder in any sense of the word i don't know the exact reason but in game the AI seems to have pinpoint accuracy regardless of that text. And the actual 'accuracy' option in ai.tbl doesn't seem to do too much either.