AIs that require config files are serious usability problems

[Pxtl]

Maybe AIs should be moved into the game packages altogether? Then again, we don't want untrustable DLLs being included in SDZs.

[AF]

sdz files are not games, they are components of games. We should not treat them liek mini installers.

[TheFatController]

We should not treat them liek mini installers.

Counterpoint: Maybe we should?

[Pxtl]

Either way, including a non-Lua AI in an sdz is unsafe for the users.

[AF]

It would also be a logistical nightmare for us AI developers

[Pxtl]

It would also be a logistical nightmare for us AI developers

The whole purpose of AIs is for users though, and right now the user-experience of AIs is a nightmare. You get a list AIs with opaque filenames and no idea of which ones will crash when you run them with the selected mod (hint: most of them).

If the AI was bundled with the mod and was the only AI listed, think what the user would see: they click the "add bots" list and only see one or two AIs that are built into the game - the modder could even give them user-friendly names and information that are contextual to his mod.

KP and CA/Chickens already use this, and it's quite nice. They're the only mods with a good user experience of AIs.

These general-purpose AIs that are really not general-purpose are just keeping users away from the single-player game.

[AF]

You would in the process be condemning AIs to mod release cycles and horrible problems.

Putting the binaries in the mod also brings about other issues aside from distribution and updating, such as executing them inside the archive, aswell asother horrible issues. It is a logistical nightmare.

It would be far better to create a BAinstaller.exe with the AI and an sdz inisde, than it is to put the AI inside the sdz.

Then there's 64bit ai.dll versus 32bit ai.dll versus linuxai.so versus 64bit linuxai.so versus ubuntu linuxai.so versus fedora linuxai.so versus PPC macai.dylib versus 32bit x86 macai.dylib versus x64 macai.dylib, etc etc etc

and what fi a bug is found in the AI? Shall we wait for a whole enw release fo BA and everyone have to update else they wotn sync? Or shall we wait 5 minutes for an AI dev to press a rebuild button and push out an update thats optional?

[BaNa]

dont add a restrictive list for which map the ai can play and which it cant cause that would suck balls. if something of the sort is needed make it into a preferred maps list...

[hoijui]

The only viable way is the one AF suggests, putting workign AIs into games installers.
We discussed all this a few times already. We agree that it is not optimal for the user as it is now (if you dont use a games installer), but all the other solutions would never work in practice at all.
The way it wors now, is that the user has to read the description of the AI, to see if it will work. These descriptions are very broad, and the user will still have to test the AIs with his favourite mods, most likely. As said, this is not optimal, but white or blacklists and all that would never work in practice. if you want the details for why, go search the other threads about this topic.

short:
there is an optimal way for mod-devs: make your own installer
there is a way that works so-so for users and AI devs: the general engine installer
all the new suggestions: we would end up with the users never seeing any AIs (worse then what we have now for users, and much worse for AI devs)

[AF]

The name of the game is reccomended AIs and AIs reccomended against, rather than AIs that definately work and definately don't, because the answerto whcih works and doesnt changes a lot more than a normal mods cycle.

[YokoZar]

Then there's 64bit ai.dll versus 32bit ai.dll versus linuxai.so versus 64bit linuxai.so versus ubuntu linuxai.so versus fedora linuxai.so versus PPC macai.dylib versus 32bit x86 macai.dylib versus x64 macai.dylib, etc etc etc

This makes shipping AI files inside mods unworkable, however shipping config files and a "whitelist me" file inside the mod is plausible.

[AF]

Indeed I suggested modders putting config files inside their mods a long time ago, as any newer configs in the users directory would override them. Nobody followed the idea though..

[zwzsg]

Well, that suggestion is useless as long as every AI sit idle or crash, even with a config file.

I suggest we axe every AI-as-.dll. Remove them from the installer, and remove them from being loaded by Spring.exe and every lobbies. Lua AI are the only reliable way to get working AI anyway. AI-as-.dll are a thing of the past, that only serve as an hindrance detering new users.

[Argh]

I agree with zwzsg.

Look, the engine isn't here for AI developers to foist their un-working products on clueless newbies, and thereby crash the engine (or possibly worse, depending on how completely unsafe their method was).

And the record in this regard is entirely clear: AI developers working on DLL-based AIs frequently build AIs that use unsafe methods and crash the game engine.

They don't even bother to fix their AIs from crashing when they hit situations that go outside their limited design parameters. And, in general, they're the last people I want to see writing a blacklist.

I can see that one now: "Hey, AI dev... update your blacklist, P.U.R.E. changed version numbers and no longer matches your blacklist schema, and players are crashing Spring trying to use your AI with my game"... <AI dev> "Too lazy, haven't made a change in six months, since I got a job after publishing my paper, can't be bothered."

If you think that sounds exaggerated... last month, I dealt with an AI developer who couldn't be bothered to fix an engine crash when testing his AI, caused by playing on a "metal" map.

When we have no way to encourage AI developers who want an audience to keep within some guidelines, then we get lazy idiot AI, not polished products that won't crash when presented with situations that go outside their parameters.

Now, before everybody assumes I'm just wanting to stick AI developers into a box, and make them slaves to game designers... look, I'm just going to say this once. I have no problem with people using the engine for ivory-tower purposes. I have no problem with them even wanting to find an audience for black-box AIs. But they should not get a free ride on the engine distribution any more than games do, unless they meet some really high requirements.

That's why I proposed my compromise, which got lost in the shuffle here: instead of building AI-as-DLL, simply build AI-as-Lua that uses specialized functions buried within DLLs written specifically for the purpose (that should be required to be safe).

This would serve several useful purposes:

1. AI developers would have something like accountability to the general game community. If they want to build a new AI and it can't meet those requirements, or go through the process of submitting their source and debugging it until it is safe and stable... then we all know that their work is experimental and probably unstable, and should not be included with the engine releases.

That gives AI developers who want a broad audience a strong incentive to play ball, which is the only way to make systems work in an Open Source world. On the other hand, it means that C.R.A.I.G. and the KP AIs are the only ones that are currently qualified.

2. It would encourage AI developers to work on community projects, and to keep in mind that, from an end-user's perspective, AIs are "part of the engine", just as any full game developed and deployed on this engine is regarded as a "complete product"- the end-user doesn't give a hoot that I'm leveraging Spring, they care about the final experience.

3. It would foster growth of Lua AI, which is the only way to eventually have general AI support and community-wide expertise available for new projects. Which is what really matters, in terms of long-term goals.

IOW, new game designers, once they've crossed the high and forbidding Barriers to Entry present around the engine, hopefully with help from their fellow game designers, would also be able to find newbie help for writing some AI support.

[AF]

Argh your points are misinformed:

• What is defined as safe can be applied to the native AIs that already exist, you dont need to discard what we alreayd have in order to enforce quality control
• Many AI developers here failt or ealise how to fail gracefully and how to check adn make assertions, which are good programming practices. This is an ideological flaw, and ti is not shared by all developers
• You keep overlooking the native AIs that bucked the trend and behaved

Since I know most about my own AI, and you keep ignoring my own AI, lets look at it point by point:

1: AI developers dont care about safety, and will only fix crashes that occur under the circumstances they design for, aka BA.

NTai went to great lengths to prevent itself from running code when the assumed situation was unavailable. It would not attempt to do things if prior conditions where not met first.

Infact, when NTai crashed, the crash was caught within NTai and the AI would log the crash and shut itself down, so the suer could continue to clean up the idle AI base. Later versions allowed seperate handling of non-critical code so that the AI could pick itself bakc up and carry on playing the game despite bugs and crashes!

I have old replays here where NTai continues to play games despite crashing 5 or 6 times a minute after the 40minute mark

2: AI developers only support the games they want.

I went out of my way to support every game I possibly could to gain a competitive advantage and make my code base as possible. I even supported comshooter!!?!?! Not to mention nanoblobz. I implemented large rewrites and refactors in order to support EE, and I was the first to support kernel panic (although I will not comment or discuss any further that topic as its a guaranteed flamewar from zwzsg)

3: Unless an AI has a configuration file for the game, it will crash and the user willbe landed in a great big mess. It is a usability flaw

Wrong!

NTai was a configurable AI, and for a long time it had no BA or AA support of any kind, yet it played the game, it built factories, it attacked the player, it wasn't an amazing BA AI, but it played it and it tried well. No crashes. No idle commander.

NTai could play mods without a configuration file, despite relying on configs.

How?

Generic configuration files.


So if you want to believe the disgruntled Content devs, go ahead, but all their points are nonsense. How do I know this? BECAUSE I ACTUALLY DID IT!!!!

If you wish to see the evidence, go look in th e70 page NTai thread in the AI forums.

Just to prove the ignorance of argh and zwzsg, I point them at the python and java AIs. These AIs are arguably just as safe as lua, and one could go as far as saying as well written c++ code can be safer and more flexible than lua AI code, if not faster.


Dont blame AI development for the failures of the few. Some AI developers think when AIs fail they should crash hard and take the engine with them. Persuade them otherwise, dont penalise those of us who try.

[AF]

In the meantime I can safely predict that no AI developer will want or feel the need to develop P.U.R.E versions of their AIs, not because they're stuck up twats who think people should pander to them, but because you're being stubborn and pigheaded because AI development didnt come to your rescue at a time when there were no developers to even look at P.U.R.E

[AF]

NTai playing Rhyoss without a config



NTai playing nanoblobz by argh, without a config



Hey look in this one its actually crashing yet it still carries on playing the game!!

[AF]

Oh look, winning at kernel panic



What's this? Making a modest attempt at EE are we?



I remember having to make various adjustments to building placement for that, just to support hubs, but if you notice, I did it without being asked, just so I could support EE, not because fang asked me, or because there was a great rapturous demand for it ( although foreboding angel wanted it and later worked on a config )

[YokoZar]

There's no point removing DLL/.so based AIs if they're useful to some users. At worst just keep them from the user - that can easily be done by hiding them unless they're whitelisted for a particular mod. Such a whitelist could be a simple text file in either the mod or the AI itself.

That way if I design my new AI to work for BA I can write "enable BA" in it and then I don't have to wait on TheFatController for an update to support it.

[AF]

The last thing I want to deal with in NTai development is politics and waiting on content developers to release new versions of their content, because they won't re-release their games because I added support.

Nor will other AI devs, its a huge pressure not to bother developing for en games unless that developer is making every attempt to court you, and they don't seem to eager to do that either.

The very people who refused to cooperate with AI developers in the old days are now complaining because of it. Let them complain about the dodgy AIs, they'll soon see when serious competition comes forward.