Potential replacement of FOCS with Python

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

Moderator: Committer

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

Re: Potential replacement of FOCS with Python

#16 Post by Geoff the Medio » Mon Oct 24, 2016 1:10 pm

em3 wrote:My 2c: Value could be made of type with __add__ and __radd__ methods overloaded...
Note that the current implementation has arbitrary parameters for what value = is set to... it can be just Value, or Value + 5, or Max(Value, 5), or Value*3 + 1, or sin(Value^log(Value)), or various other complicated expressions... Point being, don't just think of needing to overload the add methods due to that being the most common case.

User avatar
em3
Vacuum Dragon
Posts: 508
Joined: Sun Sep 25, 2011 2:51 pm

Re: Potential replacement of FOCS with Python

#17 Post by em3 » Mon Oct 24, 2016 1:55 pm

Geoff the Medio wrote:Note that the current implementation has arbitrary parameters for what value = is set to... it can be just Value, or Value + 5, or Max(Value, 5), or Value*3 + 1, or sin(Value^log(Value)), or various other complicated expressions... Point being, don't just think of needing to overload the add methods due to that being the most common case.
I just wanted to note, that example created by adrian_bother could be discouraging to some people because of the syntax:

Code: Select all

Set("Detection", Add(Value, 10))
, and that it can be simplified - actual arithmetic operation could be used instead of the lengthy "functions", like Add, Multiply etc. Granted, some of these functions would have to stay (Max, Sin, Log, ...).

I understand, that designing everything about potential foss replacement in python is a bit too soon, as far as this discussion is concerned. I just wanted to make it sound like a better idea to people that would be bothered by the implied complexity.
[...] for Man has earned his right to hold this planet against all comers, by virtue of occasionally producing someone totally batshit insane. - Randall Munroe, title text to xkcd #556

spikethehobbit
Space Squid
Posts: 58
Joined: Mon Aug 27, 2012 7:24 pm

Re: Potential replacement of FOCS with Python

#18 Post by spikethehobbit » Tue Oct 25, 2016 12:07 am

Effects groups could be made callable. That would eliminate any special handling or typing requirements.

Code: Select all

Special(
    name = "WORLDTREE_SPECIAL",
    description = "WORLDTREE_SPECIAL_DESC",
    stealth = 0,
    spawnrate = 1.0,
    spawnlimit = 1,
    location = lambda planet: (
        isinstance(planet, Planet)
        and (planet.planet_type not in [PlanetType.Asteroids, PlanetType.GasGiant, PlanetType.Inferno])
        and (planet.size not in [PlanetSize.TINY, PlanetSize.HUGE])
        and not (within_starlane_jumps(planet, jumps=2, condition=lambda system: (
            isinstance(system, System)
            and not [planet2 for planet2 in system.planets if planet2.owner]
            )))),
)
All contributions are submitted under GPL or LGPL v2 or later, or under appropriate Creative Commons licence, consistent with project guidlines.

User avatar
em3
Vacuum Dragon
Posts: 508
Joined: Sun Sep 25, 2011 2:51 pm

Re: Potential replacement of FOCS with Python

#19 Post by em3 » Tue Oct 25, 2016 10:07 am

spikethehobbit wrote:Effects groups could be made callable. That would eliminate any special handling or typing requirements.

Code: Select all

[...]
I think the whole point is for effects to not be executed in python, just constructed from python scripts (compiled into already existing engine structures).
[...] for Man has earned his right to hold this planet against all comers, by virtue of occasionally producing someone totally batshit insane. - Randall Munroe, title text to xkcd #556

spikethehobbit
Space Squid
Posts: 58
Joined: Mon Aug 27, 2012 7:24 pm

Re: Potential replacement of FOCS with Python

#20 Post by spikethehobbit » Wed Oct 26, 2016 2:35 am

em3 wrote:
spikethehobbit wrote:Effects groups could be made callable. That would eliminate any special handling or typing requirements.

Code: Select all

[...]
I think the whole point is for effects to not be executed in python, just constructed from python scripts (compiled into already existing engine structures).
Fair enough.
All contributions are submitted under GPL or LGPL v2 or later, or under appropriate Creative Commons licence, consistent with project guidlines.

Post Reply