FreeOrion

IMO to be on the asteroid belt itself those mines need not to be built on the asteroid belt itself by its non-existent (yet) industry.
So, i just tried an effect script to this end, and it almost works - save one problem. Something like this:
So the base creates one mine per turn at the random belt and mine self-terminates later, so the mines of the 3 ages work at once, even after their base ceases to spawn new ones. Of course, "BLD_ASTEROID_MINE_II" is the same with a better bonus.
But there's a problem: owner value. That is, it works only if i remove OwnedBy TheEmpire Source.Owner condition from the mine - naturally, sending those bonuses to everyone. So, the mine haven't owner? I thought it would get it from the Source, then i looked into CreateBuilding::Execute in universe/Effect.cpp - it turns out the location's owners are copied instead. If i use AddOwner on the target asteroid belt before a mine is spawned, it works, but causes starvation alerts. If add owner before CreateBuilding and remove immediately later, it's removed from the building too.

Well, the parser can be easily fixed to assign the owner explicitly in CreateBuilding, but the point is - it's not very flexible, if you have to add everything in the source anyway (even if it can be circumvented by perversions like my check for Source.Age).

I think the method you're using to create these mines and remove the base that's creating them is too complicated to be practical. It would probably make more sense to modify the way build locations can be selected, so that it's possible to order your empire to build something on an asteroid field within a system where you have a colonized planet. Currently I think there's some hard-coded filtering so that only colonized planets can be selected, but this could be modified.

The CreateBuilding effect uses the target object's owner (owner of the object on which the building is created) because that usually makes the most sense... If a building is created on a planet owned by an empire, it usually should be owned by that empire, although there could be cases where that wouldn't be what's needed. Regardless, the effect could be modified to take a parameter, as noted.

Of course it's too complicated. But that's my point: even when it's possible to do more than initially planned, almost anything non-trivial is needlessly complicated, unless there's some specific hardcoded support.
Then it will be something else, like more flexible colonization or ship repair... Because it grows.
But if possibilities of what essentially is a script require more hard-coded stuff and not less - maybe, it demonstrates that parsers are great for tables, but scripted effects would be better as... scripts? I mean, when even Scheme looks like a good alternative...

Making all game content "scripts", instead of "definitions" as they are currently, sounds fine if you know you to program and write scripts, but a lot of people are unable or unwilling to learn how to do those things. Having a more limited content description language that doesn't have arbitrary variables or execution flow control or other programming / scripting language complications makes it significantly more approachable for prospective content designers, even if the actual definition files end up being somewhat complicated (and limited in what they can do).

Arguably the entire game could be made using scripting languages... from all the production mechanics, ship / fleet movement, the UI outside of the actual rendering calls, as well as how techs or buildings or other such things function... Going forward, I'd like to increase the number of things that can be "scripted" or defined in text files rather than hard-coded. However doing this takes time and makes things a lot more complicated.

And since FreeOrion is open-source, the significance of some aspect of the engine being coded in C++ and requiring a limited content definition language vs. a scripting language like Python being able to do almost anything with the game mechanics is a bit lessened compared to what it would be for a commercial closed source game. It may not be possible to do any arbitrary thing using the current content description languge, but you could add the appropriate functions to C++ and use them from the content definitions, which has nearly the same functionality as would being able to write a scripting language program to implement the desired effect.

The modified set of content files found here allows the player to create outposts on asteroid belts and build asteroid mines or asteroid shipyards on them. In the future, it should probably be possible to make such outposts production centers, but not population centers, meaning that there would be resource meters, but no social meters such as population and health. A different formula to determine resource production (perhaps using the construction meter?) would be required in this case.

Also, that set of buildings is really unnecessarily complicated for what you're trying to do, in any case. Much, much easier would be:





Different effects groups for refinements can be done in the effectsgroups of the asteroid mine itself, rather than having the base produce different types of asteroid mines, by using the OwnerHasTech condition in the scope.

This is still all pretty pointless though, since the main base of operations is still on the planet itself, just as it is in your version. This means that there's no real strategic significance to having the asteroid mine on the asteroid belt itself. Better in pretty much every way would be to have the main mining facility exist on the asteroids as a production center.

_________________
Warning: Antarans in dimensional portal are closer than they appear.

And what's exactly the point to turn all into script? Of course, if there's an object with pre-set fields (like a ship), it's just as well may use a table. But then, is there any essential difference between "list of valid fields to be set and their values" which should be parsed and "list of valid variables to be initialized and their values" which should be interpreted? Either way you end up with exactly the same (save few syntactic trifles): It already is an interpreted language, just with weird syntax and that needs more code for every new method than is really necessary.
What's "more approachable"? Simple object init: see an example above. Effects: do you think the current implementation is less awkward and more "intuitive" than a real script language would be? Is "(set! index (+ index 1))" in a fugly Scheme that much more cryptic than "SetMaxTrade value = Target.MaxTrade + 1" in FO-effects? Then how about "sum = sum + countCargo( unit )" in clean Lua? Beyond this, it's an imaginary problem: designers who will never need to write a script with loops, aren't required to even know what "loops" are. And those who need, either can do it - or must deal with C++ code in four different files instead.
It certainly takes time and is a lot more complicated when you get a simpler interpreted language, but must rewrite your own interpreter every time you want the script to do something new.
Of course, there's always some balance between the content and the code, but right now it's hardly close to an optimum. IMHO rule of thumb is: things that must be fast are better hardcoded and things that have no impact on FPS and not much on new turn generation time may as well be scripted. E.g. universe spawning is better as a script coming with a ruleset, and GUI, well, isn't (Glade XML, on the other hand...).
Also, while more complex scripts may be slow, right now it uses conditions instead of procedures when this isn't really necessary. Would straightforward object and function references be slower than scanning and matching everything for any trivial task?
Yeah, and there's basically two ways for this: either reinvent the bicycle, extending this parser until it's equal to a convential interpreter or get a ready one in some library. Just like with OGRE: you could do what you need on your own, but is it a good idea?
"Lessened", but the difference between a ruleset and a branch still means lesser moddability. It's easier to restart a game than to recompile everything three times over just to tweak a thing or two. Of course one can hardcode everything in OSS, but this doesn't mean it's the best way to do everything.
While Python may be overkill for what's essentially are mass-used event handlers, there's always something simpler and maybe a bit faster. Just for an example other than Python: ASC is quite alive and well with its C++ / Lua.
Let me rephrase it? "It is a limited scripting language, but you have to write everything in C++ first and then refer to it, whenever you do anything not already implemented this very way". See the problem? If you must dig into the main code anyway, it would take less effort if conditions and effects were simplified and hardcoded even more and implemented as enums and arguments - like ship parts now: class = Stealth|Colony; Capacity = N. For things as complex as effects are now, digging into the main code isn't the most convenient way.

I'll address the rest of this issue later, but for now,

I have no objections to making universe generation into a Python script instead of the current C++ code, or a combination of the two that can do everything in Python but also has access to the existing C++ functions if desired. This is listed on the Programming Work wiki page as a suggested task.


While there are numerous other options besides Python for scripting, we've already got Python scripted AI, and I don't want to add another scripting language, or figure out how to set up the interface between the scripting and C++, when Python can serve that role well enough and the related dependencies are already in place.

Ah, my bad, didn't look there. Then the issue is even less than i thought.
Anyway, Python certainly can be a good tool. Once i wrote a primitive dearchivator on Python (for DwarfFortress files)... and i don't even know it... that is - still.

The point of making as much game content into scripts as possible would be ease of modifying how the game works in a more flexible manner than the current fixed-structure content definitions, which you noted earlier would be an advantage of scripting languages over the current parser. By "content", I mean buildings, techs, ship parts and hulls, specials, and similar game components.


There's no difference for simple variables like costs, build times or names. The difference would be in the effectsgroups and conditions, which are less flexible with the parser than they could be if done with scripts.


The distinction I'm making is between arbitrary functionality that the content designer needs to write in a full scripting language, as opposed to chosing and combining a limited set of commands that hide all the internal details of how they work and which must be used in a fairly strict format. Right now, to write an effects group, the designer just needs to specify two conditions and the effect to perform on the selected objects. The designer doesn't need to think about the logical steps to get a set of objects from the scripting interface, how to write a filter on those objects or how to use the filter, then how to call various functions of those objects or the universe to modify the objects, or how to use the scripting language's built in features to do logical operations on the contents of sets.


If all a content creator is doing is setting simple values of fields in a data structure, it doesn't really matter to the creator what scripting / definition format is used. For filtering objects and modifying them or the gamestate, needing to call functions or deal with scripting language syntax and flow control, as above, makes things a lot harder to understand for non-programmers.

There are also advantages to having the fixed standard format of the current definition format, which allow the content to be more easily parsed and displayed in the GUI than an arbitrary scripting language implementation would.


The current probably more awkward and less intuitive than writing a script would be for me, or someone else who's comfortable writing prodecural program code / scripts.


Those code snippets don't seem to be doing the same thing, so it's not really a fair comparison, but I'd say the explicit names of the effects and referenced properties in the FO-content-definition-style are the least cryptic of those options.


If everything was scripted instead of defined and parsed as now, effects would need to be implemented in the scripting language... so the content creator would need to know how to write scripts in that language, including flow control and data manipulation. Maybe we're talking about different things or levels of scripting, as this seems quite obvious to me... It's inherent in replacing the parser with scripts for effects and conditions.


Adding a new function to the parser doesn't involve changing anything besides the function that's being added, and the code to expose it. It's certainly not a full rewrite of the parser for each modification... And most of the difficulty in doing that is all the behinds the scenes bookkeeping and safety checking that is done to make a function that's exposed to the parser relatively simple and safe to use.

The idea isn't that content creators will be writing C++ code to create new game content though... They generally don't know how to write programs with scripting or compiled languages, as discussed above. Instead, they can define an effects group or condition as a data structure, and don't need to worry about how it's handled internally.


No, we're not at an optimium, and a lot of stuff could and should be exposed to Python or otherwise made moddable, but doing this takes time.

If you'll volunteer to work at making more things moddable (without removing all parsing for content definitions), I'll gladly help you get it working.


I'm not sure, but I suspect that conditions as currently implemented in C++ and used when deciding on effect scope or allowed building locations are probably a small fraction of the time it would take to do similar filtering using the existing interface that's exposed to Python. I don't know if this difference would be significant in terms of UI responsiveness (this needs to happen during players turns to indicate whether a particular building can be produced on a particular location) or during turn processing.

But again, that's not really the point...


The content parsers would never get as fully functional as a full scripting language. They're always going to give a fixed set of values to define and set of components that can be stuck together in a very controlled structure to definte how content functions in-game.


You don't need to branch FreeOrion to add a new effect or condition... just submit a patch.


Restarting is all a content designer will do regularly, since they in general won't know how to add a new effect or condition anyway, and we should have a sufficient variety of effects and conditions to work with that they don't feel the need to add more very often...


See above re: my distinction between scripting languages involving programming issues such as flow control and data structure handling, and the current parser which is just a data structure with no execution flow control and a very fixed structure to work with.


The requirement to write most of the details of implementation of game mechanics for content in C++ before it can be used in content definitions is a limitation. But, the fact that the content creator doesn't need to know about any of these implementation details is a benfit to this arrangement. If we were to instead do all the implementation details in a Python script, it would be more moddable, but it's unlikely we'd want to then still have the extra step beyond that to have a non-programmer friendly non-scripting-language means to define content.


I don't follow your point here... To the content creator, who doesn't mess around in C++, the available effects and conditions are hard-coded, just like definitions of the style class = Stealth, except that effects and conditions can contain other conditions. It's impossible, and unnecessary, to predict all the possible combinations of conditions or effects that a content designer might want, so FreeOrion provides a variety of conditions and effects that can be combined together to create a variety of functions in-game.

Wait... You just described... function calls?
Other than how to construct those two condition statements? There's still no need in anything greater in Python.
Why it should be any different from operator-ized function calls (with names and parameters) that effect parser currently uses? Save the number of parentheses, that is.
I don't know why it would require anyone to know about writing a filter any more than when setting up parser conditions, but Python has clear-looking way to work with sets.
If you access a meter via built-in method (which is a very good idea anyway), this method can send the same "+1 from Wonder Farms" adjustment notice. So where's the difference?
If it should be the same, and it's going to be Python, not hiding methods behind the operators, "SetMaxTrade value = Target.MaxTrade + 1" would be something like "SetMeter (target.Trade.Max, target.Trade.Max + 1)" or "target.Trade.Max.SetTo (target.Trade.Max + 1)". Even more explicit, and hardly too cryptic, no? But it's so explicit that if this one works, so will
Source.Population.Current.SetTo (Source.Population.Current - 1)
Target.Population.Current.SetTo (Target.Population.Current + 1)
- instead of two special conditions for target and source. So for non-trivial but still rather simple cases having fewer limitations may make scripts more transparent.
So? If they don't need loops, they still can write "A = 1" on a scripting language without knowing anything about loops. As to the implementation, normallyeverything not tweaked right now is hidden behind a function call anyway. So whether it's actually engine or script function is a moot point. Its uses can even be designed when it's in script form and remain after it's incorporated into engine, or vice versa.
"Level of scripting" involved will stay the same, why it should change? Just choose or make up any specific FO-effect, and it's obvious that it can be converted into "real" script (assuming parser's fixed functions are replaced with a set of equal or more generic methods) that will not be any more or less complex and will have syntax no less (though in typical cases no more) transparent. Perhaps it's possible (if not always optimal) to translate FO-effect scripts into equivalent Pyhton scripts using regexps!
Conditions are less straightforward than fields, but the principle holds. For one, since you formulated it as a condition, it directly translates into callable bool function that can be applied to the set. If this is too ugly for you, with basic operations on sets it will be something like which is at least as transparent as Right?
Naturally. And why it would be any different on Python?
<shrugging eyestalks> it's not like i'm terribly occupied right now, so i'll look into it... after all, there's already C++ / Python interaction in FO AI (and VegaStrike AI, and GIMP Py-fu...), so i have more than enough of examples to start from.
Mostly, yes, but there are things no one needs in core FreeOrion and when someone will want to implement those... Include into the engine setting-specific features for my StarCon'rion mod? The presence of "true" scripting, naturally, allows a much larger leeway.
If a designer wants to do exactly the same, and necessary functions are there, how it's more or less "non-programmer friendly"?
The difference is that if people don't need to ask for support of this or that in engine as much (especially when they don't yet have a very clear idea how it should work in the end with everything else), it all will move a bit faster and farther.
Exactly. But it's also impossible and unnecessary to predict all things like, say, someone eventually wants to use supply meter in conditions too, then something else... If there's a way to access meters as such, such problem not exists.

If the interface that gets exposed to Python for effects and conditions scripting is just a series of function calls that do what the commands that are exposed via the parser do currently, then there's not really much gain in terms of flexibility. I'm assuming that the interface exposed to Python would be much lower-level, and would be used to implement the commands that are currently hard-coded, thus allowing the flexibility that was a major motivation for the whole exposing-to-scripting idea.


Clear if you're a programmer...


"this method" doesn't send any notifications. The interface and server use the various parts of an effectsgroup definition separately to determine the objects acted on by affects and then to actually implement the effects. To do the equivalent in Python, you'd need each building to have about four separate functions that the engine would call at different times, to filter possible build locations, to determine if the building is active that turn, to filter possible scope objects, and then to actually perform the building's effects on the selected scope objects. These don't all happen at the same time, so it wouldn't be as simple as writing a single "doBuildingStuff" Python function that does all the filtering and modifies the target objects and outputs some messages. Things get complicated quickly, and having to define a data structure and four or so separate functions to do different things, all using Python syntax, and possibly Python means for implementing filtering and the like are more than most non-programmers want to deal with, regardless of how simple it might seem to you or me.


If you're using just the pre-written commands of that sort, then there's no flexibility benefit to Python. Setting a meter is a trivial example, but doing things like creating buildings or moving objects around do a lot behind the scenes, and if you wanted to make things really flexible, you'd need to reimplement all of that in Python, handling all the details in the script.

If, conversely, you want to implement much more of the game mechanics in Python, then things would get a lot more moddable. This might include the visibility calculations, or fleet movement, or production or research queue updates, or resource sharing calculations, etc. This is a much larger undertaking, and would involve a lot more than just calling the existing commands that the parser provides for effectsgroups with equivalent Python code.


I don't see any point in rewriting the effects and conditions system to use all the same function, but Python syntax, rather than the current parser. It's not any more flexible a system if done that way, and in either case any new functions will need to be exposed to the parser or to Python by modifying C++ code.


Except, as mentioned about the four functions above, that's not the way conditions are used internally. It's not just "for objects, if condition, do X". And again, non-programmers don't like programming, even if it's simple programming in a relatively clean language.


If that's the case, why is it any different in Python, and why bother changing?


I think the way to approach this is to make a new Python interface for the server that exposes a bunch of commands to add systems, planets, buildings, ships, empires, ship designs, etc. A Python script would be called by the server and would use those commands to build up the universe. This would work pretty much the same as the AI scripts that are called each turn, and the AI interface that's exposed to Python to issue orders.

Having the current universe classes be exposed to the universe-generation script using the existing universe exposing Python code is optional, as the script could just as easily determine everything it wants to put into the universe within Python and never need to ask the C++ code for what the current state is, but then you wouldn't be able to use any of the existing C++ universe generating code from within Python, as you wouldn't know what those functions had created before your script starts adding its own stuff on top.


You can't have it both ways... either the scripting is low level and everything's implemented in Python and things are flexible and can make modding do things that the base game doesn't support, or it's high level scripting and you can't do anything you couldn't do without scripting and will have to implement any changes in C++ and then expose the new function to Python or to the parser in either case.