Moving forward: Rhye's Legacy of Civilization - proposal

merijn_v1, firstly I'd like to commend you on your fine work. :goodjob: More people need to post their mod-mods, but this thread is hardly the place for it. Try starting a new thread in the mod-mod forum instead. This is my suggestion anyway.

Secondly I would like to point out that there currently is no such thing as Rhye's Legacy of Civilization - and chances are that there never will be. Unless some programmer type finds my proposal good enough to launch such an project - or something like it. Or perhaps something completely different.

What currently is available is Rhye's version of RFC (the official one) and then there is embryodead's version called RFC Epic/Marathon - which I personally view as the most up-to-date version. So my proposition is really - in all its simplicity - that someone should take it upon him- or herself to keep this version alive even after embroydead stops updating it. (Or he may keep doing it - what do I know? - then there really is no need for any of this.)

And lastly I would like to also make it clear that everyone is free to do whatever they want. I'm hardly someone who would have a say in who can do what - all I can do is voice my opinion and give suggestions - the same as anyone else. And I'm not capable to launch the project I'm proposing myself, as I'm yet to even look at the SDK. So I'm not nominating myself for anything at all.

So all we can do at this point is talk about what we as a community wanna do with RFC in the future. If any of it is to become reality depends on somebody actually doing it. In such an event I'll gladly assist with anything that is within my own means.

This is all.
 
I mentioned code improvements that make RFC more accessible for modders in my proposal (the essay at the top of this thread). I thought I'd explain in more detail what I had in mind. I apologize if this gets a bit technical.

Without talking down Rhye; the Python code achieving all the magic we know as RFC is all pretty much long chunks of code. As an example, there is a function definition (well, its really a class method, but whatever) called "resurrection". It contains about 200 lines of code, if you don't count commented lines and such. This function is called from one single place in the RiseAndFall.py file and it does everything required for respawning a Civ.

While that is well and in order, it isn't possible to call "resurrection" to make a custom spawn, like in a scenario or a mod-mod. So if you wanna say resurrect the Russian Civ after the Mongol onslaught in a historical scenario, this is no a no go. Because calling this function makes the code first check for Civs eligible for respawn and possibly picking one - and only then doing the actual resurrection stuff. This is of course no good for the scenario we had in mind, right?

So, currently one would basically have to copy-paste all the 200 lines of code, take out the stuff in the beginning about finding and selection a Civ, and then edit the rest of the code so that it does what you want it to. Ok, not so bad then. But what if you wanna do more respawns than just this one? And wouldn't it be useful to be able to do respawns in any scenario/mod-mod without going through all this programming stuff every time?

The solution then, would be to split up all this code into separate functions. So there would be one for initiating a "regular" respawn, then there would be one for selecting a random Civ among all the ones that are dead for the moment, and another one for initiating the actual respawn of a selected Civ, and so on. So you could just intersect the original code where you want and supply all the setting you wanna implement.

Because then it would be as simple as to add something like this to your own code to respawn Russia (as an example):
Code:
initResurrection(iRussia)
It beats having to deal with 200 lines of code, not?

The same thing could be done to other useful portions of RFC Python, like collapses, secessions and so on. You want to be able to initiate your own plague on a historical date, right? Sorry, not possible without doing your own custom Plague.py file, basically. But it could be made as easy as adding one line of code:
Code:
initPlague(1914, 45, 56)
...where the first value would be the starting year, while the second and third values are the X and Y coordinates for the breakout. (Additional settings are of course feasible, and don't bother looking up any historical or geographical references - I just made up the example.)

The next step beyond what I described above would be to move all the RFC specific stuff from the SDK into a XML setup. Like add a XML field to all Civs for birth date. No more recompiling the DLL file every single time you need to change a birth date! :rolleyes: In fact, all the setting for RFC could be transferred into an XML interface for easy modding. What about having a Stability.xml file to edit that allows you to access all parameters and rules involved with Stability? :eek: No programming required to achieve just about anything with the current stability system. (Tech and Civic XML entries could also have their own stability fields.)

All these things are possible - its only a question of getting the work done. I intend to rework some of the Python stuff myself, but anything beyond that is currently out of my reach. But there are also real programmers here, somewhere...
 
Not really a bug, but I think it is kinda lame that when I start as America my world map consists of the eastern seaboard of North America. I guess everyone who settled that area suddenly forget their current world geography? I think the Americans should get maps for whatever civs have cities flip to them on that first turn.

I pretty much agree here, and so did these people...

Maybe this could be an addition to Rhye's Legacy of Civilization...
 
I like very much the idea of code improvement and enabling modular add-ons.

But I'll go a little further with suggestions:

- Taking out from the SDK as much of Rhye's code as possible, and relocating it to Python. This may seem a weird idea, but it's already done in RFC:Europe. To some extent: settler maps for example are in python. This way you don't have to recompile the DLL to change them. Much more modder-friendly.

- The existance of options in custom scenario for possible modular modmods.

And an option for something which doesn't currently exist, but does in my imagination for a future project:

Choose between playing with the old settlermaps or... generate them at game start or... play without settlermaps (in other words: dynamic settlermaps)!!
 
Yeah, new game options could be added in the future - as long as the "regular" rules are default and not changed. Good idea.
 
Sorry I didn't understand the exact meaning of this thread. But I do know. Unfortunately, I didn't feel well today, so I didn't move my work to a own thread. I hope I can do it tomorrow.
 
My idea: bring back Baba Yetu as (one of) main song. I miss it but don't want to play vanilla just for that :)

This is something you can do yourself very easy. Go to the XML folder --> Audio. Open AudioDefines.xml

Go to the 3rd section (SONG_OPENING_MENU)
Change "Sounds/Soundtrack/OpeningMenu" into "Sounds/Soundtrack/OpeningMenuCiv4" (Just ad "Civ4" after the line)

Save the file and it should be done.
 
I don't think moving most of the SDK code to python is a good idea, especially since Python is much slower. However, we could use XML tags to make them easily changed. For example, we could add all the civ trait stuff to Civ4TraitInfos.xml and add a CivTrait field to Civ4CivilizationInfos.xml. Even easier to change than python, with all of the SDK's speed advantages. IMO we should try to move much of the python code to the SDK if feasible.
 
deanej has got the right idea. :agree: This is actually what I meant myself.
 
merijn_v1, don't feel like I reprimanded you or anything. Because I'm not a moderator, administrator or anything like that.
 
LuKo, adding superficial stuff like music, art and also additional city names and whatnot should be within my initial proposal also. Because it doens't affect game play, but rather enhances the enjoyment of said gameplay. :goodjob:
 
merijn_v1, don't feel like I reprimanded you or anything. Because I'm not a moderator, administrator or anything like that.

Don't bother.;)
 
I don't think moving most of the SDK code to python is a good idea, especially since Python is much slower. However, we could use XML tags to make them easily changed. For example, we could add all the civ trait stuff to Civ4TraitInfos.xml and add a CivTrait field to Civ4CivilizationInfos.xml. Even easier to change than python, with all of the SDK's speed advantages. IMO we should try to move much of the python code to the SDK if feasible.

It's not about "code" but data which is hardcoded in the DLL. Moving it from SDK to Python (or XML) has no effect on speed whatsoever, because it's read once, when you start the game. 3Miro did it for RFCEurope, making it easier to edit.

XML is the more CIV4 way to do it, but frankly, Python is more convenient when you have 30 x 30 tables to edit, even with a commercial XML grid editor.
 
Moving Python code to C++ of course makes it faster, but at the same time harder to edit.

Having RFC settings/data in Python vs XML would be a matter of making modding easier for people who know programming vs people who don't. But then again - anyone can learn programming. Basic Python at the very least.
 
Top Bottom