FfH version 1.10e

Mercenaries:
Ah ok i thought an AI hat actually used in in the game i was playing as there were several guys who had a name and in (Scout) or something after the name. Even one guy had a rudiculous amount of Promotions and 106 Xp and it was not a hero i thought (or do the grigori have an Scout hero?- and as i was the only one on the continent who made war he could not have gotten the xp via combat) so i thought they were hired Mercenaries.

About the Missionaries. You can change everythin in the SDK and most is in my opinion even more simple than in Phython and i feel the solutions you can create in C++ will be often faster than Phython equivalents (for example you can store often used data on the object so that it has not to be calculated each time and by the numbers of things we do calculationtime will get an increasinly important issue). Now we could change the Missionary code so that he askes your phyton code if the unit can spread religion. That should be doable, but i would prefer handing it back to the old code and doing the changes there. That will make it much easier with the AI. That thing about Veil and Order can be implemented within the can spread function in Unit.cpp easily. The percentage could be linked to a variable in global defines if you like. Thats not much to do. I might come with a solution as soon as this mesh is ready:
 
Chalid said:
Mercenaries:
Ah ok i thought an AI hat actually used in in the game i was playing as there were several guys who had a name and in (Scout) or something after the name. Even one guy had a rudiculous amount of Promotions and 106 Xp and it was not a hero i thought (or do the grigori have an Scout hero?- and as i was the only one on the continent who made war he could not have gotten the xp via combat) so i thought they were hired Mercenaries.

The Grigori have access to adventurers, which can be heroes of a bunch of different unit types.

About the Missionaries. You can change everythin in the SDK and most is in my opinion even more simple than in Phython and i feel the solutions you can create in C++ will be often faster than Phython equivalents (for example you can store often used data on the object so that it has not to be calculated each time and by the numbers of things we do calculationtime will get an increasinly important issue). Now we could change the Missionary code so that he askes your phyton code if the unit can spread religion. That should be doable, but i would prefer handing it back to the old code and doing the changes there. That will make it much easier with the AI. That thing about Veil and Order can be implemented within the can spread function in Unit.cpp easily. The percentage could be linked to a variable in global defines if you like. Thats not much to do. I might come with a solution as soon as this mesh is ready:

I agree that changing in the SDK is simpliar and will perform better. But from a support aspect its much more dangerous. I would love to get one modified dll and never change it again, that way we dont risk new SDK crashes. I know thats not entirely possible but I will appreciate anything we can do towards that goal to minimize the amount of SDK changes and get Mod changes pushed out to python and xml.

Also we will have to update when the expansion comes out and that is pretty easy to do for python changes, especially in mod specific files but much more difficult with SDK changes. In fact one of the largest risks to the death of this mod is an engine update that breaks our SDK changes so badly that we aren't able to adapt.

Python issues are also a lot easier to isolate than SDK issues. Part of this is just the nature of calling out to a scriptiing language, by nessesity you leave the code as is except for a single call, return and then back to the normal code. It makes it very easy to isolate changes and trap errors.

Lastly I like being able to piggyback on Firaxis's testing. It is much easier to break things in the SDK than it is in python, and Firaxis has a team testing (as well as all the players) to catch problems that are running the default DLL. The closer we stay to that DLL the better chance we have that our issues will be caught in that testing.
 
Ah the Adventurer of course that must have been one of those i've complete forgottem them!!

I see we have a kind of philosophical discussion here. I agree so far as changes should be done as much as possible in Phython under two conditions:
1) The Change does not need an major addition to the SDK. If you have to implement new things in the SDK to allow the Change to be done in Phython than you can do all - or everything that is not used in different ways - in the SDK.
2) Performance. If you can do something much faster in the SDK than in Phython it should be done in the SDK.

ABout not beein able to adapt SDK changes. The badest thing will be that we have to rewrite some code.
So but now I have to go back to that Dragon, or Kael won't get a new toy these days.
 
I'm playing as Bannor and when I recruit using a Commander I get some Axemen instead of Guardsmen (which are the Bannor replacement). Not a big deal, but a discrepancy.
 
Some Gameplay Issues:

- Ancient Forests grow to fast.
- Fireball Spell does not conjure a Fireball (at least he did not for my Mage with Spellextension II)
- Charm can be castet at Tiles one does not even see...
 
woodelf said:
I'm playing as Bannor and when I recruit using a Commander I get some Axemen instead of Guardsmen (which are the Bannor replacement). Not a big deal, but a discrepancy.

Hmm.. Im going to have to think about how to get this to pull the civ specific unit.
 
Chalid said:
Some Gameplay Issues:

- Ancient Forests grow to fast.

Good point, I halved the chance per turn that a forest would into an ancient forest (from 10% to 5%).

- Fireball Spell does not conjure a Fireball (at least he did not for my Mage with Spellextension II)

Im not able to reproduce this. If you can send me a save I would love to see it.

- Charm can be castet at Tiles one does not even see...

Yeah, I dont have range in place for the targeted spells yet.
 
Originally Posted by woodelf
I'm playing as Bannor and when I recruit using a Commander I get some Axemen instead of Guardsmen (which are the Bannor replacement). Not a big deal, but a discrepancy.


Hmm.. Im going to have to think about how to get this to pull the civ specific unit.


That should be easy:

Code:
iUnit = ((gc.getCivilizationInfo(pPlayer.getCivilizationType()).getCivilizationUnits(gc.getInfoTypeForString('UNITCLASS_SCOUT')));
Should do the trick. Note its UNITCLASS instead of UNIT.
 
Does anyone else think the Copper Golems are brutal as barbarians? Even at pow 5 they're squashing the AI and me!
 
Just discovered that Guardians of Nature doesn't give a happiness bonus for Ancient Forests, and doesn't list ancient forests in the terrain types that are supposed to get the bonus either. I think it would make the most sense to have it give a bonus along with forests and jungles, otherwise it'd be most effective for elves to cut down ancient forests to replant them as ordinary forests, which I doubt is the intent...
 
Does anyone else think the Copper Golems are brutal as barbarians? Even at pow 5 they're squashing the AI and me!

I think I've found out why. Copper golems are actually power 9!, like they were in 1.0. I thought it pretty odd that I could built units so powerful so early while playing the Luchuirp, has to be some kind of bug.

Regarding the Luchuiurp, I find that the inability to get worker units in the beginning of the game can really hurt. I had to spend about 40 turns building my golem workshop before I could even start building a Mud Golem. Perhaps remove the building requiriment from this particular unit?
 
Corlindale said:
I think I've found out why. Copper golems are actually power 9!, like they were in 1.0. I thought it pretty odd that I could built units so powerful so early while playing the Luchuirp, has to be some kind of bug.

Regarding the Luchuiurp, I find that the inability to get worker units in the beginning of the game can really hurt. I had to spend about 40 turns building my golem workshop before I could even start building a Mud Golem. Perhaps remove the building requiriment from this particular unit?

I know, I changed them to 5 for my testing because they are overpowering.
 
Yeah, I'll fix the luchuirp and their golems.
 
Chalid said:
I see we have a kind of philosophical discussion here. I agree so far as changes should be done as much as possible in Phython under two conditions:
1) The Change does not need an major addition to the SDK. If you have to implement new things in the SDK to allow the Change to be done in Phython than you can do all - or everything that is not used in different ways - in the SDK.
2) Performance. If you can do something much faster in the SDK than in Phython it should be done in the SDK.

Yeah, and part of it comes from the fact that Im not a programmer. I didn't have any code experience before Civ4 was released so Im still learning all of this. After we release the public version if the SDK stuff works out well and we don't have big issues I will be more likely to put more and more stuff there. If we have big issues and having the changes in the SDK complicates troubleshooting and stability I'll tend to look for non-SDK solutions to problems. Even if they perform worse.

So lets make sure the code we have is good, release our version on the 19th and see where to go from there. Hopefully my paranoia is unwarranted.
 
Did you read my above post about the GreatCommanders recruit?

Another thing i will check is your improve all land things like ancient forests or Genesisi. I'm not sure how you solved these but i might possibly have a faster solution (all in Python).

And did you get the graphics i send you?
 
Chalid said:
Did you read my above post about the GreatCommanders recruit?
Im glad you said something, I missed it, I will get it in. Thats exactly what I needed.

Another thing i will check is your improve all land things like ancient forests or Genesisi. I'm not sure how you solved these but i might possibly have a faster solution (all in Python).

I have a begin turn check that runs through, looks to see if the plot qualifies for an upgrade and applies a configurable chance that the plot will upgrade.

And did you get the graphics i send you?

Yeap, Im just getting back to everything now. I spent the past 3 days sightseeing in London and south/central England (got to go hang out in the center of Stonehenge and say "mmm... free obelisks").

So I actually havent looked at them yet but I will be today or tomorrow. They will definitly all be in the next version that will come out this weekend.
 
Maybe Imps aren't in yet? A CTD like that sounds like an ART_DEFINE issue.
 
Back
Top Bottom