Part
name = "SP_CLOUD"
description = "SP_CLOUD"
class = General
mountableSlotTypes = Internal
buildcost = 1
buildtime = 1
location = All
effectsgroups = [
EffectsGroup
scope = NumberOf number = 1 condition = And [
Planet
InSystem id = Source.SystemID
Not Planet type = [Asteroids GasGiant Barren Desert]
]
activation = And [
Random probability = 0.15
InSystem
]
effects = AddSpecial name = "CLOUD_COVER_MASTER_SPECIAL"
Not sure how it then chooses within available options but that's the basics of the code needed.
Mat Bowles
Any code or patches in anything posted here is released under the CC and GPL licences in use for the FO project.
MatGB wrote:Not sure how it then chooses within available options but that's the basics of the code needed.
If you don't specify a sort key and sorting method, then NumberOf should pick the specific number of objects randomly from whatever matches the condition.
spikethehobbit wrote:I'm testing this now. If it works, I'll push it out to github.
Ok, so we'll hold off further testing/merging your PR until you update your branch. Pls post a notification here when you've done that, because github doesn't send out notifications when the branch of a PR gets updated/rebased.
Also, git rebase officially sucks.
Really? What problems exactly did you ran into? I've found git's rebase to be a very powerful and helpful thing... of course when you have to resolve conflicts it can get tedious, but merge isn't any better...
git rebase is powerful, and usually works very well, but sometimes it screws up without warning. It has managed to eat ship_parts.txt twice now without detecting a conflict. Not fun.
In any case, it seems to be working as of latest master. Now to decide which monsters get which new weapons. Any suggestions would be much appreciated.
All contributions are submitted under GPL or LGPL v2 or later, or under appropriate Creative Commons licence, consistent with project guidlines.
Weapons are assigned to monsters now. The patch is ready to apply.
A few (possibly related) issues remain with bombardment:
1) Killing population should prevent growth that turn, especially if it is reduced to 0. At present, max pop planets whose growth rate is greater than the attack strength are not affected by bombardment.
2) Sometimes population will return after it has been wiped out. This might be a display error.
3) Ships assigned to bombard will show in the client as still bombarding on the next turn, but don't actually do anything. To get them to bombard two turns in a row, the player must cancel bombardment /twice/ and then command bombardment again.
All three together makes it difficult to reliably exterminate a planet.
All contributions are submitted under GPL or LGPL v2 or later, or under appropriate Creative Commons licence, consistent with project guidlines.