1
Work In Progress / Re: scripting
« on: March 21, 2012, 09:52:37 pm »
I have merged the master branch in swigX and rebuild the windows installer: https://gchevallereau.net/guillaume/openxcom/OpenXcom_python-0.3-win32_2012_03_18.zip
Welcome, Guest. Please login or register.
Did you miss your activation email? April 23, 2024, 12:15:15 pm
Did you miss your activation email? April 23, 2024, 12:15:15 pm
News: If you can't login, please contact us with your username and e-mail so we can fix it.
Show Posts
This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
2
Work In Progress / Re: scripting
« on: March 20, 2012, 02:48:22 pm »
Not that much. I do not have enough time at the moment to go any further and It's not really needed at the moment.
Don't forget that this was more a try than a proper support. I do not plan making any "real" development on this now. Maybe later. And it will more a way to figure how to shrink the size of binded API and maybe how to really solve remaining issues (handler for events for examples).
I will update the build and the branch soon with the latest changes from master. So people can still give it a try.
Don't forget that this was more a try than a proper support. I do not plan making any "real" development on this now. Maybe later. And it will more a way to figure how to shrink the size of binded API and maybe how to really solve remaining issues (handler for events for examples).
I will update the build and the branch soon with the latest changes from master. So people can still give it a try.
3
Open Feedback / Re: Difference between X-Com and OpenXcom
« on: February 24, 2012, 10:43:39 pm »Quote
Must be a fault in the ruleset data, soon you will be able put the sales price as high as you want by editing the ruleset file.It's just a development leftover. When doing manufacturing, I made some tests with selling price and I didn't fix all ruleset settings when finished. For example, just try to manufacture a laser rifle.
4
Programming / Re: Man Page
« on: February 18, 2012, 12:41:15 pm »
as i have said, it's not hard to make the build of the man page optional, so xmlto wouldn't be a required dependency.
IMHO, we should treat it like doxygen. You can perfectly build openxcom without doxygen installed, because we check for it's presence and only add needed rules to generate documentation if it was found. man page should be handled the same way.
IMHO, we should treat it like doxygen. You can perfectly build openxcom without doxygen installed, because we check for it's presence and only add needed rules to generate documentation if it was found. man page should be handled the same way.
5
Programming / Re: Man Page
« on: February 17, 2012, 09:44:20 pm »Quote
In git should exist groff and xml. But, of course end user need only groff file. Just keep it up-to-date after each change made in xml-file.I disagree. There should be only the XML file:
- it's really easy to check for the presence of xmlto in both CMake and autotools.
- if there are both version, you can be sure that one day:
- someone will edit the generated file.
- someone will forgot to update the generated file after making a modification
6
Work In Progress / Re: scripting
« on: February 09, 2012, 11:16:49 pm »
Hi,
So i have now a version of OpenXcom which allow to create custom screen and game logic. You can find the code here: https://gchevallereau.net/cgit/cgit.cgi/OpenXcom/log/?h=swigX
Before introducing those modification, I want to explaing how the OpenXcom SWIG/python bindings work.
Before starting with OpenXcom, a little explanation on how swig work. swig parse the source code and output two kind of files.
* First a language specific(python here) which contains exported definitions.
* Second a really big C++ file(more than 145000 lines for OpenXcom!). This file is a glue code between C++ and the target language. In our case this file is built as a python module.
To parse the source code, swig need an input file. Most of the work is to write this input file. Now, if you look at the swig branch, you won't find it. I use CMake to auto-generate it.
If you look at the swig branch you will see that a lot a of file has been modified, but most of the modification are to build a libOpenXcomBase(Windows dll stuff). This library is needed to build the python module.
The python stuff is not that big. Only two files:
* python_out.cpp: A python module used to redirect the python stdout and stderr to the python console
* python.cpp: The main python interface. This file contains the two function used to execute python code(runPython and runPythonString). Also contains initialization and clean up code.
So how the custom State work?
to allow redefining state, i had to change the way state are created. Instead of directly creating it, we ask a StateFactory to do it. State are created using an instance of a StateInfo class. So in C++ we have:
and when we need to instantiate it:
Another problem was the handling of callback function for events. They are at the moment pointer to class members. SWIG is not able to bind this. The solution was to create children class in python and reimplements event handling in those class. You can see that in Button for example are all PythonTextButton instead of TextButton.
game logic:
The implementation is quite similar to the custom state. There is GameLogic base class and a GameLogic manager. In python we can redefine child class of GameLogic and then add it to the GameLogicManager. They will be automatically handled.
Implementation note: I haven't changed all the code. Only the Research/Production State can be redefined. The same goes for GameLogic, new GameLogic elements can be added, but only craft repairing can be replaced. I do not plan to change this at the moment.
I put a windows build here: https://gchevallereau.net/guillaume/openxcom/OpenXcom_python-0.3-win32.zip
You can find some example script here: https://gchevallereau.net/guillaume/openxcom/scripts.zip. This zip contains 3 scripts:
* research.py: replace the Research screen
* repair_engineer.py: replace the craft repairing game logic. Craft can be repaired faster if you have available engineers.
* autosell.py: replace the production state to allow automatic selling of production.
Just unzip this file and copy all script to the python/auto-start folder.
Have fun!
So i have now a version of OpenXcom which allow to create custom screen and game logic. You can find the code here: https://gchevallereau.net/cgit/cgit.cgi/OpenXcom/log/?h=swigX
Before introducing those modification, I want to explaing how the OpenXcom SWIG/python bindings work.
Before starting with OpenXcom, a little explanation on how swig work. swig parse the source code and output two kind of files.
* First a language specific(python here) which contains exported definitions.
* Second a really big C++ file(more than 145000 lines for OpenXcom!). This file is a glue code between C++ and the target language. In our case this file is built as a python module.
To parse the source code, swig need an input file. Most of the work is to write this input file. Now, if you look at the swig branch, you won't find it. I use CMake to auto-generate it.
If you look at the swig branch you will see that a lot a of file has been modified, but most of the modification are to build a libOpenXcomBase(Windows dll stuff). This library is needed to build the python module.
The python stuff is not that big. Only two files:
* python_out.cpp: A python module used to redirect the python stdout and stderr to the python console
* python.cpp: The main python interface. This file contains the two function used to execute python code(runPython and runPythonString). Also contains initialization and clean up code.
So how the custom State work?
to allow redefining state, i had to change the way state are created. Instead of directly creating it, we ask a StateFactory to do it. State are created using an instance of a StateInfo class. So in C++ we have:
Code: [Select]
class MyState : public State
{
};
class MyStateInfo : public StateInfo
{
};
REGISTER_CREATOR("MyStateId", MyStateInfo); https:// automatically append it to the StateFactory
and when we need to instantiate it:
Code: [Select]
State * s = _game->getStateFactory ()->createState("OPENXCOM_RESEARCHSTATE",
args);
This downside, is that when creating a state we usually need to pass some arguments. As we have no base class for thing in Ruleset or Savegame, I have used a little hack. All arguments are void * pointers. If it's not really the cleanest way to do it, it actually work great.Another problem was the handling of callback function for events. They are at the moment pointer to class members. SWIG is not able to bind this. The solution was to create children class in python and reimplements event handling in those class. You can see that in Button for example are all PythonTextButton instead of TextButton.
game logic:
The implementation is quite similar to the custom state. There is GameLogic base class and a GameLogic manager. In python we can redefine child class of GameLogic and then add it to the GameLogicManager. They will be automatically handled.
Implementation note: I haven't changed all the code. Only the Research/Production State can be redefined. The same goes for GameLogic, new GameLogic elements can be added, but only craft repairing can be replaced. I do not plan to change this at the moment.
I put a windows build here: https://gchevallereau.net/guillaume/openxcom/OpenXcom_python-0.3-win32.zip
You can find some example script here: https://gchevallereau.net/guillaume/openxcom/scripts.zip. This zip contains 3 scripts:
* research.py: replace the Research screen
* repair_engineer.py: replace the craft repairing game logic. Craft can be repaired faster if you have available engineers.
* autosell.py: replace the production state to allow automatic selling of production.
Just unzip this file and copy all script to the python/auto-start folder.
Have fun!
7
Programming / Re: Research developement
« on: January 27, 2012, 12:38:32 am »
It should be really simple. The needed modifications should be:
* Transform the bool flag to a list in RuleResearchProject
* Change the SavedGame::getAvailableResearchProjects function to check a list of items instead of just one.
If we do it, it might even be interresting to set a number of needed items, and maybe if they should be consumed. We can image that scientist need to disasemble items to understand it. So your example could become:
* Transform the bool flag to a list in RuleResearchProject
* Change the SavedGame::getAvailableResearchProjects function to check a list of items instead of just one.
If we do it, it might even be interresting to set a number of needed items, and maybe if they should be consumed. We can image that scientist need to disasemble items to understand it. So your example could become:
Code: [Select]
- name: STR_PLASMA_RIFLE
cost: 700
prereqItems:
- STR_PLASMA_RIFLE:
- needed: 3
- destroyed: true
prereqResearch:
[]
unlock:
[]
8
Work In Progress / Re: scripting
« on: January 22, 2012, 06:21:30 pm »
I finally got a working windows build. You can get it here:
https://gchevallereau.net/guillaume/openxcom/OpenXcom_python-0.3-win32.zip
Once in game, you can press F6 to show/hide a python console. This console is fine for short tests. If you are going to try some longuer experiments, you can save your code into a file and drop in My Documents(Windows) or /tmp(Linux). The file must be named run_openxcom.py.
Here are some explanations on how to use it. The first thing you want to do is to import the python module and get the main game reference:
If you are not familiar with the OpenXcom code, the savedGame will give you access to most of game elements(Bases, funds, ...), the game is needed by nearly anything and holds resources and Ruleset elements.
Functions/Class have the same name than in C++, so you can use the doxygen documentation. However some of them are not yet binded.
Here are some example:
Going bankrupt:
Starting a battlescape mission:
This one is bit longer
Peoples who have already read the OpenXcom code, should understand this without any problems (This heavily inspired from the Battlescape quick test code which is in the Geoscape).
I have some other ideas, which will require some changes to the OpenXcom code:
* Allow to create custom interface for some Game screen(research,manufacture,...)
* Define custom battlescape items
* Allow to define game logic elements(Automatic selling of manufacture for example)
https://gchevallereau.net/guillaume/openxcom/OpenXcom_python-0.3-win32.zip
Once in game, you can press F6 to show/hide a python console. This console is fine for short tests. If you are going to try some longuer experiments, you can save your code into a file and drop in My Documents(Windows) or /tmp(Linux). The file must be named run_openxcom.py.
Here are some explanations on how to use it. The first thing you want to do is to import the python module and get the main game reference:
Code: [Select]
import OpenXcom
game = OpenXcom.getGame
savedGame = game.getSavedGame()
If you are not familiar with the OpenXcom code, the savedGame will give you access to most of game elements(Bases, funds, ...), the game is needed by nearly anything and holds resources and Ruleset elements.
Functions/Class have the same name than in C++, so you can use the doxygen documentation. However some of them are not yet binded.
Here are some example:
Going bankrupt:
Code: [Select]
import OpenXcom
savedGame = OpenXcom.getGame().getSavedGame()
savedGame.setFunds(0)
# Or get more money. But this cheating. This is bad
savedGame.setFunds(99999999)
Starting a battlescape mission:
This one is bit longer
Code: [Select]
import OpenXcom
# Start a battlescape terror mission
g = OpenXcom.getGame()
sg = g.getSavedGame()
sbg = OpenXcom.SavedBattleGame()
bases = sg.getBases()
base = bases.front()
crafts = base.getCrafts()
craft = crafts.front()
sg.setBattleGame(sbg)
bg = OpenXcom.BattlescapeGenerator(g)
bg.setMissionType(OpenXcom.MISS_TERROR)
bg.setWorldTexture(1)
bg.setWorldShade(0)
bg.setCraft(craft)
bg.run()
battlegame = sg.getBattleGame()
battlegame.resetUnitTiles()
battlescape = OpenXcom.BattlescapeState(g)
g.pushState(battlescape)
Peoples who have already read the OpenXcom code, should understand this without any problems (This heavily inspired from the Battlescape quick test code which is in the Geoscape).
I have some other ideas, which will require some changes to the OpenXcom code:
* Allow to create custom interface for some Game screen(research,manufacture,...)
* Define custom battlescape items
* Allow to define game logic elements(Automatic selling of manufacture for example)
9
Work In Progress / Re: scripting
« on: January 18, 2012, 09:05:52 pm »
Will do. I first need to fix some problems on Windows. But i have some ideas of example scripts
10
Work In Progress / Re: scripting
« on: January 13, 2012, 11:50:21 pm »
I have pushed my branch here : https://gchevallereau.net/cgit/cgit.cgi/OpenXcom/log/?h=swig
Some explanations on the build:
* You must use CMake. It should work on both Linux and Windows(Visual Studio)
* You will need swig and python. I have put a ZIP file of all needed dependencys here: https://gchevallereau.net/guillaume/openxcom/deps_vc.zip. If you use it, you can only build in release and relwithdebinfo(python debug lib is not in the zip file)
Once built, you have two options to use it:
* put a script in /tmp (Linux) or in My Documents (Windows), the file must be named run_openxcom.py. Note: the file will be removed once runned.
* press F6, you can now type python code directly.
Some explanations on the build:
* You must use CMake. It should work on both Linux and Windows(Visual Studio)
* You will need swig and python. I have put a ZIP file of all needed dependencys here: https://gchevallereau.net/guillaume/openxcom/deps_vc.zip. If you use it, you can only build in release and relwithdebinfo(python debug lib is not in the zip file)
Once built, you have two options to use it:
* put a script in /tmp (Linux) or in My Documents (Windows), the file must be named run_openxcom.py. Note: the file will be removed once runned.
* press F6, you can now type python code directly.
11
Work In Progress / Re: scripting
« on: January 12, 2012, 09:33:11 pm »Quote
But i'm not sure about python. What about lua? It's popular in gamesIt should be doable with lua either. I choosed python because this the one i know. But the way it's done, it's shoud be easy to get lua support.
Quote
What was already said here:Did not see that discussion before. Ruleset are fine, but i don't think it's enough. There are case where you need programming language In the referenced discussion, someone suggested a teleporting device. It's not something you can do only with ruleset. I'm sure that you can easily find other thing where it can be useful.
https://openxcom.org/forum/index.php/topic,11
And that discussion did lead to having all hardcoded data in external YAML files. Which imho is already a big step forward.
Also, you will see that modders always come up with things that will not be able to be done with scripting alone. Code changes are always needed. Unless you have a very generic game engine, and really move all logic to scripting. But then I think we can start all over again... but I can be wrong, because honestly I don't have any experience with either python or lua.
Anyway, i think it will be more clear once i push the beast to a git repo(just need some code clean).
Quote
You could move game logic from c++ to scrips partially, for example battlescape ai first, then geoscape ai, etc.There are little points in moving already implemented stuff to another language. It's much more interresting for new stuff.
Quote
Anyway, that stuff should wait after 1.0. Adding it now to official repo could slow project too much. But IMHO it's good to experimentIt's exactly how i see it. There are a lot's of stuff which are much more important than scripting at the moment(ruleset for instance). But when we will need it, we will already have something to experiment with. It can also be interresting to see what will need to be modified later to help moddability.
12
Work In Progress / scripting
« on: January 11, 2012, 09:49:18 pm »
Hi,
I have recently started playing with SWIG(https://swig.org). I have tried to bind some parts of OpenXcom in python. So far, i have a working version which allow to run some python script. I have uploaded some example scripts i have tried here : https://gchevallereau.net/guillaume/python/
I will push this to my personal git repo soon, but I want to know if there are people interested?
I think that this would be an interresting addition to OpenXcom. This can be used to help development and maybe later this can be an interresting tools for modders.
I have recently started playing with SWIG(https://swig.org). I have tried to bind some parts of OpenXcom in python. So far, i have a working version which allow to run some python script. I have uploaded some example scripts i have tried here : https://gchevallereau.net/guillaume/python/
I will push this to my personal git repo soon, but I want to know if there are people interested?
I think that this would be an interresting addition to OpenXcom. This can be used to help development and maybe later this can be an interresting tools for modders.
13
Programming / Re: Battlescape development
« on: December 13, 2011, 09:05:28 pm »
By the way, i have uploaded a video showing some of the 0.4 features here https://www.youtube.com/watch?v=226Yso3XKi8
This was done with the unlimited_ammo test(for laser rifle) and medikit.
This was done with the unlimited_ammo test(for laser rifle) and medikit.
14
Programming / Re: Battlescape development
« on: December 12, 2011, 09:31:18 pm »
I have found a little regression introduced by large unit support. When startting a mission the battlescape crash during initialization. It doesn't happen when in debug mode(using the graph button). I'm not sure of the best way to fix it, I have just added this:
in Map.cpp line 437. After this, no more crash and large unit seems to wrok without any problems
Code: [Select]
if (part < 0)
{
part = 0;
}
in Map.cpp line 437. After this, no more crash and large unit seems to wrok without any problems
15
Open Feedback / Re: 0.4 This year?
« on: December 08, 2011, 09:15:54 pm »Quote
You actually load the weapon with an ammo item of a new class "NoAmmoItem"?Yes it seems to be the easiest way.
Quote
Also did you try what happens if you want to unload the ammo out of a laser weapon?No, it was just a quick hack to have laser weapons working in the battlescape. But it should be easy to forbid unload if weapons has unlimmited ammo