RFCE 1.3 Playtest Feedback

I don't have any WIP, aside from the 1200 AD scenario. But that will come after the release.

I'm excited for the 1200AD scenario. Keep up the good work guys!

I wanted to ask:
Are you sure that 1200 is the best possible start date for the scenario?
++ had it in 1260 for example, after the most important mongol campaigns, which certainly has some advantages.
I don't want to stay that's better, rather wanted to start some brainstorming about it.
 
Scotland should be removed from the English respawn zone, especially if Scotland exists. I don't think I have to explain why this is wrong...

Edit: Also, perhaps Spain's respawn area could be restricted to just Galicia-Leon-Castile proper, so that it won't just try to grab all of Aragon or Cordoba's cities (same problem as above).

Spain's respawn area might stay though, I remember now that I intentionally set it up this way.
Aragon respawns in Naples, and it's probably better to represent the spanish with a bigger power base in the Iberian peninsula if they respawn.
 
It makes less sense if Aragon and Andalusia are both alive and well, only to have all their cities except their capital taken by the respawn. Perhaps there should be an exception for that kind of scenario?
 
It makes less sense if Aragon and Andalusia are both alive and well, only to have all their cities except their capital taken by the respawn. Perhaps there should be an exception for that kind of scenario?

Yeah, will look into it
Not sure what would be the best approach in these situations.
For now, will reduce Spain's respawn zone too.

Playing, but not noticing any problems to feed back with so far.

:king:
I still have multiple pages off stuff to do/consider on my todolist, but great news nevertheless :)
 
Uploaded another commit to the SVN a couple minutes ago.
It would be great if you could test out the .dll changes from the last 2 commits (whether everything works correctly with the DCN refreshment, all 4 UPs, and the resistance changes):

Dynamic civ names also refresh on start of a new turn, not just on specific events like new city foundation or city ownership change.
Coded missing Moroccan UP: +1 production and +1 commerce on all desert tiles (apart from peaks), additional +1 commerce and +1 food from oases
Added an extra aspect to the Cordoban UP: excess health contributes to city growth, but only if it's not starving (idea from DoC) - perfect for the 1st UHV
Coding updates in the English and Kievan UPs, no gameplay changes though
Less resistance on city conquest: multiple things affecting it, but usually around 1 turn with 1-2 population, 2 turns with 3-5, 3 with 6-9, 4 with 10-14, 5 with 15+
 
recently i got two CTD and a strange thing.

it should be a danish game in 1380
a novgorodian game in 1320 and their F8 screen

View attachment AutoSave_AD-1380 Turn 260.CivBeyondSwordSave
View attachment AutoSave_AD-1320 Turn 240.CivBeyondSwordSave
Civ4ScreenShot0019.JPG
 
Yeah, there is a small oversight in merijn last commit.
Will fix it in a sec.
The VictoryScreen will work afterwards.
 
That happens when someone reverts perfectly working changes. :p

Yeah you are right, I was the one who forced you to readd some of the changes
So I take all the blame, that's the least I can do :)
 
Why Kuban Foreign/Unstable area for Ottomans?
The fortress of Azov (Azak, Tana) and Anapa many years have been strongholds of the Ottoman Empire on the east coast of the Black Sea.
 
Yeah, there is a small oversight in merijn last commit.
Will fix it in a sec.
The VictoryScreen will work afterwards.

Found some more (and yes, all of them were in your first commit, so I won't take blame for these :p)

- Mercenaries.iMercPromotion in the CvMercenaryManager.py. You removed the referenced variable from Mercenaries.py (actually we both did, so it's a tie here :D)
It's only a one-line fix (will commit it as soon as sourceforge is back from maintenance), but caused some serious issues on the mercenary screen

- The resource-disappearence on city ownership change causes some issues if there isn't any resource in the plot whenever either of the 2 cities is acquired. Mostly harmless, but still annoying, since it only works correctly once, while those cities usually change ownership many times.
I added a call so it only activates on the 1200 AD scenario, but probably it would be better to solve this another way. Maybe by adding a horse resource somewhere for good, or to simply use the disappearance on a fix date?

- And a really serious one, unfortunately:
The new storeddata handling from SoI seem to totally break mercenary promotions.
(I'm not entirely sure, but almost certainly that's the cause)
After the quick fix to the first problem, mercenaries still won't get any promotions.
Furthermore they get another instance of the mercenary promotion whenever you click on them.. so you can end up with mercenaries with x number of mercenary promotions only.

I didn't look into the SoI code in detail yet - ie, how compatible it is with the things 3Miro and I did with RFCE previously.
While the problem with promotions is also easy to fix in itself, I'm still really concerned about this one:
The worst in it that it possibly means, that some other storedata functions will behave in an unexpected manner too? :confused:
Pls look into every aspect before you try to adapt changes like these from other mods.
 
Found some more (and yes, all of them were in your first commit, so I won't take blame for these :p)

:lol:

- Mercenaries.iMercPromotion in the CvMercenaryManager.py. You removed the referenced variable from Mercenaries.py (actually we both did, so it's a tie here :D)
It's only a one-line fix (will commit it as soon as sourceforge is back from maintenance), but caused some serious issues on the mercenary screen

- The resource-disappearence on city ownership change causes some issues if there isn't any resource in the plot whenever either of the 2 cities is acquired. Mostly harmless, but still annoying, since it only works correctly once, while those cities usually change ownership many times.
I added a call so it only activates on the 1200 AD scenario, but probably it would be better to solve this another way. Maybe by adding a horse resource somewhere for good, or to simply use the disappearance on a fix date?

I thought that the code removes a resources if there is any and does nothing if there isn't any, without issues.
My reasoning for disappearing this resource is that I don't want too much difference between the 500 and 1200 maps, and therefor the resource distribution. But as gilgames mentioned, Byzantium without horses is a no go. So I wanted that horse resource only to be there for Byzantium. Maybe it can disappear if Byzantium collapses in the 1200 AD scenario?

- And a really serious one, unfortunately:
The new storeddata handling from SoI seem to totally break mercenary promotions.
(I'm not entirely sure, but almost certainly that's the cause)
After the quick fix to the first problem, mercenaries still won't get any promotions.
Furthermore they get another instance of the mercenary promotion whenever you click on them.. so you can end up with mercenaries with x number of mercenary promotions only.

The problem is not in the StoredData, but in the manager. Every time you open it, a new merc promotion is added to the list of promotion. I will fix it.

I didn't look into the SoI code in detail yet - ie, how compatible it is with the things 3Miro and I did with RFCE previously.
While the problem with promotions is also easy to fix in itself, I'm still really concerned about this one:
The worst in it that it possibly means, that some other storedata functions will behave in an unexpected manner too? :confused:
Pls look into every aspect before you try to adapt changes like these from other mods.

IIRC, it shouldn't cause that much troubles, as it's only a container storing information about the game. Basically all I did is changing the loading and saving procedure. In the old situation, the sd was loaded and saved each time a value did change. Now it only loads upon saving/starting a game and it saves only when saving the game.

But anyway, I will try to look into every aspect when I adopt changes. (I can't promise it I will succeed ;))
 
OK. This is very very annoying!

I decided to squat Austrians with Hungary and at spawn I killed all their units. A turn passed and they got an archer from Wien. So opened wb forced peace and killed the archer. Then moved my units into the cities. Next turn this pic awaited me:
Civ4ScreenShot0020.JPG

I agree new civs need some help, but no dead civ deserve it! They shouldn't come back from the grave! I cannot fight against zombies...
 
It's an RFC mechanic designed specifically so that you can't kill newborn civs so easily. Only troops inside their flip zone will flip IIRC though.
 
IIRC, it shouldn't cause that much troubles, as it's only a container storing information about the game. Basically all I did is changing the loading and saving procedure. In the old situation, the sd was loaded and saved each time a value did change. Now it only loads upon saving/starting a game and it saves only when saving the game.

Yeah, but something is definitely strange connected to this.
In rev. 1180 the mercenary screen worked fine, but when you changed it in 1181 it did not (mercs get an additional promotion whenever you click on them)
I don't think any of the other changes can possibly cause it.
Sure, the mercenary thing was an easy fix, but this is still a valid reason for some concerns.

But anyway, I will try to look into every aspect when I adopt changes. (I can't promise it I will succeed ;))

Ohh don't worry, I also make coding mistakes all the time :)
For example after the first version of my right-away instability from revolution code, each time you clicked on the Exit button in the Religion Screen it added -8 swing stability.
As it turned out Firaxis coded the screen in a way, that the Exit and Convert buttons are not only in the same position, but they are actually the same (on click at least) :crazyeye:
Also I forgot that it's possible to switch civics/religion on popup too (when you first discover/acquire it)
So in the end I had to find a new approach for the whole thing... :rolleyes:
At least now it works perfectly (hopefully)

Anyway, after my quick rant, back a little bit. I guess my point was this:
Maybe I'm wrong in this, but sometimes I feel that the main reason you want to adapt some coding/formatting changes is just because they are handled that way in DoC.
While Leoreth undoubtedly does a wonderful job there, not necessarily everything is an improvement for RFCE too.
Some of the coding is handled totally differently here, and with a reason.

(Having said that, edead's StoredData system is definitely an improvement.
I'm not talking about this, rather generally)
 
Anyway, after my quick rant, back a little bit. I guess my point was this:
Maybe I'm wrong in this, but sometimes I feel that the main reason you want to adapt some coding/formatting changes is just because they are handled that way in DoC.
While Leoreth undoubtedly does a wonderful job there, not necessarily everything is an improvement for RFCE too.
Some of the coding is handled totally differently here, and with a reason.

(Having said that, edead's StoredData system is definitely an improvement.
I'm not talking about this, rather generally)

There is likely some truth in there. During your "break", I've done some things with DoC code, so I got quite familiar with that and forgot about some differences between the mods. Also because I didn't mod RFCE during that time. Most of the code I copy is because it should make the code faster, without changing the effect. Which, if it works, would be an improvement. But it's likely that I forget about the differences and it doens't work as well in RFCE.
 
There is likely some truth in there. During your "break", I've done some things with DoC code, so I got quite familiar with that and forgot about some differences between the mods. Also because I didn't mod RFCE during that time. Most of the code I copy is because it should make the code faster, without changing the effect. Which, if it works, would be an improvement. But it's likely that I forget about the differences and it doens't work as well in RFCE.

Fair enough.
Don't worry, I will help you sort it out.
But one always have to be very cautious when adding stuff from other mods.
Compatibiltiy issues can be extremely annoying. In some cases it's very hard to spot that they are the real cause, and usually it's not trivial to fix them.
 
Top Bottom