Messages

1

OXCE Builds & Ports / Re: [OXCE+] Lua Integration

« on: November 06, 2018, 11:03:42 pm »

Another update - I'm back!!! Okay, so my real job significantly took up more time than I had planned for, but that is the nature of game development. no, for the record, I had nothing to do with Red Dead Redemption so don't ask

New geoscape bindings are pushed up to github. I'm still playing with the API a bit more, so the usual preamble of future changes may break compatibility applies

2

OXCE Builds & Ports / Re: [OXCE+] Lua Integration

« on: October 05, 2018, 10:56:38 pm »

Just figured I would give an update since I've been silent for the last week. My day job has been rather demanding recently, but I haven't given up on the Lua integration. I will keep you posted once the new version is up on GitHub.

3

Work In Progress / Re: Random thoughts on external AI

« on: September 26, 2018, 11:11:42 pm »

They way most modern neural networks work is by defining training data and then building networks of decision trees. I've dabbled in some tensorflow network designs, and it takes a long time to get used to how it works, and get your mind wrapped around a lot of the concepts. However, someone with some experience could easily build a network in a few months time.

At it's most basic level, the neural network has a series of points to spend. Time Units are the currency of the game in Battlescape. Because of which, it actually becomes easier to define the network. You can spend those points by moving, attacking, throwing, or various other things, but it's still just a currency. Now, selecting the right thing to spend that currency on is the trick. First, you develop a hierarchy of networks. One for scouting(when no enemies are seen), another for attacking(for when an enemy is spotted), and maybe another one for retreating(for when forces are too strong), and perhaps a fourth one for regrouping. You train each of the sub-networks in isolation, then combine them for a more strategic AI that oversees it all.

For scouting, you define the success of the network by it's ability to find each enemy, and weigh that against defensive metric(have they ended up in a spot with a good defence ability, like behind a wall or in some smoke). For attacking, the success criteria is a lot easier, kill everything with minimal damage to your own units. For retreating, you have to get your units back to a point without killing them. And finally, for regrouping, the success depends on the ability to get everyone to a point with some defensive ability. Once you've trained each of the individual AIs, then you can easily train a strategic AI.

All of this is months and months of work. I won't have time to do this, but someone with some more interest in this could do it.

4

OXCE Builds & Ports / Re: [OXCE+] Lua Integration

« on: September 26, 2018, 10:25:18 pm »

That is definitely within the scope of the Lua work. You will be able to read and write the region data, so it's simply a matter of setting the colour of a region and then capturing when a craft is launched and changing the behaviour via overrides.

5

OXCE Builds & Ports / Re: [OXCE+] Lua Integration

« on: September 25, 2018, 11:59:07 pm »

Well, I would love to continue the neural network discussion, but today I'm back at my normal keyboard and so I've begun the process of making the interfaces generic and adding in a TON of hooks.

As for the next steps, I want to see if I can get some basic geoscape coverage of events. This includes the usual, onUpdate, on1Hour, on1Day, etc, but also events when the aliens decide to do things(onAlienBaseCreated, onSubMissionStarted, etc) and basic detection (onCraftDetected, onActivityDetected, onTerrorDetected, etc). I'm trying to find ways to make it so that it's possible to override default behaviour so you can skip the popups that come up in a mod.

For instance, I made a quick script today that automatically finds the nearest base for when an alien craft is detected, and if the sub has weapons, has fuel, and isn't damaged, it sorts all subs matching the criteria and selects the one with the highest damage per second. It then allows me to add a button to the detection screen to auto-deploy the craft. That last part I'm still working on.

6

Work In Progress / Re: Random thoughts on external AI

« on: September 23, 2018, 11:48:11 pm »

Getting a little off topic here, but I don't see a technical problem building a neural network, although it would take a lot of effort.

Step 1) Gather as many events and store every action that a user, and the existing AI take
Step 2) Use that to train a generative neural network to simulate both the user and the existing AI.
Step 3) Take both AIs and pit them against each other(adversarial generative neural network).
Step 4) Let it run continuously for a looooooong time. Meanwhile, keep feeding it new playthroughs and more data. Maybe pausing it every week and playing it to make sure it is on the right track.

The biggest problem I see is that you would have to build your network in Lua. Problem with that is that there are so many other better tools out there for building deep learning networks and, well, it would be hard to compete with that. You could, with source, make it so that you can use Tensorflow or one of the other machine learning toolkits, so, to get back on topic and answer the original question...

If you know how to do all the above, then yes, you can build a neural network AI that would obliterate even the best players, but if you know how to do all the above, then I doubt you would want to use Lua to do it. So, yes, you could, but why?

7

Work In Progress / Re: Random thoughts on external AI

« on: September 22, 2018, 10:21:12 pm »

With this Lua support, would it be possible to affect the AI decisionmaking by outside software (like neural networks)?

So are you looking to completely replace the AI, or merely hook in to the existing AI and tweak things?

@Whispers: called it

Yes, yes you did. No, this will not allow you to do any networking at all. Networking is my day job and I'm not sure I want to spend my evenings doing my day job... unless you guys pay me... A lot of money 

8

OXCE Builds & Ports / Re: [OXCE+] Lua Integration

« on: September 19, 2018, 11:26:42 pm »

Yeah, event binding needs to be done in Lua to get the pre-indexed function ref. Also allows you to reference nested functions inside tables without the need for writing a function string to lua function ref, err, function.

Basically, if you did the function binding in rules, then I would have to parse out the function name. If the function name was global, like "on1Hour" was in the example, then it's easy, but if the function sits withing an object, then it would need to know what was on the stack prior, so something like "MyTable.on1Hour" would be possible, and "MyTable:on1Hour" would need to be handled as a special case. I'm lazy, so I didn't want to do that

On that topic, the call to get the game pointer as it is is slightly more expensive than using a function metamethod table. I might move that direction in a future revision, but having one, and only one userdata object in the xcom table made sense when I first started this. In fact, now that I think about it a little more, with the recent change where I split out the LuaGeoscapeBinding class, I might as well create a LuaGeoscapeApi class and use that for the metamethod table and store the game object there.

Edit: but it's not an optimisation, so much as it is cleaner for the API user

9

OXCE Builds & Ports / Re: [OXCE+] Lua Integration

« on: September 19, 2018, 10:06:00 pm »

Would be possible to get ride of `getGameFromLuaState` and use some kind of `this` pointer?

What if someone replace `Game` in that global variable? I think only way it could work properly is have only one type available in user data.
Some thing like this:

And `GetPointer` will be only way to get OXCE data from lua. This will allow checking for correct type and even allow encoding const in typeless language.
I used similar trick in my script engine.

Well, firstly, I'll be moving "xcom.__self"(the game pointer) to private metadata ASAP(or stick it directly in the registry, a hidden area accessible only to C/C++). Once I do that, I can set the access patterns(making it protected, hidden, and read only - http://lua-users.org/wiki/MetatableEvents), but I just wanted to play around with it and make sure I set it up correctly, so leaving it public for now just allows me to see it. At this moment, it's the only user object I plan on implementing, but once I get to the point where we are implementing local callbacks for objects, then yeah, I'll need to be more careful.   

There is no concept of "this" in Lua. Everything is done on a stack, so while it would be possible to create userdata objects in every metatable for use as an object pointer in C/C++, that is a lot of objects I don't think are necessary at the moment.

Also, the type is stored in the metatable(referenced as "Game") so there is type checking already available by using luaL_checkudata, but for brevity sake, just getting things in and testable is my first goal. Using a wrapper class is a bit extreme for now, but I will likely move to that eventually. Using luaL_checkudata is much better since it is already built in to Lua, just didn't spend the 2 secs to put that in. I'll do that now.

Another thing is existing of `lua_gameGetFunds` and `execute1HourCallbacks`, in both cases it should be generic function that is responsible for boilerplate.
You can compare it to `ScriptBind.h` that I used for this. In best case I could add `so.add<&getRankScript>("getRank");` that convert normal C++ member function to special function that obey my "calling convention".
With this and `Get<T>` you can build one generic function that will convert and check prams before there are send to original C++ function.
Similar case when you call Lua scripts.

Oh, that's exactly where I am going with this, but one thing I know about playing with templates is you ALWAYS want to have a working non-template version before you start wrapping things in nested template classes to make debugging and diagnosing issues easier. Today was hectic at work so I didn't get the chance to start the work on moving over to making it more generic and adding in the required templates. I do plan on showing off a little and using the variadic templates to allow for multiple parameter passing to script execute functions

[ps]
one picnicking: OXC use tab for indents and it would be good to stick to it.

Yeah, problem is when I switch from my laptop to desktop they both have different settings which aren't synced at the moment. I'll switch it to tabs for the next checkin

--- posts merged, please don't double-post ---

Sorry about that. I'll edit existing posts in cases where I was the last post

Yankes, I just saw the github comments. Just FYI that all github emails go to my spam folder.

To answer your question on github, yes, scripts are only ever loaded and executed once during game load. Their context is persisted though, which means that they have to register callbacks or else no part of the script will be run again, as such, yes, they are loaded from disk every time they are run, but they are only ever run once as a normal script. That was/is intentional.

10

OXCE Builds & Ports / Re: [OXCE+] Lua Integration

« on: September 18, 2018, 10:23:20 pm »

I'm loosely shaping the API by the save game structure, so the xcom.soldiers api is a bad example(cause soldiers could be in a craft, in a base items list, in transfer, or on the battlescape somewhere.)

But yeah, I see your point

--- posts merged, please don't double-post ---

Updated OP with more details on progress

11

OXCE Builds & Ports / Re: [OXCE+] Lua Integration

« on: September 18, 2018, 08:43:29 pm »

So far all events I have planned are global events. I can see circumstances where you want to "only run this function on this particular instance of an object" , but that would be too intrusive for a first pass API. I'd have to go in and modify every spot where an instance of an object is created and either do multi-inheritance to a common base class which holds the necessary functions to allow binding functions to that instance, or I'd have to do some other method of allowing local instance callbacks which would touch more files than I would like to at the moment.

I think for the first version I will only have global events. Things like xcom.geoscape.register5SecCallback, xcom.battlescape.registerTurnBegin and even xcom.geoscape.registerUpdateCallback for those needing frame to frame updates. For other things, like xcom.soldier.get(soldier).registerDamageCallback(), I don't think the initial API will handle it like that. Instead, you could have something like xcom.soldier.registerDamageCallback() which takes a function that has a parameter for which soldier was damaged. It covers the same use case, but perhaps not as cleanly because you'd get that callback for EVERY soldier that receives damage instead of one specific soldier.

has<x>Callback and clear<x>Callback appear to be okay, so I'll move forward with that idea for now.

I'm still toying with ideas on how to architect the API that is less intrusive on the engine, yet allows controlling as much of the underlying data as possible.

12

OXCE Builds & Ports / Re: [OXCE+] Lua Integration

« on: September 18, 2018, 04:49:49 pm »

and Yeah, I know you were just giving an example, just pointing out that in this instance, its already there.

The point was not to showcase new features, but how I go about building the API functions.

13

OXCE Builds & Ports / Re: [OXCE+] Lua Integration

« on: September 18, 2018, 03:18:56 pm »

Ugh, I'm not really happy with the "register callbacks" mechanism. It lacks a certain grace that I usually like my APIs to have, but I simply can't think of a better way to deal with it.

Scenario:

As a mod developer, I want a show, every day in game time, my current funds

Solution:

Using the register callback mechanism, you can specify a lua function to be called. Something like this:

Code: [Select]

function on1Hour(gametime)
  print("Your current funds are " .. tostring(xcom.game.getFunds()))
end

xcom.geoscape.registerOn1HourCallback(on1Hour)

Now, every hour, on the hour, the function will be called. If you try to register more than one function, then it will simply overwrite whatever callback you had previously. Perhaps I should return the previous function? Maybe set it up so there is a has<x>Callback and clear<X>Callback? Hmmm, I'm not sure. I need to get this right because the callbacks are the key to the whole API.

14

OXCE Builds & Ports / Re: [OXCE+] Lua Integration

« on: September 18, 2018, 12:22:00 am »

Quick question to @Yankes and @Meridian.

What are your thoughts on std::shared_ptr and std::unique_ptr, etc?

Reason I ask is because it would make a large portion of the Lua code a lot easier. Instead of having to check for invalid inputs, I can guarantee a pointer will never be null simply by increasing a reference count.

It's not necessary, but thought I would ask.

15

OXCE Builds & Ports / Re: [OXCE+] Lua Integration

« on: September 17, 2018, 11:06:07 pm »

`std::tuple` for rescue ;P

Where's my hammer? I've got to knock some sense into...

But for more serious answer, pair or tuple are good as implementation detail, not as public interface. Adding name give greater meaning to code that some random pack of values.

Oh, okay, I'll put my hammer away now.