The One DLL Project

NikNaks

Deity
Joined
Jul 25, 2006
Messages
2,972
Location
England
I have a dream that one day, people will not have to worry about merging the DLL for themselves. I have a dream that all SDK configuration will be done in easily accessible XML.

But then again, sometimes I dream ninjas are in my bedroom. :eek:

...

I'm serious, though. Do you guys remember the old CCCP (Civ Community Core Project or some such) for Warlords? The premise was that all the DLL mods that were around at the time would be merged into it, so that only the coders themselves would ever have to worry about it. If I remember rightly, it didn't turn out all too well. The BtS iteration of this is the World of Civilization mod, but there are some really buggy parts of that code, and the team themselves are busy and often don't like to share, which is a real shame, as they are talented coders in their own right.

But why can't we try again? We have a great community here, and I think, with a little effort, we could really make this work. The idea is simple, but the execution would be difficult. Personally, I'm not an experienced coder, but I'm eager to learn, and am happy to spend time organising and running the project.

So this is the idea. We build a stable SDK with as many features as we can add. New features should always be rigorously tested before being released. Every feature we add should be configurable by XML. Any variables should be exposed and everything should be documented. This DLL can then be used by almost every mod, bar those who have such radical changes that it would be unfeasible to (for example, Fall from Heaven would almost certainly have to made drastic modifications).

But where do we start? Well, johny smith of the WoC recently took the stable modular loading extensions from the main mod. I think this merged with RevolutionDCM would be an excellent base to build upon. We would have both stability, and, with the WoC modular loading, a vast flexibility for enabling components: for example, empty tags, or those that have no change from the normal value, can simply be omitted. I'm sure, with some work, someone could nail the mess that is that files require schemas to be in the same folder.

This sounds daunting, I know, and if you've made it this far, I appreciate your interest. But now it's down to you. If you're interested in this idea, and want to help out in any way, please post or PM me. I'm mostly looking for people who have either modded the SDK before, have C++ mods currently running now, or who just know their way around a block of code.

I may add to this post in the future to give more information or more details, but I think I've talked about everything I wanted to.

Thanks for reading,
NikNaks
 
Yeah, appreciate your joy for this great game and making it simple to customise. As you have said, the philosophy of RevDCM is to build a very stable core with solid balanced mod code that is controllable via a XML and thus by a user interface. You are correct about the possibility of carrying on the tradition. I have thought about building a WoC interface into RevDCM. It would be nice to make RevDCM more plug and play in theory. At this stage it is only a concept and I have little idea of the actual WoC design and how practical it is to make a RevDCMWoC.

As you have said, it would probably need to be a new project, because RevDCM as it is now has reached the stage where it should remain backward compatible with the major submods of RevDCM out there. WoC would break this most likely.

johny smith of the WoC recently took the stable modular loading extensions from the main mod...

Some one has already attempted it?
Cheers.
 
It sounds nice to do, but it could have all sorts of strange side-effects. For example, when I made my expanded city radius mod, this made even regular cities get huge health bonuses from forests, and the national park wonder got bonuses from preserves 4 tiles away, even if the city itself couldn't work them.
 
Yeah, appreciate your joy for this great game and making it simple to customise. As you have said, the philosophy of RevDCM is to build a very stable core with solid balanced mod code that is controllable via a XML and thus by a user interface. You are correct about the possibility of carrying on the tradition. I have thought about building a WoC interface into RevDCM. It would be nice to make RevDCM more plug and play in theory. At this stage it is only a concept and I have little idea of the actual WoC design and how practical it is to make a RevDCMWoC.

As you have said, it would probably need to be a new project, because RevDCM as it is now has reached the stage where it should remain backward compatible with the major submods of RevDCM out there. WoC would break this most likely.
I think that's a good summary. Of course, in an ideal world, there would be no need to create a sub-mod, as everything would be in it. But that's still pie in the sky. ;)
Some one has already attempted it?
Well, not this idea, no. He's worried that work is going to get lost within the WoC, so he's stripping a lot of the buggy work and has created WoC Lite. I think the first step would be merging that in, and working out any issues we find.
It sounds nice to do, but it could have all sorts of strange side-effects. For example, when I made my expanded city radius mod, this made even regular cities get huge health bonuses from forests, and the national park wonder got bonuses from preserves 4 tiles away, even if the city itself couldn't work them.
Wow, really? At first glance, I would consider that a bug, but even if it is, I have no idea how to fix it. If the idea is really going to work, there'd need to be some internal help to try and tackle odd things like this.
 
Mostly, you will need someone who is dedicated to JUST merging code, and not generating much new code on their own. Simply due to the volume of DLL modding which exists out in the community already, and continues to be developed. But a close second hurdle is that you need someone who is absolutely phenomenal at AI programming. With so many things meshed together and so much of it being largely optional, you need an AI which can react appropriately depending on what is active and what is not, without bogging down the turn speed. If you incorporated FfH and Fall Further work you need the AI capable of using spell/ability information, and ignoring flight and espionage. If you brought in Stack Attack capabilities you need AI which properly balances/blends their stacks. Bring in a stack limiting mod and you need the AI to abandon the concept of SoD's. And beyond raw mechanics, there are many AI decisions which are actually influenced by how your XML is established. Primarily the order in which to make build decisions within a city, but extending well beyond that even. Many things in the DLL for base BtS make assumptions that the overall game structure will not be changed in certain ways, and when a modder doesn't know this going in, they get unexpected complications. Many people who toy in the DLL have changed these behaviors to suit their own XML and overall mod strategy.

It would be a VERY ambitious project, but I must admit I would be in favor of it, as long as I didn't have to be a part of it directly ;) I have coded tons of things which would be of great use to normal Civ mods, but don't have the time to code the rest of my ideas, let alone export everything back to base BtS code personally. Seeing someone else make it more widely available would be quite pleasant.
 
Well, the merging of components would inevitably be a slow process in order for the DLL to remain bug-free and stable. There are a few people out there who have merged SDK without any prior knowledge, but I've seen that it's often a "click and hope for the best" kind of approach. I want to avoid that where I can, and do everything bit by bit. Nice and slow. The kind of vision that I'd like to see is that of something like Conqueror's Delight by Dom Pedro. There's a ton of functionality, but it's down to XML to mess with it.

And as for AI coding, there just needs to be someone who enjoys that sort of thing on the team. I can see that being a problem at a later date, though. Most of what I was originally thinking of merging to begin with doesn't really involve AI scripting. For example, the WoC stuff is all about making it easy for modders, not about changing the game as such. But fair point, none the less.
 
Wow, really? At first glance, I would consider that a bug, but even if it is, I have no idea how to fix it. If the idea is really going to work, there'd need to be some internal help to try and tackle odd things like this.

It is a bug: Cities are not supposed to benefit from something unless it's in their workable radius. I did manage to fix the bug, but it goes to show how changing one thing can impact another. And in some bases be difficult to spot.
 
I think its a good idea, one could start with all the small new XML tag entries that exist, since they dont actually change the gameplay, then move onto the larger gameplay changes that can be "optioned out"
Exactly my thinking.
Its times like this, that make we wish I knew how to do this stuff.
Me too. :( I guess we should try learning it. :crazyeye:
It is a bug: Cities are not supposed to benefit from something unless it's in their workable radius. I did manage to fix the bug, but it goes to show how changing one thing can impact another. And in some bases be difficult to spot.
Well, one thing I'm not claiming is that C++ is easy. If anything, I'm saying the opposite. The less we plebs have to worry about it the better :lol:

I'm glad this is generating some interest. I'm planning to open a project on SourceForge soon, so if those of you who are interested could send me their usernames, I'll add them right away.

Everyone else, keep posting your ideas and suggestions. :goodjob:
 
I'm planning to open a project on SourceForge soon, so if those of you who are interested could send me their usernames, I'll add them right away.

Everyone else, keep posting your ideas and suggestions. :goodjob:

Perhaps you should consider working on the World of Civilization mod which hopes to do the exact same thing. Or at least steal their code and branch it.
 
I've got a fair bit of programming knowledge but very little internet download capacity. Could someone summarise what Johny has created without me having to blow 10MB downloading it?

Here is a guess:
1) He has only modified the SDK DLL for better bts and autoplay only. There is no WoC code in the DLL.
2) He has included python from WoC designed to effect modular loading in WoC format.
3) This means that WoC modules such as new civilisations/religions etc can be plugged in, but more advanced modules that require AI modifications in the DLL, cannot.

Is that correct?
Cheers.
 
Perhaps you should consider working on the World of Civilization mod which hopes to do the exact same thing. Or at least steal their code and branch it.
Did you read my entire post? I thought I'd summed up my position here:
The BtS iteration of this is the World of Civilization mod, but there are some really buggy parts of that code, and the team themselves are busy and often don't like to share, which is a real shame, as they are talented coders in their own right.

But why can't we try again?
As it happens, I've been a member of the WoC team for a long, long time, but it's just not working out.
I've got a fair bit of programming knowledge but very little internet download capacity. Could someone summarise what Johny has created without me having to blow 10MB downloading it?

Here is a guess:
1) He has only modified the SDK DLL for better bts and autoplay only. There is no WoC code in the DLL.
No. All of the code for the modular loading is in the SDK. There's also some bits and bobs for the scrolling civics screen that need to be there, along with snippets to enable the giant GameFont files.
2) He has included python from WoC designed to effect modular loading in WoC format.
The Python included is mainly for interface mods and the scrolling civics screen.
3) This means that WoC modules such as new civilisations/religions etc can be plugged in, but more advanced modules that require AI modifications in the DLL, cannot.
Yes, there's no AI coding in there. However, any modules that use tags that aren't in default BtS won't work either.

If you are planning to d/l it, do it sooner rather than later. He's going to re-add a ton of work to that Lite mod, so it's going to become heavier veeeery quickly.
 
@NikNaks
Thanks for the info. Have downloaded woc_lite and will take a close look. As a first thought, I cannot see why woc-lite could not be built into RevDCM as it is and also remain backward compatible with the current range of submods. It's contentious but I cannot see why not at this stage. I agree with you that the way to go would be to add basic WoC compatibility to a RevDCMWoC test build, get it stable and then work from there. If woc-lite could be put into the RevDCM core and kept there, that would be a big bonus for long term maintenance and improvement considering that Jdog5000 and I are working together on different parts of RevDCM on sourceforge.

In the mean time, really good confidence information would be if anyone on this forum is or has used woc-lite, and whether they think it is a good stable build already, or what the problems are with it.
Cheers.
 
That's great news if it makes it into the RevDCM core! I've asked in the thread, and am awaiting reply, but from what others have posted, there seem to be asserts that appear with the AIAutoPlay component. However, as that's already in Revolutions, that shouldn't be an issue.

You will get at least one error message, but that's simply the code looking for an "MLF" file in the Modules folder. I think one is included in the download, so just dropping that in the folder should stop it from appearing.
 
Thanks NikNak
Understand the concept and it looks pretty promising. There is a fair bit of work and stability testing to do. In the mean time, I don't have much data volume with my ISP so hunting around for quality modules that could plug into WoC lite is a bit inefficient. So far have come up with this link which points to modules that are quite dated. Am testing the build by plugging in a religion from that list of modules:
http://forums.civfanatics.com/showthread.php?t=285008 post #3

What other good modules links are there if any?
Cheers.
 
Thanks NikNak
Understand the concept and it looks pretty promising. There is a fair bit of work and stability testing to do. In the mean time, I don't have much data volume with my ISP so hunting around for quality modules that could plug into WoC lite is a bit inefficient. So far have come up with this link which points to modules that are quite dated. Am testing the build by plugging in a religion from that list of modules:
http://forums.civfanatics.com/showthread.php?t=285008 post #3

What other good modules links are there if any?
Cheers.

Please don't include new religions, or units, or corporations or anything like that into the RevDCM core, 7 religions is enough.... And if people want new content like that they can make merges...
 
@Phungus
Appreciate the point not to add this kind of stuff to RevDCM. The point is not what WoC modules could or could not be included with RevDCM, but whether the WoC plugability concept works with RevDCM at all.
Cheers.
 
Glider, johny tells me he's contacted you, so hopefully you guys can work something out between you.

Has anyone else read this? I guess many people dismissed my PMs as spam, which is a shame.

If you have read, please feel free post your comments, thoughts or suggestions. :D
 
Question, what if you designed the game to expose most functions to python, and wrote a script that generated the python code based on which modules were selected to load? For example, I wrote a mod to expose the combat code to python, and then wrote the combat code in python (easier than compiling it every time, and python's memory management makes code writing certain things simpler).

So you'd have a huge number of DLL functions with a "python override" clause much like some of the current functions used for Final Frontier. A modder uses a moduler python file and, when their mod is set to enabled, the launcher program references that modular python file in the eventmanager or other relevant python file. In this way a single DLL could control almost anything by simply adding files.

A separate but related project if you would be so kind to embark on it is to design the code to real the XML in an adaptive manner. That is, to auto-create variables based on what the XML schema says instead of needing a separate line in the DLL for each of the variables.
 
Back
Top Bottom