Scripted Universe Generation!

Programmers discuss here anything related to FreeOrion programming. Primarily for the developers to discuss.

Moderator: Committer

Post Reply
Message
Author
User avatar
Vezzra
Release Manager, Design
Posts: 5415
Joined: Wed Nov 16, 2011 12:56 pm
Location: Sol III

Scripted Universe Generation!

#1 Post by Vezzra »

It has been a mighty struggle, but after some serious grappling with the peculiarities of C++, boost python and Co I'm finally able to post a patch containing my first major code contribution (after being around for more than two years... ;)): the first steps of an implementation of scripted universe generation (as described on the progamming work wiki page).

Well, it has been a major learning experience (between C++'s often very inconclusive error messages, boost's, ahem, so-called "documentation" etc.), but here it is. It's of course far from complete, but the basic framework has been implemented at least so far that the thing is functional, so universe generation isn't broken. You can apply the patch and play around with what's already there.

Which is Python scriptable placement of the star systems currently. That part is already done by the new Python universe generator interface, the rest is still handled by the old C++ code. The Python script (UniverseGenerator.py) is located in the default folder with the other content files. Take a look at it, and also at the new UniverseGenerator.cpp, that should give you a pretty good idea of how things are set up. I've added a "custom" galaxy shape that is handled entirely by the Python script, for all the other shapes I've exposed the C++ function that create them to Python and call them from there.

Dear fellow coders: Can you take a look at the patch and review the thing? My C skills turned out to be very, very rusty (ok, they are pretty ancient, the last time I did something serious in C was back in the Eighties), I've practically never done anything in C++, not to mention boost python et al, so it's more than likely that I've botched some things. I want a bit feedback before I dare to commit this. And of course I also need to know if the approach I've chosen is okay (Geoff? I can imagine that I'm going to get quite some corrections from you).

That said, of course I did some basic testing already, on Windows and OSX. It builds and runs fine on both platforms. So apparently I haven't botched anything critical :D

The plan is to implement the new interface step by step in a way that universe generation stays fully functional during the entire process (like it's been done with this first step), so that I don't have to accumulate everything in one gigantic commit. If you have comments, suggestions, ideas what should be done, I'm all ears. If I'm able to implement said ideas is an entirely different question ;). But I'll try.

As I said, the patch has been tested on Windows and OSX, so it also contains all necessary changes to the respective project files. As I don't have a Linux dev platform for FO, I'm not able to do the same for Linux. For the Linux folks: There are two new files, UniverseGenerator.cpp and UniverseGenerator.h which belong to the server of course, and two existing cpp's also have to be added to the server because I make use of them: PythonLoggingWrapper.cpp and PythonEnumWrapper.cpp. Adjust your build environment accordingly.

Now, let the feedback come :D
Attachments

[The extension patch has been deactivated and can no longer be displayed.]


User avatar
Vezzra
Release Manager, Design
Posts: 5415
Joined: Wed Nov 16, 2011 12:56 pm
Location: Sol III

Re: Scripted Universe Generation!

#2 Post by Vezzra »

There is one issue I haven't been able to solve (I did a crude hackaround though to get things working). Originally I wanted to do that to be able to insert system positions into the positions vector from Python:

Code: Select all

    class_<std::vector<SystemPosition> >("PositionVec")
       .def(vector_indexing_suite<std::vector<SystemPosition>, true>())
       .def("add", &std::vector<SystemPosition>::push_back);
As you can see, I simply intended to expose std::vector::push_back to Python. Which, to my initial delight, worked perfectly fine on OSX. However, when I tried to compile this very thing with MSVC, I got the following compile errors (line 142 is the one exposing push_back):

Code: Select all

2>..\..\universe\UniverseGenerator.cpp(142): error C2780: 'boost::python::class_<W> &boost::python::class_<W>::def(const char *,Fn,const A1 &,const A2 &,const A3 &)' : expects 5 arguments - 2 provided
2>          with
2>          [
2>              W=std::vector<SystemPosition>
2>          ]
2>          C:\Users\user\SoftwareProjekte\FO\script_unigen\Boost\include\boost_1_51\boost/python/class.hpp(266) : see declaration of 'boost::python::class_<W>::def'
2>          with
2>          [
2>              W=std::vector<SystemPosition>
2>          ]
2>..\..\universe\UniverseGenerator.cpp(142): error C2780: 'boost::python::class_<W> &boost::python::class_<W>::def(const char *,Fn,const A1 &,const A2 &)' : expects 4 arguments - 2 provided
2>          with
2>          [
2>              W=std::vector<SystemPosition>
2>          ]
2>          C:\Users\user\SoftwareProjekte\FO\script_unigen\Boost\include\boost_1_51\boost/python/class.hpp(250) : see declaration of 'boost::python::class_<W>::def'
2>          with
2>          [
2>              W=std::vector<SystemPosition>
2>          ]
2>..\..\universe\UniverseGenerator.cpp(142): error C2780: 'boost::python::class_<W> &boost::python::class_<W>::def(const char *,A1,const A2 &)' : expects 3 arguments - 2 provided
2>          with
2>          [
2>              W=std::vector<SystemPosition>
2>          ]
2>          C:\Users\user\SoftwareProjekte\FO\script_unigen\Boost\include\boost_1_51\boost/python/class.hpp(243) : see declaration of 'boost::python::class_<W>::def'
2>          with
2>          [
2>              W=std::vector<SystemPosition>
2>          ]
2>..\..\universe\UniverseGenerator.cpp(142): error C2914: 'boost::python::class_<W>::def' : cannot deduce template argument as function argument is ambiguous
2>          with
2>          [
2>              W=std::vector<SystemPosition>
2>          ]
2>..\..\universe\UniverseGenerator.cpp(142): error C2784: 'boost::python::class_<W> &boost::python::class_<W>::def(const char *,F)' : could not deduce template argument for 'overloaded function type' from 'overloaded function type'
2>          with
2>          [
2>              W=std::vector<SystemPosition>
2>          ]
2>          C:\Users\user\SoftwareProjekte\FO\script_unigen\Boost\include\boost_1_51\boost/python/class.hpp(234) : see declaration of 'boost::python::class_<W>::def'
2>          with
2>          [
2>              W=std::vector<SystemPosition>
2>          ]
2>..\..\universe\UniverseGenerator.cpp(142): error C2780: 'boost::python::class_<W> &boost::python::class_<W>::def(const boost::python::def_visitor<Derived> &)' : expects 1 arguments - 2 provided
2>          with
2>          [
2>              W=std::vector<SystemPosition>
2>          ]
2>          C:\Users\user\SoftwareProjekte\FO\script_unigen\Boost\include\boost_1_51\boost/python/class.hpp(224) : see declaration of 'boost::python::class_<W>::def'
2>          with
2>          [
2>              W=std::vector<SystemPosition>
2>          ]
Huh...? Anyone any idea what's going on here, and why this works on OSX but not on Win?

User avatar
Geoff the Medio
Programming, Design, Admin
Posts: 12745
Joined: Wed Oct 08, 2003 1:33 am
Location: Munich

Re: Scripted Universe Generation!

#3 Post by Geoff the Medio »

There is a vector indexing suite in Boost::Python, so you shouldn't need to expose individual functions. See the "STL Containers" section in PythonAI.cpp.

However, I think it's fine to just have an AddSystem(...) function, and deal with details of implementation in the C++ code. That can be filling in the appropriate container expected by other code, or something else later.

Why do you need to redefine the SetupData struct which appears to nearly duplicate the GalaxySetupData struct (which is already exposed to the AI in PythonAI.cpp)? The only difference appears to be adding a systems positions container, which seems unnecessary... At the least, it could be derived from GalaxySetupData, but I don't think there's any need for that either, if the only difference is passing in/out system positions.

Rather than "Custom", I'd call it "Python Test" or somesuch...

More generally, I'm a bit hesitant to add a Python dependency to the server process. I expect this could lead to problems, particularly on Linux. A separate process, similar to the AIs, for galaxy generation, might be useful? Moving all the universe generation stuff out of Universe anyway probably would be good.

User avatar
Dilvish
AI Lead and Programmer Emeritus
Posts: 4768
Joined: Sat Sep 22, 2012 6:25 pm

Re: Scripted Universe Generation!

#4 Post by Dilvish »

I'd suggest that rather than trying to have python directly provide a std::vector<SystemPosition>, that you have the python code provide a python list of (double,double) tuples and then have your recipient function decode that into a std::vector<std::pair<double,double> >

a partial example is in IssueCreateShipDesignOrderWrapper from AI/PythonAI.cpp, which accepts a python list of strings and populates an std::vector<std::string> > from that. Extracting toubles is a bit more complicated, but I think something like the following might work:

Code: Select all

        std::vector<std::pair<double,double> > system_locs;
        int const num_systems = boost::python::len(python_system_locs_list);
        for (int i = 0; i < num_systems; i++) {
            boost::python::tuple loc_tuple = boost::python::extract<boost::python::tuple>(python_system_locs_list[i]);
            double sys_x = boost::python::extract<double>(loc_tuple[0]);
            double sys_y = boost::python::extract<double>(loc_tuple[1]);
            system_locs.push_back(std::make_pair<double,double>(sys_x,sys_y));
        }
If I provided any code, scripts or other content here, it's released under GPL 2.0 and CC-BY-SA 3.0

User avatar
Vezzra
Release Manager, Design
Posts: 5415
Joined: Wed Nov 16, 2011 12:56 pm
Location: Sol III

Re: Scripted Universe Generation!

#5 Post by Vezzra »

Geoff the Medio wrote:There is a vector indexing suite in Boost::Python, so you shouldn't need to expose individual functions. See the "STL Containers" section in PythonAI.cpp.
Yes, I know that and actually use it. As you can see, I've exposed std::vector<SystemPosition> via vector_indexing_suite. Unfortunately, the Python class created by that doesn't include a way to add new items to the vector, you can only iterate over it, access the items (and also change already existing index positions, I believe). That's why I came up with the idea of exposing std::vector::push_back, which did work perfectly fine - but not on Windows :(
However, I think it's fine to just have an AddSystem(...) function, and deal with details of implementation in the C++ code. That can be filling in the appropriate container expected by other code, or something else later.
Well, yes, but I also want to provide the possibility to easily iterate over the already added positions, and that's best done by using the indexing suite as it provides easy and convenient iterating and accessing on the Python side. No need to re-invent the wheel.
Why do you need to redefine the SetupData struct which appears to nearly duplicate the GalaxySetupData struct (which is already exposed to the AI in PythonAI.cpp)?
To be honest, I haven't really looked at GalaxySetupData very much. I just adjusted the call to universe generation in ServerApp to call my new GenerateUniverse instead of Universe::CreateUniverse, and left everything else untouched. As all setup data was passed in a bunch of parameters, instead of just passing a single record/class instance containing all the data, I just went with that (assuming whoever coded this piece had a reason for doing things that way). Initially I intended to pass the setup parameters to the Python function the same way, but somewhere down the road decided it would be better otherwise, assembled the setup parameters in a global struct the Python function could retrieve.

But of course you're right. So I guess I expose GalaxySetupData to Python, adjust the call from ServerApp to pass the GalaxySetupData instance and pass that on to the Python function.
The only difference appears to be adding a systems positions container, which seems unnecessary...
Yeah, of course, that's just a temporary "hack", see the comment to m_system_positions.
Rather than "Custom", I'd call it "Python Test" or somesuch...
Ok.
More generally, I'm a bit hesitant to add a Python dependency to the server process. I expect this could lead to problems, particularly on Linux. A separate process, similar to the AIs, for galaxy generation, might be useful?
Ugh, do you want to deepen my major learning experience so much more? :shock: :wink: Ok, kidding aside - I really didn't see that one coming. Why on earth do you want to do this? What kind of problems do you expect that you want to open that can of worms? Because this will add significant complexity, with all the potential issues, potential for bugs and breaking things. I didn't have any idea that adding Python dependency to the server could be so hazardous...?

Anyway, I'd suggest to try the less daunting approach first and leave all the universe generation stuff in the server. If the issues you seem to expect turn up, we can still consider moving it to a dedicated process.
Moving all the universe generation stuff out of Universe anyway probably would be good.
What exactly do you mean by that? Move out of the Universe class or out of UniverseServer.cpp? The former is already mostly done, most of the universe generation functions are already outside Universe. Those who aren't can be moved out I think. The latter doesn't make much sense, as UniverseServer.cpp consists practically entirely of universe generation stuff.

It would probably make sense to move the remaining universe generation member functions out of Universe, rename UniverseServer.cpp to UniverseGenerator.cpp and put everything universe generation related in there. Rename my UniverseGenerator.cpp to PythonUniverseGenerator.cpp and put the entire Python interface stuff there. How does that sound?

User avatar
Dilvish
AI Lead and Programmer Emeritus
Posts: 4768
Joined: Sat Sep 22, 2012 6:25 pm

Re: Scripted Universe Generation!

#6 Post by Dilvish »

Vezzra wrote:
Geoff the Medio wrote:More generally, I'm a bit hesitant to add a Python dependency to the server process. I expect this could lead to problems, particularly on Linux. A separate process, similar to the AIs, for galaxy generation, might be useful?
Ugh, do you want to deepen my major learning experience so much more? :shock: :wink:
In support of Vezzra, I feel compelled to mention I had much the same reaction to seeing this issue raised now -- although for someone already familiar with the manner of forking off these python processes it might not seem like a big deal, for anyone not already familiar with that it could be a rather large monkey wrench to throw into the middle of a project, more so than typical scope creep.

Geoff , since you do just say you're "hesitant" to proceed with a server Python dependency, rather than outright objecting, I expect you're willing to let things proceed as Vezzra suggests, with splitting this off as a distinct process being a follow-up project, and I just wanted to voice some support for that.
If I provided any code, scripts or other content here, it's released under GPL 2.0 and CC-BY-SA 3.0

User avatar
Geoff the Medio
Programming, Design, Admin
Posts: 12745
Joined: Wed Oct 08, 2003 1:33 am
Location: Munich

Re: Scripted Universe Generation!

#7 Post by Geoff the Medio »

Vezzra wrote:...I also want to provide the possibility to easily iterate over the already added positions...
Why? You can treat a series of "AddSystem" calls to be final. The Python code can set up its own container of planned system positions, and decide when it's happy with them, and then finalize them by API calls when done. There's no real need to have ongoing interaction with C++ data structures, is there?
What kind of problems do you expect that you want to [...avoid...] adding Python dependency to the server...
There are numerous issues reported on the forums about problems people have had with Python initialization. Weird installation conflicts or version issues seem to contribute. The result is that they can't run games with any AIs in them. Making the server, and in particular universe generation, depend on Python as well would make things more dramatically broken when Python init breaks. At least now they can get into a single player game.
Moving all the universe generation stuff out of Universe anyway probably would be good.
What exactly do you mean by that? Move out of the Universe class...
Yes.
...most of the universe generation functions are already outside Universe.
I'm looking at the series of functions like CreateUniverse, PopulateSystems, AddStartingSpecials, GenerateNatives, GenerateSpaceMonsters, GenerateStarlanes, GenerateHomeworlds, NamePlanets, GenerateFields, and GenerateEmpires, which are all part of Universe. Implementing Python-scripted generation would largely accomplish this goal, though.
It would probably make sense to move the remaining universe generation member functions out of Universe, rename UniverseServer.cpp to UniverseGenerator.cpp and put everything universe generation related in there. Rename my UniverseGenerator.cpp to PythonUniverseGenerator.cpp and put the entire Python interface stuff there. How does that sound?
Sounds good.
Dilvish wrote:I expect you're willing to let things proceed as Vezzra suggests...
Yes. I'm fairly sure it'll cause problems, but the benefits are probably worth that.

User avatar
Vezzra
Release Manager, Design
Posts: 5415
Joined: Wed Nov 16, 2011 12:56 pm
Location: Sol III

Re: Scripted Universe Generation!

#8 Post by Vezzra »

Dilvish wrote:I'd suggest that rather than trying to have python directly provide a std::vector<SystemPosition>, that you have the python code provide a python list of (double,double) tuples and then have your recipient function decode that into a std::vector<std::pair<double,double> >
Actually I did consider this as a possible solition, but to be honest I like that even less than the "bolted on" AddPosition function I resorted to in the end. Besides feeling even more awkward, I'd also had have to do that twice, because it's not only necessary to pass the positions to the C++ code, but there are also the C++ functions which calculate the positions for the various galaxy shapes which I simply expose to Python instead of reimplementing them completely on the Python side. So you also have to pass the positions vector from C++ to Python.

Under these circumstances making use of the indexing suite seemed the best and easiest approach.

User avatar
Vezzra
Release Manager, Design
Posts: 5415
Joined: Wed Nov 16, 2011 12:56 pm
Location: Sol III

Re: Scripted Universe Generation!

#9 Post by Vezzra »

Geoff the Medio wrote:Why? You can treat a series of "AddSystem" calls to be final. The Python code can set up its own container of planned system positions, and decide when it's happy with them, and then finalize them by API calls when done. There's no real need to have ongoing interaction with C++ data structures, is there?
Well, yes and no, I guess. It just seemed to be the most consistent approach all things considered. After all, as you can see (and as it's suggested on the programming work page), I haven't thrown the "galaxy shape" functions that calculate the system positions out of the window, but exposed them to Python so we can continue to use them instead of completely reimplementing them in Python. Of course that means I had to expose the positions vector they use to store and pass back the positions to Python, so just using this vector on the Python side as well to store the positions seemed the most obvious solution. Of course I could just use a list container in Python and, when finished with whatever complicated juggling with it's contents, pass it to C++ via a series of AddSystem calls. However, if taking that road, I'd rather expose a AddSystems function that passes the entire container, no need to burden the Python scripters with implementing loops here that we can do on the C++ side just as well.

But wether I pass the entire container or single system positions, I'd have to provide to seperate functions, one for passing positions calculated by Python functions (and therefore stored in a Python container), and one for passing positions Python received from the exposed C++ "galaxy shape" functions (and therefore stored in the exposed C++ container). Also not the easiest and most elegant solution.

Another approach would be to use only Python containers and make the C++ "galaxy shape" functions use them. On the Python side that would make things completely transparent, you would use only Python containers consistently throughout the entire procedure. Drawbacks: We'd have to rewrite the C++ "galaxy shape" functions accordingly, which would make things on the C++ side a more awkward - either you start copying the containers, or use the boost::python container objects. One thing, I'm not sure how smooth that's going to work. Another thing, that would add boost::python dependency already on the UniverseServer.cpp (which is going to be UniverseGenerator.cpp) level, which is something I'd been trying to avoid. I don't know how you feel, but I'd rather put all Python related stuff into PythonUniverseGenerator.cpp, so the purely C++ universe generation functions and the Python interface to them are cleanly separated.

All these options will work, and there are probably pros and cons to all of them. I can live with most of them, the one I like the least is requiring the Python scripters having to handle two different types of containers, and having to pay attention to which function to call with which container. They should be able to use one type of container wether they use the exposed "galaxy shape" functions or calculate the positions on the Python side.

Do you have specific preferences for or objections against one or more of these alternatives?
There are numerous issues reported on the forums about problems people have had with Python initialization. Weird installation conflicts or version issues seem to contribute. The result is that they can't run games with any AIs in them. Making the server, and in particular universe generation, depend on Python as well would make things more dramatically broken when Python init breaks. At least now they can get into a single player game.
Ah! That's what you're worried about! I see... however, I've to admit that I'm still confused: How would moving universe generation into it's own process solve this problem? I'm probably missing something glaringly obvious here, but if universe generation fails because Python init breaks, it will do that regardless if it runs in it's own process or as a part of the server process. As you've pointed out yourself, the problem here is not so much the dependency of the server process itself on Python, but the dependency of the universe generation procedure on Python. But this dependency will remain anyway, that has nothing to do with in which process universe generation runs. If Python init breaks, you won't get a universe to play in - game over, dedicated process or not. You can play without AIs, but you can't play without an universe, so you can't really compare that...?
It would probably make sense to move the remaining universe generation member functions out of Universe, rename UniverseServer.cpp to UniverseGenerator.cpp and put everything universe generation related in there. Rename my UniverseGenerator.cpp to PythonUniverseGenerator.cpp and put the entire Python interface stuff there. How does that sound?
Sounds good.
Would you be okay with it if I postpone cleaning up the Universe class and do that in one of the next steps, instead of incorporating all this into the first patch? I don't want to do too much at once with the first step, the patch is already quite big.

User avatar
Dilvish
AI Lead and Programmer Emeritus
Posts: 4768
Joined: Sat Sep 22, 2012 6:25 pm

Re: Scripted Universe Generation!

#10 Post by Dilvish »

Geoff the Medio wrote:Making the server, and in particular universe generation, depend on Python as well would make things more dramatically broken when Python init breaks.
How about the existing universe creation routines get kept as a backup (moved from Universe.cpp to UniverseServer.cpp or whatever it winds up being called), and the server's attempt to init python gets wrapped in try:except and/or other error checking, so that it can fall back on the current routines if need be. Shouldn't something like that be workable?
If I provided any code, scripts or other content here, it's released under GPL 2.0 and CC-BY-SA 3.0

User avatar
Dilvish
AI Lead and Programmer Emeritus
Posts: 4768
Joined: Sat Sep 22, 2012 6:25 pm

Re: Scripted Universe Generation!

#11 Post by Dilvish »

Vezzra wrote:There is one issue I haven't been able to solve...As you can see, I simply intended to expose std::vector::push_back to Python. Which, to my initial delight, worked perfectly fine on OSX. However, when I tried to compile this very thing with MSVC, I got the following compile errors (line 142 is the one exposing push_back):... Anyone any idea what's going on here, and why this works on OSX but not on Win?
It looks to me like the templated nature of std::vector<SystemPosition>::push_back is confusing boosts overloaded class::def routines. I'd suggest making a wrapper function for std::vector<SystemPosition>::push_back and then add that wrapper function instead of the original. An example of something a little similar would be UpdateMetersWrapper in PythonUniverseWrapper.cpp -- I think your wrapper can be even simpler, its main purpose being simply to avoid making Boost deal with adding a templated function.

maybe also/instead define a typename for std::vector<SystemPosition> & then use that everywhere might help boost sort it out.
If I provided any code, scripts or other content here, it's released under GPL 2.0 and CC-BY-SA 3.0

User avatar
Vezzra
Release Manager, Design
Posts: 5415
Joined: Wed Nov 16, 2011 12:56 pm
Location: Sol III

Re: Scripted Universe Generation!

#12 Post by Vezzra »

Dilvish wrote:How about the existing universe creation routines get kept as a backup (moved from Universe.cpp to UniverseServer.cpp or whatever it winds up being called), and the server's attempt to init python gets wrapped in try:except and/or other error checking, so that it can fall back on the current routines if need be. Shouldn't something like that be workable?
I was thinking along the same lines... I want to keep the existing functionality anyway, so that the entire universe generation process could still be covered by C++ functions alone.

The main issue here is that the whole point of the Python scripted universe generation is to be able to do get much more (scriptable) flexibility for universe generation. Which means that some mechanics are going to be replaced, I'm thinking of initial buildings, ships, fleets. To be able to fall back on the old mechanics they have to be kept in place, requiring content scripters to provide e.g. starting fleets not only in the Python script, but also the old FOCS scripts for a fallback mechanism be able to work. Not pretty...

User avatar
Geoff the Medio
Programming, Design, Admin
Posts: 12745
Joined: Wed Oct 08, 2003 1:33 am
Location: Munich

Re: Scripted Universe Generation!

#13 Post by Geoff the Medio »

I think if you're writing a Python galaxy generation script system, you shouldn't need to preserve all the existing c++ functionality. If those functions work well, they can relatively easily be replicated in Python - we have their source code after all. Trying to preserve all the existing code and how it interacts while letting Python selectively replace any part will make the process unnecessarily complicated.

While I'm hesitant to switch to Python, if the switch is made, I think it should be as full a switch as possible, as a fully separate / replacement galaxy generation pipeline. This would function without trying to integrate Python scripts into each step between different bits of C++ code, which leads to all these sorts of issues about different containers and how to pass them between languages.
Would you be okay with it if I postpone cleaning up the Universe class and do that in one of the next steps, instead of incorporating all this into the first patch?
Yes... though I think implementing the Python stuff should pretty much replace most of the existing code anyway, as above. I'd implement it all separately, rather than trying to integrate it incrementally into the existing code...
To be able to fall back on the old mechanics they have to be kept in place, requiring content scripters to provide e.g. starting fleets not only in the Python script, but also the old FOCS scripts for a fallback mechanism be able to work.
Content scripters still need to be able to control how stuff spawns as part of defining content, without getting into the Python code (just as they don't have to write C++). Exactly what is scripted in Python vs. lists can change, but Python code will need to have access to that part of scripts in some manner, such as being able to evaluate conditions on sets of objects, or get the list of starting buildings or preunlocked items, even if all the C++ galaxy generation code is eventually removed. Exposing such lists to Python shouldn't be complicated, though.

User avatar
Vezzra
Release Manager, Design
Posts: 5415
Joined: Wed Nov 16, 2011 12:56 pm
Location: Sol III

Re: Scripted Universe Generation!

#14 Post by Vezzra »

Dilvish wrote:I'd suggest making a wrapper function for std::vector<SystemPosition>::push_back...
Argh... I've to confess I feel quite stupid now :oops: I did some more thorough digging into the boost::python documentation, and found that contrary to what I thought before, the vector indexing suite actually does expose a append member function to Python. To my defense, the only hint for it's existence was buried somewhere in a code example (I obviously didn't read carefully enough the first time).

Well, problem solved. The test build on Windows is not yet finished, but I'm fairly confident that it will succeed...

User avatar
Geoff the Medio
Programming, Design, Admin
Posts: 12745
Joined: Wed Oct 08, 2003 1:33 am
Location: Munich

Re: Scripted Universe Generation!

#15 Post by Geoff the Medio »

Vezzra wrote:...the only hint for it's existence...
I haven't tested on an exposed vector, but you can use dir(object) within Python code to get a list of functions and variables with an object, which might be useful to keep in mind...

Code: Select all

>>> d = dict()
>>> dir(d)
['__class__', '__cmp__', '__contains__', '__delattr__', '__delitem__', '__doc__'
, '__eq__', '__format__', '__ge__', '__getattribute__', '__getitem__', '__gt__',
 '__hash__', '__init__', '__iter__', '__le__', '__len__', '__lt__', '__ne__', '_
_new__', '__reduce__', '__reduce_ex__', '__repr__', '__setattr__', '__setitem__'
, '__sizeof__', '__str__', '__subclasshook__', 'clear', 'copy', 'fromkeys', 'get
', 'has_key', 'items', 'iteritems', 'iterkeys', 'itervalues', 'keys', 'pop', 'po
pitem', 'setdefault', 'update', 'values', 'viewitems', 'viewkeys', 'viewvalues']

Post Reply