Stability, 'Core areas', and Mongolia.

Mayan spawn date is pretty bad for Iroquois, true.... Perhaps I could use the Vikings instead (another easy 'Minor civ' change.) But if I have to change the DLL for the spawn date (I would use 900 or so AD for the Iroquois, because I want to give them a chance to achieve their first UHV, 'Be the first to Constitution'.) can I also change the number of Civs, thus making any civ-removal redundant?

Once I have read and comprehended your excellent textbook link (it's going great!) should I have the minimum Python knowledge to mod the UHV/UP?

And one more thing. Does PyScenario help with spawn triggers? If I wanted the Iroquois to spawn in 960 AD, would PyScenario help? or would I need to go into the DLL anyway? Thanks in advance (and also for your HUGE help with Python- you may have kicked off a modder here!) Baldyr.
 
Mayan spawn date is pretty bad for Iroquois, true.... Perhaps I could use the Vikings instead (another easy 'Minor civ' change.) But if I have to change the DLL for the spawn date (I would use 900 or so AD for the Iroquois, because I want to give them a chance to achieve their first UHV, 'Be the first to Constitution'.) can I also change the number of Civs, thus making any civ-removal redundant?
Changing the setup of Civs, period, is hard with RFC. This includes changing the number of Civs and removing any...

Once I have read and comprehended your excellent textbook link (it's going great!) should I have the minimum Python knowledge to mod the UHV/UP?
Great! That book (How to Think Like a Computer Scientist) will pretty much teach you the works. (I never even read the last two chapters, as I thought is was going into peripheral territory.) Sure, there is always more stuff to learn but you will know about every aspect there is to Python programming. Unfortunately the book won't teach you about Civ modding as such, but I can teach you the basics once you know Python.

If you get through the book you will pretty much be equipped to redesign all the Python in RFC. I don't even think Rhye knew half of what that book can teach you when RFC was originally made... (Not to be disrespectful, but I get that from looking at the actual code. So you don't necessarily have to do things the way Rhye did - do what the book tells you to instead.)

The real test of your progress comes later in the book - there is card game simulator (Old Maid Hand) used as an example for learning something called Object-Oriented Programming. I thought it was very hard to follow the whole thing, but once I did manage to understand every aspect of the code (I got help :p), then I knew how to do the really advanced stuff with Python. Also, I realized that CivIV Python uses Object-Oriented Programming, so the book was actually really helpful!

So be prepared to tackle that hurdle once it comes along. I think I have the entire script for the example game if you need to look at it. (The example code is spread out over several chapters, which doesn't make it easier to follow.)

And one more thing. Does PyScenario help with spawn triggers? If I wanted the Iroquois to spawn in 960 AD, would PyScenario help? or would I need to go into the DLL anyway?
You mean changing the spawn date? No, this has to be done both in Consts.py and in the SDK. The hard part isn't supposedly to change the date itself, but rather to recompile the DLL. Unfortunately I wouldn't even know where to start...

PyScenario is just a tool to help non-programmers spawn units and cities and whatnot, or to change map tiles, flip cities, grant Techs or the like. If you learn actual Python there is nothing PyScenario can do that you cannot do on your own (minus all the limitations). You can take a look at the CivIV Python API to whet your appetite...
 
If you get through the book you will pretty much be equipped to redesign all the Python in RFC. I don't even think Rhye knew half of what that book can teach you when RFC was originally made... (Not to be disrespectful, but I get that from looking at the actual code. So you don't necessarily have to do things the way Rhye did - do what the book tells you to instead.)

God worked with clay first and then evolution took over. Hence all the imperfections.
(After all, we would do much better without a tailbone or appendix)
(This from a non-coder.)
 
God worked with clay first and then evolution took over. Hence all the imperfections.
(After all, we would do much better without a tailbone or appendix)
(This from a non-coder.)
Sure, and I'm not trashing Rhye, not at all. As someone pointed out in another discussion; RFC was really pioneer work - back in the early days. We have to appreciate the fact that the mod has evolved - and thankfully continued to evolve - over the years.

With that said, there is both a tailbone and an appendix in the RFC code I would very much like to remove. And I probably will, given the time to do the work. (It would probably both run a lot faster and be a whole lot easier to mod.) No reason to play around with clay, really, since its the mod-modders who pretty much have taken over development. (Yeah, the inmates are running the asylum! :crazyeye:)
 
I'm making an Iroquois barebones file now. Damn, I wish I hadn't started this before you fixed the mod's tailbones! :lol:
 
Don't question my coinings.

(It's a file containing all the things I'll need to create the Iroquois, without doing anything itself. Perhaps it's got some other name?)
 
Don't question my coinings.

(It's a file containing all the things I'll need to create the Iroquois, without doing anything itself. Perhaps it's got some other name?)
Like your work-form, your draft or your sketch? I have no idea what material you have collected but its good that your going forward, on some level.

How are the studies progressing, by the way? Give a holler if you get helplessly stuck.

And you might wanna start your career as a programmer with something a bit lighter than adding/changing a Civ to RFC. What about scripting Native units and cities to replace the soon-to-be displaced Mayans? Then you maybe could go on to the UP and the UHVs? This would be good clean Python work for your to get started. :king:
 
Sure, and I'm not trashing Rhye, not at all. As someone pointed out in another discussion; RFC was really pioneer work - back in the early days. We have to appreciate the fact that the mod has evolved - and thankfully continued to evolve - over the years.

With that said, there is both a tailbone and an appendix in the RFC code I would very much like to remove. And I probably will, given the time to do the work. (It would probably both run a lot faster and be a whole lot easier to mod.) No reason to play around with clay, really, since its the mod-modders who pretty much have taken over development. (Yeah, the inmates are running the asylum! :crazyeye:)

I've never gotten up to my elbows in coding but would you care to enlighten me? :)
 
I've never gotten up to my elbows in coding but would you care to enlighten me? :)
On the shortcoming of the mighty Rhye? Do you really think this is appropriate? :eek:
Spoiler :
Well, Rhye is using something called classes. This is part of Object-Oriented Programming - the kind of programming that the game itself uses - but RFC isn't utilizing any of the features that come with OOP. There are clear advantages here to be taken advantage of, like storing values as fields in the actual class instance. (Otherwise those classes could be taken out entirely - if it didn't involve editing the entire mod, every single line of it.)

This brings us to the main point of concern, as RFC relies on "pickled script data" to store values. A lot of values. And this is going on numerous times on any given turn. Pickling and unpickling requires precious computing resources and takes up time. The mentioned class instance fields would be a much better way of storing much of that data.

I actually did some of the work involved in taking out the pickling entirely (well not entirely, its still required at save/load game) but by doing so realized that it can't be done with entirely. But I think most of it could still be axed, perhaps as much as 90%! :eek:

The reason why RFC isn't as easily moddable as one would wish is the way the code is structured. While Rhye has divided the code in a given module (or .py file) into say 10-20 functions, the same code could have been restructured into perhaps as many as 100-200 separate functions. I believe this would go a long way towards being able to make your own custom respawns and things like that. (Right now you'd pretty much have to copy-paste some 100 lines of code and try to sort everything out yourself to fit your purpose. It would be easier to just call-up the functions you need and feed settings you wanna use into these.
 
DLL recompilation is rather easy, it just takes a while to do it (about 10-20 minutes, if not more, to compile a full DLL). The hard part is actually doing the editing IMO (but I have no programming experience beyond what I've more or less taught myself).
 
DLL recompilation is rather easy, it just takes a while to do it (about 10-20 minutes, if not more, to compile a full DLL). The hard part is actually doing the editing IMO (but I have no programming experience beyond what I've more or less taught myself).
Yeah, both programming and compiling would be easy once you know how to do it. And I think that the compiling part with CivIV is pretty much the same process each time, so once you figure it out you only have to remember what you did right the last time. Not to say there can be some pitfalls along the way, before you figure it out... :rolleyes:

But once you know programming it isn't hard either. Because otherwise you don't really know programming. :D The good news is that you can learn how to do this also.
 
Yeah, programming has definitely gotten easier, especially because of this site. The people here are always willing to help a n00b.
 
Once you understand shooting it isn't hard consistently getting head shots on deer at 30 metres with an M14 :mischief: also when hunting for a meal, copper>lead

basically everything gets easy when you know how to do it
 
Back
Top Bottom