Messages

1

OXCE Builds & Ports / Re: OXCE Lua

« on: June 19, 2024, 03:03:58 am »

Update:

Right, there's been some big modifications to the original source. Maxmahem has graciously offered to help move towards a more Entity Component System compliant code base. The reason why is that we need handles to objects so we don't have to manage the object lifecycle as much on the Lua side. I've started working on the UI side, wrapping all the interface objects and converting those over to composable elements(components) to make things easier when translating to and from Lua.

Overall, this is shaping up to be a huge refactor.

I have a branch that I've been toying with where I take the Lua bindings and I redirect it to a json serializer. I open up a plain old TCP socket and I accept basic HTTP GET and POST commands which basically means I can now edit anything that is exposed to Lua through a web page. It's actually something I've done for a lot of projects I've worked on, and it greatly helps test and diagnose issues. I'll probably merge that in to the Lua branch soon, although it has very little to do with Lua.

Would love to get your thoughts on these changes. Feel free to leave feedback here, or on the repo, any time!

2

OXCE Builds & Ports / Re: OXCE Lua

« on: June 09, 2024, 11:02:13 pm »

And where was this memory leak? I recall couple of places where someone copy vector but in any of this places was no memory leak as objects from vector lived lot longer. And even more, original vector should not be changed in that case too.

My bad, upon further review it appears as though the array copy was erroneous, but it wasn't deleting from the copied array. It was roughly line 2511 of BattlescapeGame.cpp. Mine looks a lot different then yours will, but something like this:

Code: [Select]

bu->removeSpecialWeapons(_save);
std::vector<BattleItem*> invCopy = bu->getInventory();
for (BattleItem* bi : invCopy)
{
_save->removeItem(bi);
}

bu->setTile(nullptr, _save);
_save->clearUnitSelection(bu);
delete bu;

3

OXCE Builds & Ports / Re: OXCE Lua

« on: June 07, 2024, 08:13:38 pm »

1. We intentionally didn't target YAML-CPP repository, because we (both OXC and OXCE) had a lot of negative experience with that. Many YAML-CPP versions (for example v0.5.2 or v0.7.0) simply don't work with OpenXcom. It was broken for months, sometimes years long at times. (Situation with SDL is even more complicated. For some builds, e.g. Android, we've even forked SDL repo.)

That's the beauty of FetchContent within CMake. We can specify the exact commit or tag that needs to be synced. I wanted to go this route as it cleans up a lot of potential compilation issues.

2. FYI, OXCE doesn't use OXC github CI builds (yet). Developers (incl. OXC developers) use MSVC project. Our build servers use also other build methods beside cmake. Not to mention Android/iOS builds, which use yet more methods.

That's fine. I've given up on this ever going upstream. If I am going to need to maintain a forked repo for the long haul, then I need to set things up in a way that makes it easier for me. OXC and OXCE both have stated missions of keeping the gameplay as core to the original as possible(with quite a few exceptions), and I completely understand and agree. My goal is different. I would like to see all sorts of crazy modifications that don't necessarily align with the goals or limitations of the current systems.

Packaging for Android should actually be easier now, as CMake as native support for that, and it has integration in Visual Studio.

It should be noted that CMake isn't REALLY a build system, but a build system generator. It can output VS Projects, Makefiles and more. I did go through the effort of getting the FetchContent stuff to work with VS Projects, but it took an entire afternoon of hacking together batch files and other means that just didn't make the code any better.

4. Not sure why you talk about laziness. "Auto" was added intentionally, before everything was without auto, now auto is used where we think it's appropriate. I've also made some cleanups myself (e.g. 9a90fab4372841b387319900993d0267251db18b) and right now both Yankes and I are happy with the current state. If you have a different preference, it's fine, but calling us lazy is a bit rude. If you've found any potential bugs, please report them.

Oh my. I completely apologize! I've been running on very little sleep and that slipped out while I was typing up all the notes. My sincere apologies! I've removed it from the post.

Personally, I really dislike the auto keyword, and there was one situation where the code was dereferencing a pointer to a vector and assigning it to auto, which copies the vector. Then, immediately underneath, it was iterating through the elements and deleting them, then clearing the newly created array, meanwhile leaving the parent array full of pointers that led to deleted memory. That example comes to mind, but I'd have to dig to find it again. I've literally changed a huge chunk of the codebase by now, so finding it will take me more than a cursory glance at the commits.

Ah man, now I feel bad about the "lazy" comment. This isn't my first time on these forums, but still, it's been long enough that this is basically a first meeting, and I completely screwed it up. Sorry about that Meridian.

4

OXCE Builds & Ports / OXCE Lua

« on: June 07, 2024, 03:23:35 pm »

Hey,

That's right, I've started it.

https://github.com/ken-noland/OpenXcom

How it works

I've modified Game and Mod so that they take in a ModFile class which contains a list of all the mods active and are in the correct loading order. Once Mod has finished loading, then I load up LuaMod which goes through each metadata.yml and checks to see if there is a tag for a lua file in there. The metadata should look like this:

Code: [Select]

#
# metadata.yml for Lua Test

name: "Lua_Test"
version: 1.0
description: "Verifying the callback mechanism works"
author: Whispers
master: xcom2
lua: bootstrap.lua
Once it sees the "lua: bootstrap.lua", then it knows this is a mod which uses the new Lua stuff. Once that is detected, it uses the path to the mod, then appends the lua filename, then loads the Lua file. A couple of things to note here is that I don't think this will work for zipped up files in its current state, but that may come later. In fact, I'll post a bug on the repo so I know I will catch it at some point. The other thing to note is that I've overriden the Lua print and redirected it to log, so anything you print, or any Lua errors, will get output to the game log.

Once loaded, it is executed once, and only once. It's up to the mod to register events.

Code: [Select]

function onLoad(doc)
print("the above 'doc' contains the entire save state converted from YAML to Lua Tables")))
end

game.on_load_game:register_callback(onLoad)
There will be more hooks, but I had to start somewhere. Once the game is loaded, then things become more interesting. "game.base" becomes available, which I'm currently working on. On the C++ side, I've been working on how to simplify the registration of events and callbacks, as well as how best to expose the data. I've come up with a mechanism which allows a programmer to register a container and the LuaApi does the rest, but it's still very early at the moment.

And that brings me to the current status. All the Lua stuff does at the moment is likely to change. For instance, 2 days ago I was designing the api to use getters and setters, but that's not necessary Lua. Want to change a soldiers name? Just set it in Lua and then you're done. Err, at least that's the idea anyway. Want to send a message to another mod? Sure, I'll get to that eventually. Cross mod communication is definitely on my agenda. My first priority is setting up the API and exposing as much as I can.

So, there are two types of callbacks, at the moment. Events and Accumulators. Events fire off just like you would expect them to. Things like onLoad and onSave or, when I get around to it, onTick are all events. They fire off with parameters that be be read by the Lua state. Most events fire off for every mod that registers a callback, but a handful of events can be consumed. When an event is consumed by the callback, it does not fire off for the next mod and it could also stop the default behavior in C++. Accumulators are a bit different. The first parameter for an accumulator callback is the result of the previous accumulator(or the default value). The accumulator must return a value which is passed to the next one or sent to the game.

The framework for Lua is mostly there. The Api has started to take shape. I'm very hopeful that this time around it will be an official release.

Big changes

This does introduce some changes that I feel are necessary.

1) YAML is no longer required in the binary dependencies. I would also like to get SDL removed, therefore removing all binary dependencies altogether, but... time...
2) I've dropped support for the old MSVC Project, Makefile and I will not be supporting any other build system other than CMake. Reason why is because in order to grab the YAML and (in the future) SDL stuff and build it, I use CMake for that. There's also a strong argument that if you are developing on something that is shared, then you should all be using the same process that is used to trigger the nightly builds.
3) I've squashed over 800 warnings from build the x64 version, but more are coming. I basically squash them as I'm building.
4) I've been slowly but steadily removing the "auto" from the variable declarations. In the process, I've found a TON of potential bugs and issues and fixed them as I went along. Far too many to list here.
5) I've exposed a getGame function callable from anywhere. I hate singletons, but in order to get the hooks where I needed them to be I need to get the Game*. Now, singletons are evil, but there is an alternative called Thread Local Storage. Not that it matters, due to how many other globals are floating around, but theoretically, you could fire off different Game objects on different threads. This keeps things nice and tidy for the future.
6) You need to have a C++20 compiler now

Backstory: A long time ago I started on working with integrating Lua into OpenXcom. At the time, I was basically told the change was not wanted by the authors of OXCE, so I abandoned it. This time around, *I* wanted the change so I could implement some custom logic without having to touch the source. It's taken me the last two weeks to get it up and running again, but this time it's far more powerful than before.

Next Steps

Continue implementing more events, exposing more data and fleshing out the API. Specifically, the next API I am working on is for UI.

I haven't even defined what a release looks like. I'd love to get your feedback and thoughts.

5

Programming / Local Llama3 Integration

« on: May 25, 2024, 04:21:52 pm »

Hey,

A while back(several years ago) I wrote some stuff for OXCE which enabled some Lua modding, but it wasn't well received so I abandoned it.

Lately I've been toying with the idea of using a local Llama3:8b LLM model for some limited scope stuff within Xcom. The first, and most obvious one, is the council notices at the end of the month. Instead of it being some bland text which is always the same, I was thinking it would be cool if it could reference what happened during the month, and the results of those actions. Not everything, of course, but just the highlights. Even cooler, imagine if it would read it to you with a similar voice of the Spokesman in Firaxis Xcom, but maybe attenuated and made in 8 bit audio.

Unlike the Lua stuff, where I just went off and did it, then was told it wasn't going to make it into mainline, I wanted to ask before beginning work on something like this.

So the way it would work is fairly straightforward. If you have the option enabled and the address and port to the Llama instance set, then it would work. Otherwise it would fall back to using the same bland text we have seen for decades now. If it is enabled, then it would feed all actions you have performed over the past month, how those actions have changed your political standing within governments, and some very simple prompt engineering to make the report sound like it is coming from the Spokesman, then viola! You have a custom report at the end of every month detailing your progress and standing within the governments. It's possible to take this a step further and enable a conversation with the Spokesman, but I kinda feel as though that would diminish the feeling of finality of the end of the month report.

To do the voice encoding, it's possible to train up something with Piper(https://github.com/rhasspy/piper). Once again, making it optional. If you have piper installed, then we could provide it with a model and text to read, and that's it. You'd have in game text to speech that would sound similar to the Spokesman.

What are your thoughts?

6

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

7

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.

8

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.

9

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.

10

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.

11

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?

12

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 

13

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

14

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.

15

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