Should BUG have its own DLL?

[EmperorFool]

A modified DLL in the Assets folder will cause a failure to load even if that DLL isn't actually used.

!!! Guess that shoots that idea down.

Does adding new game options affect save compatibility?

Ditto. I hadn't thought about that. Since they must be saved in the game (different for each game, passed to others when you send them a saved game), it must change the format. I doubt they made it so extensible as to allow a different set of options to exist as those the current game expects. Nothing else works that easily.

I don't know that I'd like to be locked into an interface choice for an entire game.

Yes, that would be a big downside. I think XML is probably the best way to go:

• No saved game problems
• Modifiable during a game (still gotta restart though)
• Ease of work for us
• Not so hard for users to modify

Heck, since I can read and write XML in Python, I could even add code to read in those options, put them onto the options screen, and write them back out. They even provide a separate GlobalDefinesAlt.xml for us to use. Of course, that makes integrating with DLL-mods trickier, but not impossible.

 

[The Doc]

Graphical? Here are some of the things that would be possible with a BUG DLL:

• Real hover help text for all BUG buttons (CDA, City Screen, PLE, etc).
• BUG features in city/unit hovers: turns to growth/shrinkage, border pop, GPP birth
• Net happiness/health in city hover: 2:happy:, 1:sick:
• Available building effects: +2:happy: Market (tells you that you will get +2:happy: if you build a market in this city)

There are more if you search the forums and our tracker. None of them are graphical in my mind, but maybe we're saying the same thing with different words?
[...]

Well, that's even worse, IMHO, because then everyone will have to use the DLL in order to get all available information. I don't think people will forgo the DLL if they can get better information with it. Although it would be optional it would become implicitly mandatory.

I voted No mainly because I'm worried that the team will succumb to the temptation to make multiple DLL changes. I'm sure that the motivation will be to improve the BUG experience. However I'm concerned that the rest of BUG will become dependant on the DLL and thus it will no longer be optional.

I'm concerned about this dependance, too.

 

[Cammagno]

Well, that's even worse, IMHO, because then everyone will have to use the DLL in order to get all available information. I don't think people will forgo the DLL if they can get better information with it. Although it would be optional it would become implicitly mandatory.
I'm concerned about this dependance, too.

I don't understand... how can be a bad thing to add more features that can't be added without DLL? If its use is optional, we'll have a separate install for BUG with or without it and it can be used with a CustomAssets install, I don't see any reason to oppose this improvement...

 

[EmperorFool]

I understand the argument that it will become so popular as to become the de facto standard, but I don't see why that's bad.

Do you oppose car stereos? You can buy a car without one, but most everyone buys one with their car or installs one later. But surely that doesn't mean we should all forgo music in our cars, does it?

It will be entirely optional and will remain that way.

If you're afraid that BUG's Python part will lag as more and more gets put into the DLL, rest assured that I vastly prefer to code in Python and will keep features in Python whenever I can. Some things just can't be done outside the SDK, and that's where the DLL comes in.

Or are you worried about it from a competitive-play point of view? That to compete you will be forced to use the DLL? In that case, I say BUG itself provides far more advantage than the features planned for the DLL.

 

[The Doc]

To be clear: I'm perfectly fine with new features but I'm worried because of the cons that ruff already pointed out.

Cons:
* It wouldn't be UNALTERED
* who would trust the BUG people not to totally change the game

Speaking for myself, I like BUG because it does exactly what its name says: providing a better experience with the original game and not bloating it up with hundreds of new units, buildings, civs, etc. The underlying game stays exactly the way the guys at Firaxis meant it to be but with a bit of tweaking on the interface. That's what BUG is all about. I just fear that this, well let's call it "vision" is diluted when a DLL comes into play.
Another point is merging mods with BUG which I guess gets a little tougher with a DLL. But that's only a side note.

 

[Cammagno]

To be clear: I'm perfectly fine with new features but I'm worried because of the cons that ruff already pointed out.

Speaking for myself, I like BUG because it does exactly what its name says: providing a better experience with the original game and not bloating it up with hundreds of new units, buildings, civs, etc. The underlying game stays exactly the way the guys at Firaxis meant it to be but with a bit of tweaking on the interface. That's what BUG is all about.

I 100% agree. I also don't want features that alter gameplay. But if I'm not wrong, we are speaking of having a DLL not altering gameplay at all, and a DLL wich will be the same plus bug fixes. Am I right about this? Not sure...

 

[EmperorFool]

Let me summarize by saying that I agree entirely with the desire for unaltered gameplay with cool features as well.

To address the 2 points quoted from Ruff.

1. It wouldn't be UNALTERED.

This would be true only of the BUG DLL merged with the unofficial patch DLL. The base BUG DLL would retain its unaltered gameplay status. It would add interface changes only. No new units and no gameplay fixes or changes of any kind.

2. Who would trust the BUG people not to totally change the game?

The same people that currently trust the BUG people not to totally change the game. Understand that the Python API allows plenty of opportunity to alter gameplay in many ways: fixes, additions, tweaks, and out-right cheating.

You may argue that there are some that can verify out Python changes but not our C++ changes, but there are people that can verify our C++ changes as well. In any case, has anyone fully vetted our Python code? If not, then it won't matter if fewer people will similarly not vet our C++ code.

I think people are underestimating the power available in the Python API. With the "chipotle" cheat code entered into your CivilizationIV.ini file, do this:

1. Hit tilde (~). You should see the developer console appear, a partially transparent text window, over the main interface.
2. Type "gc.getPlayer(0).changeGold(10000)" and hit enter.
3. ???
4. Profit!

This--and far more powerful effects--can be performed using Python by anyone without even entering the cheat code. The cheat code simply gives you access to the developer console.

 

[ruff_hi]

Is there a thread on how to grab the code underlying the DLL? (Or is the junk in 'CvGameCoreDLL' all that I need?).

What about a thread on how to compile said code?

I have 'Microsoft Visual Studio 2005' installed on my pc but I am pretty sure it is only the vb.net part of it. I can go back and grab the C part if required.

 

[EmperorFool]

Yes, the code you need is in CvGameCoreDLL. There are two threads in the Python/SDK thread for compiling the DLL: one using the free CodeBlocks program and another using Visual Studio or VC++ 2003 or something. The latter has a makefile I believe that can be used for your setup.

 

[The Doc]

Here's the thread with the instructions: click
But from what I read so far, it seems that it only works with Visual Studio 2003 or the VC++ Toolkit 2003. See here, for example: click

btw: Funny. I compiled my first DLL today to test something for FFH2.

 

[Sam_Yeager]

This would be true only of the BUG DLL merged with the unofficial patch DLL. The base BUG DLL would retain its unaltered gameplay status. It would add interface changes only. No new units and no gameplay fixes or changes

In fact one of the downsides of a BUG DLL is that it might well be harder to use BUG alongside DLLs such as unofficial patches or other mods. Having observed the frenetic speed at which this team knock out changes it's unlikely that the maintainers of other DLLs could merge in the changes fast enough even if they were so inclined.

Please note that I'm trying to point out legitimate concerns rather than be a old fogey here.

 

[EmperorFool]

@Sam - That is a valid point. In fact, all the points posted have been valid (except Ruff's; he's always wrong ). I know I cannot make everyone happy, but I'd like to at least shoot for content.

The unofficial patch changes infrequently, and Dresden has been contributing to both it and BUG, so I suspect he'd be more than happy to maintain a merged BUG DLL.

BUG's Python code would interact with the DLL in such a way as to not require it. It would check if it's present and alter its behavior based on that knowledge. Yes, there might be BUG features that would only work with the DLL, but given that the alternative is not to have the feature at all, I don't see a downside in that one regard.

As an example of good faith, look at the Advanced Scoreboard. Every feature that I added to the scoreboard is available within the AS and without, where possible (tech icons and grouping vassals under their masters just won't work using the regular scoreboard). I could have forced people to use the AS if they wanted Attitude Icons, the Power Ratio or Wort Enemy Icons, but I didn't.

To be honest, there was one feature where I was tempted to break this, but Alerum talked me out of it. I was just overworked and tempted by laziness. This demonstrates that the team is committed to options and will be able to keep each other in line.

 

[Willem]

I vote no. Having it's own dll would create all sorts of compatibility issues with other mods as we wouldn't be able to use it with those that also have dll's. Python file are fairly easy to merge using WinMerge, but not too many people would know how to merge C++ applications.

 

[Dresden]

I have 'Microsoft Visual Studio 2005' installed on my pc but I am pretty sure it is only the vb.net part of it. I can go back and grab the C part if required.

For MSVC, try Refar's instructions and makefile. It has worked wonderfully for me with only one small alteration needed relating to debug builds. As Doc mentioned, the actual compiler needed is the VS2003 one (download and installation are covered in Refar's PDF), but you might need the C++ component of VS2005 since you'll be using that as your IDE.

The unofficial patch changes infrequently, and Dresden has been contributing to both it and BUG, so I suspect he'd be more than happy to maintain a merged BUG DLL.

Yep. Unofficial Patch development has slowed considerably from when Solver started it, although I'll be making a new one sometime later this month. If BUG chooses to go the DLL route, I was thinking of creating a base DLL that would allow us to compile either a BUG-only or BUG-plus-UP DLL as we see fit based on a single #define (similar to how FAsserts are handled in the original SDK and how I'm incorporating AIAutoPlay into the UP). The current Unofficial Patch source has all changes documented (including the ones made originally by Solver) so it won't be hard.

 

[EmperorFool]

Having it's own dll would create all sorts of compatibility issues with other mods as we wouldn't be able to use it with those that also have dll's.

To reiterate, the BUG DLL would require the BUG Mod itself, but the BUG Mod would not require the BUG DLL. The BUG DLL would be entirely optional.

 

[ripple01]

I say go for it! I've been so wowed about what you guys have been able to do using Python that I'm drooling thinking about what you could do in combination with the SDK...

Cheers,
ripple01

 

[NikNaks]

How's this for an idea. It might be a little bit pie in the sky, but it'd be awesome if we could get it to work.

How about trying to re-launch the CCCP as part of BUG, with the DLL then containing as many of the SDK mods as is physically possible. It'd be a ton of work, but it's an idea.

 

[ruff_hi]

How about trying to re-launch the CCCP as part of BUG, with the DLL then containing as many of the SDK mods as is physically possible. It'd be a ton of work, but it's an idea.

No no no - out dam spot. CCCP was chock full of game changing things and if we include them, then the BUG users are going to really really hate us ... and I mean really

Look at the reaction we have generated just from thinking about the outside change of maybe including a DLL.

 

[EmperorFool]

Could you get us started with some links to those mods? Are they interface mods or gameplay-altering mods?

 

[NikNaks]

Ruff, the idea of the CCCP is that it merges mods without enabling them. You have to add a global define to actually change the game.

P.S. I haven't forgotten about fixing those icons, EF. I'm really busy but should have them done in a week or so.