FfH2 0.33 Changelog

31. Added the Psychopath event (Nikis-Knight).

I wonder how this is like. Is it for Perpentach (or Balseraphs) or is it like a citizen of your empire goes nuts and start to fire his crossbow around in school?
 
4. Illusions cant be upgraded to golems/elementals/etc anymore.

I'm going to miss that, kind of. I remembered seeing it a few times, and it was nice to be able to kill things with Govannon's summons, but I don't recall if that happened only on the third turn with summoners or what. It can even make a twisted kind of sense: the illusion has lasted so long, it is so powerful, that it's essentially real: anything that fights and dies really dies out of sheer terror, not wounds inflicted. That's assuming it's not somehow overpowered for illusions to eventually be able to kill things.
 
One thing that really annoys me is that if you buy a tech in advanced start you never get the free unit it would provide, or trigger events like the one that founds the Guild of the Nine. I usually play with adanced starts, and know from experiance that this can be a big deal. Normally you can adopt any religion (assuming you aren'tone of the agnostic leaders) by researching the tech, even if you can't found it. With advanced starts, buying the tech early is a complete waste of gold which forces you to wait for the religion's natural spread. I guess the free unit to the first to reach/buy the tech could be overpowered (since one player is given the option before the other civs start the game), but the units that go to anyone when they get the tech shiould really still be granted. Can this please be changed in 0.33?


I also think that Palaces need to be made purchasible in advanced starts, and cheap. The best Capital City site is not often visible when you first start the game, but you can't purchase visibility unitl a city is placed. Being able to change the capital would be a big improvement, assuming that you can't just make it so that you don't need a city to buy visibility or techs.


Advanced Starts also really need to let you know what leader you are. Traits can play a huge part in deciding what should be bought, but can currently only be surmised by buying units that get free promotions from those traits.
 
29. All spells are now pre-qualified in the SDK to minimize python calls and improve performance.

i re-read the list and this scared me. will it make it harder for people to mod spells now? as it was, python was a pain, but now with SDK involved... im screwd :(:(:(
 
i re-read the list and this scared me. will it make it harder for people to mod spells now? as it was, python was a pain, but now with SDK involved... im screwd :(:(:(

It means more XML fields to use the same kind of pre-reqs which the spells had frequently used in the Python scripting. Like specific Unit, Specific Civ...

Yeah I looked through every spell in FfH and added an xml requirement for it if there wasnt one. For modders that means its easier to create spells. I added the following xml attributes for spells:

BuildingPrereq
BuildingClassOwnedPrereq
CorporationPrereq
FeatureOrPrereq1
FeatureOrPrereq2
ImprovementPrereq
PromotionInStackPrereq
bCasterMustBeAlive
bCasterNoDuration
bPrereqSlaveTrade
iCasterMinLevel

A modder can still create spells just using python prereqs and none of these requirements. But base FfH doesn't have any like that.
 
I was pretty sure you wouldn't remove the ability to use python prereqs, but it nice that to have it confirmed.


What about base terrain prereqs? Wouldn't spells like Vitalize, Scorch, and Spring need tags for those too in order to not need python prereqs?

There should also be a iPlotCounterPrereq tag. (Sure, Sanctify would only need to know if it is > 0, but having more control is always nice.)


It may also be good to remove some SDK code that and use some of the tags instead. For instance, the bCasterNoDuration tag for summoning spells would make the block on summons summoning unneeded, and the terrain prereq tags could eliminate the need to check to see if it is a valid terrain



I'd still really prefer it if you changed the format to allow arbitrary numbers of each prereq, and alternate sets of prereqs for the same spell. While I'm on the subject of unlikely spell system changes, I'd like to reiterate that you should really try to get targeted spells working through a SDK code similar to bombing/paradropping/air combat/ranged attacks, which the AI uses quite effectively. Targeting individual units may be hard (although very nice) but I don't think it would be all that hard to teach the AI to target tiles. I'd also really like spells to be able to pass lists of valid targets (probably one list of units and one of tiles, plus possibly also lists of players or cities) into the python results so we don't have to cycle though so many tiles and check so many units before doing something to them.
 
I was pretty sure you wouldn't remove the ability to use python prereqs, but it nice that to have it confirmed.

What about base terrain prereqs? Wouldn't spells like Vitalize, Scorch, and Spring need tags for those too in order to not need python prereqs?

Vitalize, Scorch and Spring don't have a single terrain type they are castable on. Spring can be cast on any terrain. All three of the spells you mentioned already have SDk prereqs (they all have promotion requirements).

0.33 still uses python prereqs. It just has some SDk prereqs for every spell first, so that the python prereq fires less frequently. Check the 2nd post int he modders thread for a better description.

There should also be a iPlotCounterPrereq tag. (Sure, Sanctify would only need to know if it is > 0, but having more control is always nice.)

In some cases Sanctify can be cast even if iPlotCounter is 0. Every addition to the SDK has a cost and benifit. Adding one just to get rid of a python check isnt that important, adding one to make sure every unit int he game doesnt do a ython check every turn is a huge benifit (hopefuly that post I refered to above helps explain).

It may also be good to remove some SDK code that and use some of the tags instead. For instance, the bCasterNoDuration tag for summoning spells would make the block on summons summoning unneeded, and the terrain prereq tags could eliminate the need to check to see if it is a valid terrain

There isnt a block in the sdk to keep summons from summoning. There is a block to keep summons from summoning their own unit type (to prevent loops). That is different than the bcasternoduration tag.

I'd still really prefer it if you changed the format to allow arbitrary numbers of each prereq, and alternate sets of prereqs for the same spell.

This isnt a format change. Its a move from an attribute to an array of attributes which has a bigger memory footprint, more difficulty to manipulate and general nastiness to deal with. I avoid arrays whereever possible, so it would need to be a pretty big beniifit before I would consider adding one. dont think that if I just add a few more tabs to the spreadsheet it will all work.


While I'm on the subject of unlikely spell system changes, I'd like to reiterate that you should really try to get targeted spells working through a SDK code similar to bombing/paradropping/air combat/ranged attacks, which the AI uses quite effectively. Targeting individual units may be hard (although very nice) but I don't think it would be all that hard to teach the AI to target tiles. I'd also really like spells to be able to pass lists of valid targets (probably one list of units and one of tiles, plus possibly also lists of players or cities) into the python results so we don't have to cycle though so many tiles and check so many units before doing something to them.

If you dont think it would be hard to do, feel free to try it out. its a pretty considerable task for me. Most noticeably from the Ai perspective. Dont think that because the AI uses some functions that are similiar to targeting that its easy to co-opt that for spell targeting. Each of the functions you listed are specially coded for the game and for the ai to function. They dont share code with each other, and they wouldnt share any code with any spells that we wrote to use it.

The afterworld scenario has a very modest targeting function which is kinda cool so I played with that a bit too. They got around most of the difficulty by making the option only available to human players, the ai never uses it.

I hear what your saying. But the paradrop/bombard functionality is pretty useless to us for the hardest part of setting up the system.
 
Having just finalized a setup for using arrays prolifically myself, I must agree with Kael that it is NOT a pretty thing. Especially if you attempt to minimize your memory footprint by allowing the sizes to be mutable. I still haven't solved a few of the crashes I am getting, but have isolated them to chunks of code that work perfectly written precisely the same way elsewhere. And all of that is for individual pre-reqs. The backflips you must perform to have a single entity be allowed multiple pre-req layouts would be sickening to sort through (primarily due to prereqs being checked via multiple pathways and functions)
 
I'd say most definitely usually it's only some of the letter patches that maintain previous saves
 
Yeah I looked through every spell in FfH and added an xml requirement for it if there wasnt one. For modders that means its easier to create spells. I added the following xml attributes for spells:

BuildingPrereq
BuildingClassOwnedPrereq
CorporationPrereq
FeatureOrPrereq1
FeatureOrPrereq2
ImprovementPrereq
PromotionInStackPrereq
bCasterMustBeAlive
bCasterNoDuration
bPrereqSlaveTrade
iCasterMinLevel

A modder can still create spells just using python prereqs and none of these requirements. But base FfH doesn't have any like that.

Oh thank god for that, :lol:
 
After removing Lanun cove-terraforming will you consider making ports buildable next to each other again?
Should not be a big problem anyways since ocean / coastal tiles give one Food less than lakes (which were the main reason coves next to each other were overpowered in the first place in addition to more solid comerce due to reliable proximity to cost.) so ocean coves / water-tiles max out at 4 Food, 1 Hammer 4 Commerce for them (which should not be a problem compared to many other options wich even become better in the comming version. Like Agriculture-Aristocracy.) + you have a hard limit now of water-tiles available in fat-cross.
Still more expensive to build than cottages unless work boats don't need to be sacrificed for them (which whould someway be ok because of the slightly higher yield.).


Lest the Lanun becoming a subpar civ. That whould at least preserve some of its power near water at least (which they should clearly have imo. Perhaps im not the only one to think so...). Which without it whould considerably suffer (and give the lanun very few incentive to stick to coast mainly. Because of the many very solid options inland. Making them to a subpar land-civ with some mediocre options on coasts giving them at least some playability on water-heavy maps.).

Sure that whould give a big incentive to build cities on small islands. But that must not be bad and is rather thematic for them imo. ;)

And perhaps you can even cut some cluttering code and checks that way getting additional performance and more intuitive use for new players. :)


Still not very happy with this change since it makes a very solid civ that was fun to play and not so terribly map dependent one to a mediocre one at best (And really advantageous only on very water-heavy maps.) + highly map dependant again no matter if above suggestion is heeded or not.
Another instance where constant naging of the blancing-fanatics has made the game less fun.


Will there be any consideration / chance of putting water terraforming back in in any way (be it by a late-game Lanun unit or a Tier 3 Spell of any sort.)?


Albeit from an AI perspective and time where the ability did arrive it could be seen as making sense since i don't know if AI could be made to grasp worker-coves and tactical terraforming from the earliest stages might seem a bit cheesy.
(If those 2 were the main reason with a higher emphasis on the first one ignore a large part of above rant since they are very improtant to make the AI cometitive and round up the game even if they detract from some of the fun.
But please consider the suggestion of ports beeing able to be built next to one another again. Im sure its possible to teach that one to the AI even better than with the limit in place.)
 
Exactly as you said "creative terraforming" was never the intent and wouldnt be useable by the AI.

I dont like the concept or the aesthedics of pirate cove spamming (ie: no limit on range). But I would be welcome to upgrading the pirate harbors and pirate ports to make them more profitable. In my mind the pirate improvements should be cool, rare points of interest on the map. Imperative for the Lanun to guard (getting them pillaged should be costly) but I want the Lanun costs to look open and idealic, not full of improvements.
 
Top Bottom