Mods X AI's

[FLOZi]

I have encountered CRAIG being broken multiple times already in S44

Problem exists between testers and devs (I usually manage to patch CRAIG up after I break it so long as someone informs me something is wrong (actually, the biggest breakage came when start unit spawning switched to a gadget, and engine healthbars were removed (replacement gadget caused some weird issues with CRAIG i never fuly figured out)))

as a matter of fact, no serious AI dev will want to use Lua to code his AI (reasons mentioned many times already)

Where?

[AF]

Knorke, Shard wasn't designed to be 'configurable' it was designed to be 'programmable'. Those tasklists and lists of attackers are not how you configure shard, its how you configure the placeholder code, code that can be completely overriden with custom logic.

If you'd like you can redefine what modules are loaded so the default taskqueue and attacking system never get loaded, and load your own custom logic instead.

Or you can override the files, to make it use your own modified version, simply by copying the file into your games subfolder, and then editing the copy. The whole AI right down to its core can be torn out and reimplemented as you see fit

If you look at the shard thread, you dont even need to do that, instead of specifying a unit name you can specify a function that returns a unitname string.

[Forboding Angel]

Now watch as I rip your argument to shreds.

as a matter of fact, no serious AI dev will want to use Lua to code his AI (reasons mentioned many times already). people like forb will never get that, but they and their users are not the only people that count here. they have never been, and they will never be.

Is AF a serious AI dev?: Yes
Is Shard AF's AI?: Yes
Is it almost entirely in Lua?: Yes
Is the Shard dll mainly used for call routing and crap like that?: Yes
Do serious AI devs want to use Lua code in their AI?: Yes
Is hoijui nuts?: Mebbie

if all you need is Lua AIs, then use them, and ship your game without native AIs. that has been possible since years already (since there is Lua AI support). no reason for you to advocate the death of native AIs due to your limited viewpoint. stop wasting other peoples reading time.

Limited viewpoint? You need to check yourself. Apparently you forgot who you are talking to. I have been a huge supporter of AIs (native) for a very long time (feel free to ask krogothe how much time I spent with him finetuning KAI's behavior with EE). And time spent in helping AF test NTAI and Shard.

Here we get to the crux of why you're so damn butthurt. Get off your self righteous trolly and listen for a second. Spring is about making RTS games, not AI projects. It just so happens that the two tend to coincide to an extent, and it isn't a bad idea to have spring be open to AI developers making c++ ai's for coursework and crap. I don't believe I said anything about ripping support for native AIs out of the engine code. I DID however advocate removing native AI's from the engine installer. They most definitely should be removed.

AAI? Shit. Doesn't work with anything reliably and never really has (I'm sorry to say it like that, submarine, but it's true. Nothing personal intended, but everyone thinks this, jsut I happen to eb the only one saying it out loud :-/).

KAI? Dead. It more or less sucked after krogothe deleted all the sauce when he was drunk as shit one night and had to re-write it. Then he up and fucked off, and kloot tried to keep it going for a while, but it's dead. Barely works somewhat decently with BA.

RAI? Actually RAI tends to be the most flexible as long as you aren't using any advanced lua gadgetry and are using a metal and energy economy. Great for BA. Not so great for anything else (but at least it won't crash, sometimes).

Shard? Really good AI with some kinks, but doesn't matter in this discussion because it isn't included with the engine installer.

I think I covered them all (that are included in the installer). Yes, absolutely they should be removed from the engine installer and should have been many versions ago.

There has not been a single crash report of a native AI in 0.82.7 for BA.

Oh well, if it works with BA then it should definitely get special treatment.

I have encountered CRAIG being broken multiple times already in S44, that happens if someone changes the game, but not the AI, which yes! is possible also if they share the same code repository. If you compare, do it in a way it makes sense. Comparing the stability of a single game LuaAI to a native AI that is meant to play an other game but can technically be started with the wrong game too -> stupid!

I appreciate you 100% ratifying why the above AI's should be removed from the engine installer. You make a very convincing point.

Regarding the first part... If BA switched to a gadget economy, it would break kai and rai and etc, what's your point? At least a LuaAI doesn't have to be recompiled before it will work again, and it can be fixed in minutes/hours instead of waiting for days or weeks for some AI dev to fix it and be arsed to recompile it, and wait for a new spring version to come out so that the new ai is shipped with it and it works again. In the meantime, with the native ai you've sat for 6 months with your thumbs shoved directly up your ass.

Final comment @ hoijui: If you reply in a tone and content essentially calling me an ignorant asshole, you will in turn be treated like one. Disagree and state your claims in a somewhat civil manner, and we'll have a discussion without resorting to fighting like cavemen over a stick.

[KaiserJ]

some AIs are not compatible with some mods, could each AI ship with a "compatibility list" so new guys know for sure which AIs are intended for which game or mod

[knorke]

Imo it is not clever to include AIs in the installer but not to include any playable content.
Because what is the chance the additionally downloaded games or maps will work for the included AIs?
Compatibility lists would be nice but lobbies would have to display them too.
It is the same problem with game <-> map compatibility. Well, at least some maps have prefixes in their name.
But ideally those would have compatibility lists too.

[FLOZi]

Imo it is not clever to include AIs in the installer but not to include any playable content.
Because what is the chance the additionally downloaded games or maps will work for the included AIs?
Compatibility lists would be nice but lobbies would have to display them too.
It is the same problem with game <-> map compatibility. Well, at least some maps have prefixes in their name.
But ideally those would have compatibility lists too.

This is pretty much the crux of it. +1

One more comment on this

I have encountered CRAIG being broken multiple times already in S44, that happens if someone changes the game, but not the AI, which yes! is possible also if they share the same code repository.

Yes it has been broken multiple times, and fixed, by me - a commonplace mod dev, not any AI dev or even the original creator. Something that would not happen with a native AI.

[hoijui]

AF made his AI use Lua so mod devs can easily modify it, not because he is a serious AI dev. his AI is still a native AI, not a Lua one. you argument all gone.

I say, this community is here for mod devs, players, and AI devs (and others of course, which do not matter for this discussion). you say, it is here for players and mod devs only. do you know what part of the community has the highest chance of producing engine-dev offspring? would that still be the case if AIs could only be written in Lua? you wrong, me wright.

i did not read the rest of your post.

If downloading native AIs is as simple as getting a mod/map, it could be a viable alternative to the white-/black-listing only. though, the downloading way needs the same work to be done, plus more work on top of it, which is not little, so we do not even have to choose whether we want one or both, before one is not done yet.

[AF]

AF made his AI use Lua so mod devs can easily modify it, not because he is a serious AI dev. his AI is still a native AI, not a Lua one. you argument all gone.

That is not true.

I chose lua because it was a better candidate than TDF for a scripting language, and I wasn't keen on the competing scripting languages such as python or a java VM. Familiarity with lua among content devs may have been a note in ym dissertation but it was not the justification.

Why did I not make it purely in lua?

Because it would have limited me. No salvaging code from dead AIs, using C++ libraries etc Lua wise all I have are coroutines which are limited in comparison to the threads I made use of in NTai.

I say, this community is here for mod devs, players, and AI devs (and others of course, which do not matter for this discussion). you say, it is here for players and mod devs only. do you know what part of the community has the highest chance of producing engine-dev offspring? would that still be the case if AIs could only be written in Lua? you wrong, me wright.

Indeed, the one area of nonengine development that ahs given us the most new developers are:

Windows based Visual Studio AI developers....

i did not read the rest of your post.

If downloading native AIs is as simple as getting a mod/map, it could be a viable alternative to the white-/black-listing only. though, the downloading way needs the same work to be done, plus more work on top of it, which is not little, so we do not even have to choose whether we want one or both, before one is not done yet.

NTai for a long time was download only, and so were many of the versions of rival AIs. These managed to knock up thousands of downloads each for individual versions.



Put quite simply, the language you use to write your AI should not matter. Lua is perfectly capable of writing complex efficient AIs. You gain some stuff, and you loose access to a lot of very helpful things, but it didn't stop Supreme Commander having a lua AI, or many of the other commercial game engines with Lua AIs.


What I'd like to see:

• Better API versioning for native AIs
• Improved documentation
• The ability for AIs to add callins/callouts for gadgets/luaAIs. I should be able to let gadgets make calls such as Shard:HelloThar() in their gadget code
• Unsynced gadgets for Native AIs
• A way for AIs to blacklist themselves from games, whitelist, and everything else having an 'unverified' marker.
• API callouts to execute strings of lua code with returned values
• Better interface packaging, we're not all linux developers, and we're not all comfortable with pulling up a console and grabbing the latest and greatest and using cmake to build everything, sometimes we just want to load everything up, make a VS project file, and press build then test with the latest stable release.
  
  That's how it used to work when we had 5 longterm active AIs with smaller projects and more interest being shown, that's what we need to return to.
• The ability for LuaAIs to instantiate native AIs, be it to execute things like custom pathfinders and threaded algorithms, or native AIs that are more like the classic Native AIs
• Native AIs can send messages/requests to gadgets and get a reply, but gadgets cannot do the same thing
• Remove the dead AIs from the windows release installer.
• Move this thread to the AI forum

[smoth]

none of the ais have ever played gundam. even when it was using the engine's code. you had to cheat to make it work.

(not an invite, just putting that point out there.)

[hoijui]

native AIs have gotten more and more stable, not by accident, not by surprise, but because they are not dead, because they are still maintained.

out of the current engine devs, one is using windows (and VS), and he was not an AI dev before being an engine dev. two of the linux based devs came in through AI.

the old native interface is still available.

i though gadget => synced, widget => unsynced.
(as you mention unsynced gadgets)
these are already accepted, and i have put at least a little work in each one of them:

• direct widget <=> native-AI communication
• white-/black-blacklisting
• AI SDK(s)
• Better API versioning for native AIs

The ability for LuaAIs to instantiate native AIs
this is already possible (/aikill and /aicreate or /aicontrol, i forgot).

Improved documentation
This is the job of AI devs, as they see where it is missing, and they know what to put there much better then engine devs. Two AI devs have contributed there yet, and it was something like improving ~5 callback function comments each.

so the only pro argument for using Lua (other then the one i already gave), is that it is better then TDF...
you not knowing anything else then Lua and TDF is a good argument too of course, in your case, but not of use in a general way, as it is unlikely that dedicated AI devs (eg, studyign the subject in university) will know Lua but not any other (scripting) language. and it is not different from the argument i already gave (that it is known by content devs).

@FLOZi
native AIs are fixed by devs other then their creators all the time, also others then engine devs.

[FLOZi]

But not typically by content devs.

[AF]

I'm sure NTai was able to support Gundam back before the lua-ness was added and it started to rapidly diverge, though nobody took the time to complete the tasklists before this occurred.

Once the lua took hold, the official line was that no AI could play Gundams playstyle and the game was changing so fast any effort would be wasted, so i steered clear as advised.

you not knowing anything else then Lua and TDF is a good argument too of course, in your case, but not of use in a general way, as it is unlikely that dedicated AI devs (eg, studyign the subject in university) will know Lua but not any other (scripting) language. and it is not different from the argument i already gave (that it is known by content devs).

Krogothe learnt C++ building KAI, as did I, as did the author of SAI, and OTAI.

But even then, I could have built Shard in Java, or C#, both languages I'm competent in, both languages I had already sued for major projects. Heck I had NTai prototypes with Ruby embedded. I conducted plenty of research as part of my dissertation to justify the choice of lua and explore alternatives, and lua won out. There was even a chance Shard could have used javascript.

Experience with academia doesn't hold with your hypotyhesis either. Nor does common consensus about the ease of learning lua amongst content developers.


Bug reports

I'd make it clear that its highly unlikely that you will ever recieve bug reports for AAI. Players are notorious for not reporting AI bugs, and are much happier to declare the AI doesn't work to themselves and switch to a rival.

Eitherway there are plenty of people here complaining that AAI doesn't work. I've seen a lot of people say RAI doesn't work outside of TA for silly reasons, go ask Conflict Terra devs, ZK devs, or forb, RAI usually gets 80% of the way there but fails at some small but critical point.

Another example, there was a version of NTai were I made a mistake packaging it and uploaded and released without realising. By the time somebody told me, it had been several days and 1k+ people had downloaded and installed that version.

[hoijui]

the current AIs are made to work with BA, and some of them also with other TA mods. They are not dead, because they are still maintained for what they were written for. There is nobody working on making them work with other projects. We do get complaints that they are not working with other games at times. The problem is not, that we do not know what to fix, but that there is nobody working on this. This would be fixed/reasonably worked-around with the white-/black-listing.

ultimately, everything all of you complain about could be solved by work.
most or all of this work lies in my domain. as i am not very active these days, all this stuff will probably not come soon, except somebody else will do it.
constant repetition of shit does not make my motivation rise.
i have done a lot of big/heavy changes to the Java AI interface for .. practically a singe person, which did not yet release anything to the public, simply because he acted nice. he was reasonable, competent, offered help where he could, and generally acted in a way that makes sense when talking to someone that may do work for him for free. that means, everything you get is a gift, and you have no right to be angry if that work is not done, or done slowly.
a solution that makes things better for one group, and worse for an other group is not an acceptable solution. removing native AIs from the installer without other changes is an example for that. you can hope that someone (eg. lobby-devs & me) will code white-listing. you can do that yourself. you can create your own installer without the native AIs.
removing the native AIs from the general spring installer without other changes is not acceptable. stop asking for that, it will not happen. it should not happen.

@FLOZi
how many native AI devs have fixed LuaAIs yet?
what is your point? i don't remember anyone saying anything against LuaAIs being easier to maintain for game devs.

@AF
back in the days of drafting the new AI interface, you were advocating the use of Lua files for meta info for native AIs. my draft went without them. back then, my word was worth little here, as i was a newb. by now, from the start on, this Lua files based method was a pain in the ass, and though it is written by now, and reasonably stable, the design flaw is getting more and mroe obvious. it adds unnecessary complexity in multiple areas and disallows certain designs completely, adding nothing of value in practice.
Forgive me if i am skeptical of whether your choice of Lua is objective and unbiased.
I think your AI is good to have, and i think the choice of Lua there is good too, due to you and quite some game devs knowing it. But in general AI academia, it is no big player. A new AI dev, not yet a long time spring community member, willing to write a spring AI as a thesis, will most likely not use Lua, if he does not already know it, because he probably does care little about game devs.

[Forboding Angel]

you say, it is here for players and mod devs only.

WARNED.

[McLoud]

AAI used to work fine, but nowdays no one seems to make it plays more than a few minutes without crashes. I dont think its the language choice that matters for a good AI, and maintenance of one will only be kept working if you got people who knows about:
a) general understanding of the mods where they work
b) language on it is written (if you know C, native AI's should be a problem, ditto for Lua, C#, Java)
c) AI concepts in general
d) got a clue why it got broken in the first place

I tnink scripted/managed languages are kinda easier for non-devs since they require less effort to get working. You need to very (in)competent to make a Java AI not work in linux and vice-versa, maybe same for C# and virtually true for Lua and javascript
I think C/C++, Java and maybe C# got the best IDE support and that counts for me, but to each dev their tomatoes.

[AF]

the current AIs are made to work with BA, and some of them also with other TA mods. They are not dead, because they are still maintained for what they were written for. There is nobody working on making them work with other projects. We do get complaints that they are not working with other games at times. The problem is not, that we do not know what to fix, but that there is nobody working on this. This would be fixed/reasonably worked-around with the white-/black-listing.

ultimately, everything all of you complain about could be solved by work.
most or all of this work lies in my domain. as i am not very active these days, all this stuff will probably not come soon, except somebody else will do it.
constant repetition of shit does not make my motivation rise.
i have done a lot of big/heavy changes to the Java AI interface for .. practically a singe person, which did not yet release anything to the public, simply because he acted nice. he was reasonable, competent, offered help where he could, and generally acted in a way that makes sense when talking to someone that may do work for him for free. that means, everything you get is a gift, and you have no right to be angry if that work is not done, or done slowly.
a solution that makes things better for one group, and worse for an other group is not an acceptable solution. removing native AIs from the installer without other changes is an example for that. you can hope that someone (eg. lobby-devs & me) will code white-listing. you can do that yourself. you can create your own installer without the native AIs.
removing the native AIs from the general spring installer without other changes is not acceptable. stop asking for that, it will not happen. it should not happen.

@FLOZi
how many native AI devs have fixed LuaAIs yet?
what is your point? i don't remember anyone saying anything against LuaAIs being easier to maintain for game devs.

I bid you read this out loud again, but first, watch this video, and immitate connie marbles voice and tone when you say it for maximum hilarity

(apologies, that's how it turned out in my head and it was very entertaining, I know your being serious mind)

@AF
back in the days of drafting the new AI interface, you were advocating the use of Lua files for meta info for native AIs. my draft went without them. back then, my word was worth little here, as i was a newb. by now, from the start on, this Lua files based method was a pain in the ass, and though it is written by now, and reasonably stable, the design flaw is getting more and mroe obvious. it adds unnecessary complexity in multiple areas and disallows certain designs completely, adding nothing of value in practice.
Forgive me if i am skeptical of whether your choice of Lua is objective and unbiased.
I think your AI is good to have, and i think the choice of Lua there is good too, due to you and quite some game devs knowing it. But in general AI academia, it is no big player. A new AI dev, not yet a long time spring community member, willing to write a spring AI as a thesis, will most likely not use Lua, if he does not already know it, because he probably does care little about game devs.

Meta info should not have been effected by the native AIs lua, and would have separated AI from AI meta, keeping the two out of each others way, and leaving us with 1 consistent method that everybody knew.

Your unfamiliarity with the lua APIs may have made that slow, and indeed, I had slowdowns building Shard at first. I knew a little lua, I could defined data structures, but I'd had little practical application in the language. I had to learn much for building Shards lua component, but I learnt it, and it didn't take as long as you would expect, and many others have come to the same conclusion.

Just to be sure though, I've asked various people outside of this community whether moving to lua would be a mistake over more popular languages, and the response was unanimous:

"Moving to a different language won't make you more or less popular, it's what you build not what you build it in that matters more".


I would suggest given your reply then Hoijui, that you immediatly embark on a self documentation spree. The API is in the precarious hands of having a bus factor of 1. Should you leave or be struck down by some deity, how would you like your successor to view you? Frustration for having to pick everything apart, figure it all out, then rebuild from scratch in frustration, or praise for outlining the critical things and the overall structure, without it being a snap back forum post that gets buried after a week or two for nobody to see.

[hoijui]

... hae? :D

The AI Interface is the second best documented part of the spring engine, after the Lua stuff, and i did add quite some docu (what i was able to) to make that happen. I say again: improving it further has to be done by AI devs. If there is a function in the Callback of which i don't know what it does, i wont write a test AI to find that out and document it. The same thing applies for Tutorials. You guys know what one has to do in an AI to build the first solar in BA, i do not!

I may have had initial problems with the Lua API stuff, but that is not what i am talking about, and i would have had that with other APIs too, most likely more. Whether using Lua for the meta-info files is the best choice... i am not so sure, but i am sure that having the meta-info files in the first place is bad. the overall design of that is bad, as it is needlessly complex and limiting. it prevents a lot of design approaches for AI Interface plugins. While the complexity part was well painful enough (and this has nothing to do with the Lua API, but the design approach of using meta-info files), the limiting factor did not show up much so far, but now it leaks through at every edge.

• meta-info files are static: meta-info can not be added, removed or modified at runtime
• meta-info files are an alien thing to the Skirmish AI project structure (place, handling during release, language, documentation)
• meta-info files have to contain the project version, which is hard till impossible to integrate smoothly into a project release process that is not alien to the Skirmish AI project

stuff that is impossible (or would require very, very ugly hacks) because of this:

• pure Maven based Java AIs
• AI servers
• AI Interface plugin specific Skirmish AI resolving
• adding & removing AIs at runtime
• simplified/less engine internal and AI Interface plugin internal code for the AI Interface

just saying all this, to make sure you know that your idea caused and causes pain, actively, in my ass, while all you claim me doing wrong is actually only because of stuff i did not do (yet). and due to the nature of free contributions, you have no right to be angry at me for that.
I don't care about people that will think bad of me because of stuff i did not do (for them, for free, because they told me to do it a 1000 times!!!!11).

[Forboding Angel]

I say, this community is here for mod devs, players, and AI devs (and others of course, which do not matter for this discussion). you say, it is here for players and mod devs only. do you know what part of the community has the highest chance of producing engine-dev offspring? would that still be the case if AIs could only be written in Lua? you wrong, me wright.

i did not read the rest of your post.

Well maybe you should, cause then you wouldn't look so dumb when you accuse me of taking a stance opposite of what I did.

Thanks to behe fucking deleting the entire content of my post just because of the first line, I won't bother to repeat it.

I for one have a bit of a problem with this. AAI barely works with anything, and rai and kaik are really only good for *A clones. Why are these AIs distributed with the engine?

Edit: Removing bad punctuation.

Here we get to the crux of why you're so damn butthurt. Get off your self righteous trolly and listen for a second. Spring is about making RTS games, not AI projects. It just so happens that the two tend to coincide to an extent, and it isn't a bad idea to have spring be open to AI developers making c++ ai's for coursework and crap. I don't believe I said anything about ripping support for native AIs out of the engine code. I DID however advocate removing native AI's from the engine installer. They most definitely should be removed.

Note the giant red text for your emphasis.

*Sidenote* You may get special treatment form the mods because you're an engine dev, but you won't get it from me. Allow me to quote myself once more.

Final comment @ hoijui: If you reply in a tone and content essentially calling me an ignorant asshole, you will in turn be treated like one. Disagree and state your claims in a somewhat civil manner, and we'll have a discussion without resorting to fighting like cavemen over a stick.

Accusing me of taking a stance opposite of what I have taken and you can expect there to be some issues.

[hoijui]

a solution that makes things better for one group, and worse for an other group is not an acceptable solution. removing native AIs from the installer without other changes is an example for that. you can hope that someone (eg. lobby-devs & me) will code white-listing. you can do that yourself. you can create your own installer without the native AIs.
removing the native AIs from the general spring installer without other changes is not acceptable. stop asking for that, it will not happen. it should not happen.

who's looking dumb?
isn't that an answer to what you say i missed because i did not read the rest of your post? you just approved that of being a good decision.

[Forboding Angel]

Whether I can make an installer w/o the native AIs is completely besides the point. I believe that I made it perfectly clear why the Native AIs should be removed from the engine installer in previous posts.

Your counter-argument is , "Legacy legacy legacy".

Now explain to me, how I could possibly be the one with egg on my face given the proposed arguments?

What you haven't said is that you're worried that Native AI development will die if those are removed. My rebuttal is that if that is the case, then they were dead long ago and are now just decaying and being all smelly.