Should BUG have its own DLL?

[ruff_hi]

This is a poll. It doesn't promise anything ... except that if you vote in it, your vote will be recorded.

The issue being polled is "Should BUG have its own DLL?"

Pros:

• BUG could fix some of the known bugs in 3.17
• BUG could add some features that are not available via python
  • HOF view
  • better hover information
  • new logger items (spaceship parts)
  • etc

Cons:

• It wouldn't be UNALTERED
• who would trust the BUG people not to totally change the game
• etc

Naturally, all source code will be available on our public SVN repository just as it is with the rest of BUG.

 

[Dresden]

Not voting yet, just giving some random responses.

BUG could fix some of the known bugs in 3.13

Is that a typo or would a BUG DLL actually be based on 3.13 rather than 3.17? (or worse, have versions for both patches?) Either way I would hope that if bugfixing is one of the goals that a BUG DLL uses all or part of the unofficial patch as a base. i.e. "no need to reinvent the wheel"

It wouldn't be UNALTERED

That would be my primary concern. Does this mean BUG would become BAG? The fact that it does not alter gameplay is IMHO one of BUG's primary "selling" points. Given that and keeping inline with the grand spirit of BUG's efforts to keep everything optional, I would hope that a custom DLL would be optional too. This means that all the snazzy new features which rely on DLL modification would have to gracefully fall back if the SDK additions aren't present. I've been trying to think of a simple python-accessible version indicator for the Unofficial Patch and something like that and/or the use of exception-handling seems necessary.

who would trust the BUG people not to totally change the game

The same people who trust Bhruic, Solver, and myself with Unofficial Patches as well as all the other modders whose stuff they use. I assume BUG's DLL would be open source like the rest of it and anyone with major concerns can either read the source and compile it themselves or opt out of the DLL.

 

[ruff_hi]

Is that a typo

Yes - duh - fixed.

Given that and keeping inline with the grand spirit of BUG's efforts to keep everything optional

I would hope so. I was actually thinking that we could have a DLL tab and the first one is 'enable BUG DLL' (off by default). If this option is not checked, then the 3.17 stuff kicks in and any python additions that rely upon the BUG DLL gracefully skip their stuff. In fact, I would even like it to do that if the BUG DLL was not there ... something like:

def isBUGDLLPresent():
   try:
      return BUGDLL.isPresent():
   else: (or what ever the correct code is)
      return False

def isBUGDLLEnabled():
   if not isBUGDLLPresent():
      return False

   #return result from DLL option tab

Thus the new python stuff check the second function before getting too carried away.

I assume BUG's DLL would be open source

My thoughts too.

 

[alerum68]

What no Banana Option? I think it would be a great idea for us to expand into the .DLL. I think we're pushing our limits on things we can do now without going into it, and feel many great ideas are having to be pushed to the side because of those dreaded words, "Would need to be in the .DLL".

 

[EmperorFool]

I don't see why we would lose our Unaltered status. So far, all of the ideas that I remember saying those dreaded words to are still interface changes -- not gameplay changes. Am I missing something.

Yes, the DLL would be open source, installed alongside the other code I should think.

 

[Dresden]

I don't see why we would lose our Unaltered status. So far, all of the ideas that I remember saying those dreaded words to are still interface changes -- not gameplay changes. Am I missing something.

Ruff mentioned bugfixes in the FP; if bugfixes are included, then it would alter gameplay. If they are not, then BUG would still be Unaltered. Although in the latter case I'd probably wind up running a hybrid Unofficial Patch/BUG DLL myself.

 

[GooglyBoogly]

As long as the .Dll doesn't change any gameplay elements (including bugfixes and AI tweaks) then I am all for it. Otherwise it would be enough just to link to any respective dlls/threads. If you want to combine any/all of those changes then go right ahead - it just won't be BUG anymore.

 

[ruff_hi]

As long as the .Dll doesn't change any gameplay elements (including bugfixes and AI tweaks) then I am all for it. Otherwise it would be enough just to link to any respective dlls/threads. If you want to combine any/all of those changes then go right ahead - it just won't be BUG anymore.

That is a good point. We could make them optional (with OFF being the default).

 

[Cammagno]

I like to have a BUG DLL, but:
a) separate released
b) not altering gameplay (orwith altering features minimized, optional and off by default)

 

[JujuLautre]

If you decide for it, could you please give the source with the mod's download, as there is the source with Warlords and BTS? I'm sure I am not the only guy compiling his own dll

 

[EmperorFool]

To reiterate: All source code will be delivered with any DLL and be available on our public SVN repository just as it is with the rest of BUG. Ruff, could you please alter your first post to reflect this?

I would vote for two DLLs: one with and one without the bugfixes. The reasons include

• some crazy people might not want the bugfixes (new poll?)
• other mods including BUG
• the changes will probably be disjoint and easy to merge

As for having a single DLL that can turn options on and off, I think that's possible by adding new game options. I don't think we should add a Python callback to determine the state of an option because that might be a performance hit. At worst we could move DLL options to the CIV4Defines.xml, making them harder to modify and requiring a restart to take effect.

I for one am excited about enhancing the hovers. The only sad part about an optional DLL is that if it weren't optional, we could have real hovers for all of BUG and its buttons. Sure, we can make those optional as well, but that's going to involve some serious grunt work.

 

[The Doc]

To be honest I'm rather not in favor of a BUG-DLL. On the one hand people can always copy a bugfixed DLL into their BUG folder (or is more difficult than that?) and don't necessarily need one from BUG.
On the other hand, to me it sounds a bit over the top to provide a DLL just for "graphical" reasons. The result would probably be that although the DLL would be optional everybody would use it to get the best graphical experience.
Another point is the installation as a main mod. Though, I don't make use of this option: Is this still possible with a DLL?

 

[ruff_hi]

To be honest I'm rather not in favor of a BUG-DLL. On the one hand people can always copy a bugfixed DLL into their BUG folder (or is more difficult than that?)

No it isn't. Just drop the required DLL in the right spot and you are good to go.

Another point is the installation as a main mod. Though, I don't make use of this option: Is this still possible with a DLL?

Yes it is. Just drop the required DLL in the right spot and you are good to go.

Funny how the answer to both questions were exactly the same.

 

[The Doc]

No it isn't. Just drop the required DLL in the right spot and you are good to go.
No it isn't. Just drop the required DLL in the right spot and you are good to go.

Funny how the answer to both questions were exactly the same.

Ruff, you are a true comedian.

 

[EmperorFool]

On the other hand, to me it sounds a bit over the top to provide a DLL just for "graphical" reasons.

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?

Another point is the installation as a main mod. Though, I don't make use of this option: Is this still possible with a DLL?

No it isn't. Just drop the required DLL in the right spot and you are good to go.

Funny how the answer to both questions were exactly the same.

It would have been funnier if the answer to the second question was correct.

You can plop the DLL into the BTS install folder's Assets folder to have it available to BUG installed in CustomAssets, but it may conflict with other mods that don't have their own DLL. This is how most people install the unofficial patches.

If we make the DLL smart enough to detect when it's running with and without BUG, we can make this option work.

Or am I talking out my non-mouth orifice again?

 

[ruff_hi]

It would have been funnier if the answer to the second question was correct.

Hey - read my edited post above. I fixed that a good 7 minutes before you posted.

 

[LunarMongoose]

I've always been a big fan of adding support for XML tags for different colors for the names of National Wonders, Great Wonders, Team Projects and World Projects...

I was also the first to add text showing the Bombard Limit of siege units... and still the only one who seperates Lethality (ie damage and thus kill chance) out from Intercept chance on intercept-capable units, to accurately reflect the difference between guns and missiles among other things...

But my ideas get ignored, or stolen woot, a lot around here, so eh what do I know.

Here's my ancient, dust-caked thread if you're interested.

 

[Sam_Yeager]

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.

 

[EmperorFool]

I'm concerned that the rest of BUG will become dependant on the DLL and thus it will no longer be optional.

I swear to never allow this to happen to BUG as long as I have any say in the matter. I would like the Python side of BUG to be enhanced by the DLL but never require it.

I freely admit that it would be nice to be able to require the DLL (less work means more new features), but I am not willing to lock out all the modders out there that have enough skill to merge BUG with their mods but not enough to do the same with a DLL.

Does that help alleviate your fear? What if I pinky swear? Scout's honor? (note: I was an Indian Scout, not a Boy Scout)

 

[Dresden]

You can plop the DLL into the BTS install folder's Assets folder to have it available to BUG installed in CustomAssets, but it may conflict with other mods that don't have their own DLL. This is how most people install the unofficial patches.

I doubt any BUG DLL changes would actually conflict with non-DLL mods. However those who play locked modified assets games (such as GOTM/HoF) would be required to either install BUG as a Mod, forgo the DLL, or juggle their files since a modified DLL in the Assets folder will cause a failure to load even if that DLL isn't actually used. (I'm still not sure I understand the reasoning there unless it was simply the easy way out.)

As for having a single DLL that can turn options on and off, I think that's possible by adding new game options. I don't think we should add a Python callback to determine the state of an option because that might be a performance hit. At worst we could move DLL options to the CIV4Defines.xml, making them harder to modify and requiring a restart to take effect.

Does adding new game options affect save compatibility? Even if it doesn't, I don't know that I'd like to be locked into an interface choice for an entire game. Unless of course we could use CyGame.setOption() to change them on the fly (looks like you can but I've never really tried). XML defines are certainly doable if necessary though.