Development Thread

[EmperorFool]

I have just committed a smallish change that may have a big impact. When coding, you can now alt-tab out of the game, modify some Python, and alt-tab back in. All Python modules will be reloaded so you can see your changes immediately.

Now, this used to work before (partially), but PLE broke that feature entirely. Not only have I fixed the problems with PLE, but I've fixed the problems from the original Civ4 code as well!

The problem child was CvMainInterface, as usual. This screen is created only once and kept showing forever. The problem is that the Python objects holding its state are recreated when the modules are reloaded, but the interfaceScreen() function isn't called again.

My first attempt was to simply call that function after initializing BUG, but that broke the minimap. So I've split the function into two parts. The new part sets all of the instance variables (self.foo), leaving the interface-drawing code in interfaceScreen(). Whenever you add a new element to this screen, you need to make sure you split apart your code accordingly. Look at the examples; it's pretty straight-forward.

To be perfectly clear:

The initState() function must not draw on the screen.

and

The interfaceScreen() function must not create any instance (self.foo) or global variables. It is free to alter existing ones, however. Understand that after reloading Python modules, interfaceScreen() won't be called again.

Now, these are tricky areas and I was careful, but I wouldn't be surprised if we get new problems. So let me know ASAP if you see any crazy behavior.

 

[ruff_hi]

I have just committed a smallish change that may have a big impact. When coding, you can now alt-tab out of the game, modify some Python, and alt-tab back in. All Python modules will be reloaded so you can see your changes immediately.

This is a HUGE help - thx for all the hard work EF. Just to point out, this is particularly useful when you are fiddling with screen layout - alt-tab out, change by a few pixels, back in to see if it all lines up.

 

[EmperorFool]

Yes, but keep in mind that stuff on the Main Interface will not be redrawn. I think all other screens get redraw via interfaceScreen() whenever they are opened, but I'm not sure. If you find a screen doesn't show your changes, let me know and I'll take a look.

 

[Dresden]

I have just committed a smallish change that may have a big impact. When coding, you can now alt-tab out of the game, modify some Python, and alt-tab back in. All Python modules will be reloaded so you can see your changes immediately.

Oh you rock. It's like Christmas comes early.

Spoiler :

smiley abuse == happiness

 

[Dresden]

the latest in tick marks - added a whip threshold indicator. I'm not sold on it - but it is an option. The yellow behind the light blue is particularly hard to see.

Could it be made so that the whip ticks are shown so long as whipping is generally allowed even if that city can't whip yet? The situation I mean is if it would take like 3 pop to whip something but you only have 2 available due to small population. It'd be useful to see where that whip enabling point is.

 

[Dresden]

I just realized tonight that the EventSigns component might will slightly alter gameplay if BUG is used with BTS 3.13; it contains modified versions of the EventInfos and Event Python and was based on the 3.17 files. So some changes 3.17 made to events could will be unintentionally carried over. (I say "some" because the triggers aren't included.) I'll try and track down the exact differences but if anyone has any good ideas on how to resolve it, don't be shy.


EDIT: These are the changes that 3.17 made which would be altering gameplay for a 3.13 BUG user; descriptions come from 3.17 patch notes
1) "Blessed Sea" event no longer tied to a specific ship (CvRandomEventInterface.py)
2) Barbarian uprising events can occur only if you can build a counter unit (CvRandomEventInterface.py)
3) "Mother lode" event: yields more gold on average (CIV4EventInfos.xml)
4) Fixed "Impeachment" event (CIV4EventInfos.xml; fix was removing 6 whip anger)

It would be possible to make 3.13 versions of those 2 files but can the installer detect whether a user has 3.13 or 3.17 and install the proper one? It'd suck having to make 2 separate downloads because of those few changes in 2 files.

 

[NikNaks]

I don't see why we should really do that. It does change gameplay, but only for the balanced effect that Firaxis was trying to achieve. #4 sounds like there was a bug in it, anyway.

 

[Caesium]

Why don't you read the BtS-Version from the xml and then trigger with python, which version of event signs has to be used?

The version is found in GlobalDefines.xml

	<Define>
		<DefineName>CIV4_VERSION</DefineName>
		<iDefineIntVal>317</iDefineIntVal>
	</Define>

In 3.13, I think, this will be

	<Define>
		<DefineName>CIV4_VERSION</DefineName>
		<iDefineIntVal>313</iDefineIntVal>
	</Define>

The question is: Does Complete have such an entry too?

 

[EmperorFool]

The version is in the XML? Sheesh, I looked for "3.13" when I checked.

In any case, I've been wanting to add a function to test for specific patch levels a la BugUtil.isNoEspionage(). Seems like a good reason to break that function out into GameUtil and add version checkers: is313(), is317(), getVersion(), etc.

 

[Dresden]

Ah, thanks for reminding me about the XML version string. While the python portion of events could easily use that to run the proper code, the mother lode and impeachment changes are purely XML-based and so I don't know that we could pick and choose which to use at runtime.

 

[EmperorFool]

Forgive me for being dense, but I have no idea what you're saying the problem is.

Here's my guess from the Motherload event given its name: a rival gets the event for their Iron mine, but you haven't researched Iron Working yet. Normally, mousing over the plot tells you that the mine gets +2 (or whatever it gets), but with Event Signs you see it's the Motherload event and know there must be Iron there. Spoiler!

Is this even the problem you're talking about? If so, what does 3.13 versus 3.17 have to do with this? Color me confused.

 

[Dresden]

In order for EventSigns to identify that an event has triggered and changed a plot, it either adds (or changes existing) Python hooks for the various events. So that means I have to replace the game's original EventInfos and RandomEventInterface files with slightly modified versions; the EventInfos has to tell the game about the new hooks and the RandomEventInterface implements them.

The problem is that these modified files are based on 3.17 and both files differ between 3.13 and 3.17. So if someone with a stock 3.13 installation installs BUG, they are getting a couple of the event-related 3.17 fixes/changes even though they didn't install that patch. The Python differences can be worked around using the version define but the XML differences probably cannot and so 2 events will change. The mother lode event on unmodified 3.13 gives 20-40 gold but a 3.13 user with BUG installed gets the 3.17 version with a higher reward (100-200). Similarly they get the fixed version of Impeachment without the unhappiness.

These are quite small changes but since they are actual gameplay alterations I figured we should discuss how to handle them.

 

[EmperorFool]

One option is to do what we did with BAT 1.0--have a separate patch file for 3.17 (or 3.13 in this case) that is run after the initial install. It would be a PITA for us to maintain, but not horrendous.

 

[ruff_hi]

I added an option that allows the user to enable / disable PLE. Check-it and you get PLE, leave it blank and your unit plot is vanilla BtS.

 

[alerum68]

Been a while since we used this thread, but had a question and needed to get input from the group.

I want to divide the Forum. I want to create four new subs, for BAT, BULL, BUFFY and BEaST. I think we should keep BUG questions in the main forum, as it is now. I'm willing to go through the threads to break it out, but not sure to go about how doing it. First, who do we contact for this? Is there any other suggestions? Maybe a sub for merged files, where people can post patches so other Mods work with our Mods? Another private forum just for the group members?

 

[EmperorFool]

I'm afraid most users won't know the difference and will just post in the BUG forum. We definitely need a single forum for Modders and Merges. We are getting a lot of new users from BUFFY--even ones that don't know what HOF and xOTM are I think.

It would be nice to have a private forum as we did with BUFFY, but keep in mind we have the team mailing list too. We could easily create a BUFFY team mailing list.

 

[alerum68]

I still think it would be a good idea, even if only half the people use the sub forums. I'll be honest... I feel the same way about BUFFY as Ruff does about BAT. I have no interest in it, as I never play HoF / GoTM games, so having to read BUFFY stuff for me is a PITA. Anyone else input?

 

[ruff_hi]

I still think it would be a good idea, even if only half the people use the sub forums. I'll be honest... I feel the same way about BUFFY as Ruff does about BAT. I have no interest in it, as I never play HoF / GoTM games, so having to read BUFFY stuff for me is a PITA. Anyone else input?

I have no idea what you are talking about .

Actually, BUFFY is BUG + BULL + HOF stuff

The last part is pretty small and any error that BUFFY throws up, BUG + BULL will probably have too (but I know what you mean about reading stuff that is boring ).

 

[The Doc]

IIRC, we had a short discussion about splitting the forum at the mailing list a while ago. I just searched my inbox for it and here is, what EF came up with in the end:

MAIN

Download / SVN / Version Info
FAQ
Questions

BUGS AND FEATURES

Known Issues*
Bug Reporting
Feature Requests

DEVELOPMENT

Development
Modding / Merging Info


To keep things organized we could let the users use [BUG], [BAT], [BULL] and [BUFFY] in front of their thread titles. That would make immediately clear to what mod they are referring to.

 

[EmperorFool]

Yes, I remember that discussion and feel that layout is still the way to go today. I understand that Alerum doesn't want to read about BUFFY issues and Ruff doesn't want to read about BAT, but now we have this situation:

BUFFY = BUG + BULL + HOF
BAT = BUG + BULL + VD et al​

Many of the BUFFY bugs being posted actually refer to BUG and/or BULL, and a few BAT bugs posted do as well. I would rather scan a single forum, ignoring VD and HOF stuff as I go, rather than scan four forums looking for BUG + BULL stuff.

The idea to use prefixes on thread titles is great, except users won't get it right.

Another option is to use multiple bug reporting stickied threads:

• Graphical Problems
• No Interface Issues
• Other Bugs