IMPORTANT: Major SVN Update

EmperorFool

EmperorFool

Deity
Joined
Mar 2, 2007
Messages
9,637
Location
Mountain View, California
For any users that get the latest version of BUG from our SourceForge.net Subversion code repository, I've just committed a major update this morning. The only difference you'll notice as a user is that all of your settings will be reset to defaults. :(

I apologize that it needs to be done this way, but I've rebuilt how BUG stores settings (split into multiple INI files, but stored in the same location). I can promise that this will be a one-time occurrence, and that there's a good reason. The new method will make merging other mods into BUG (and vice versa) much easier.

Note that the "Adv Unit Naming.ini" file (the largest one) is unaffected by this, so you won't lose your advanced naming templates. Also, your original BUG Mod.ini file is not touched, so feel free to pull values from it if necessary.

The new code doesn't store values that aren't different from the defaults, so after you run BUG the first time after updating, it will create empty INI files. You won't see any values until you start changing settings.
 
deleting all older files in your main directory and then "SVN update" works.
 
ricardojahns said:
gives an error. "operation failed".
Click to expand...

When doing SVN Update? I notice that yesterday and still today I'm having spotty internet trouble with SF.net, the forums, and gmail. I assume it's Comcast, but you're not around here, so I dunno.

You could try a fresh checkout. Maybe your svn directories got borked.
 
@EF:

The glorious chance for me to do a fresh checkout and install BUG from scratch :) . Wanted to do that for ages. Everything worked fine :D . One bug I've spotted: In ruff's reworked victory screen the leader name is not resolved at the poll stats, instead the string placeholder %s1 is shown (members page).

Imhotep
 
OK.
Until you released your new code, it has been quite simple to merge bug with other mods.
But with the new core there should be a how to, because you changed so many things, and the main thing is how to use it parallel to other modcomps. That is extremely confusing, because in my case before BUG I used an customized CvCustomEventManager, in which i merged BUG and it worked. And now I'm likely to stay with 3.0. And the very best of all, even merged into a mod's folder it stores the inis to MyGames instead of the mod's folder, or even better, a subfolder.

Could you please provide the name of the files and the part of code, that has to be changed for using the "old" customeventmanager and for changing the path, where the inis are stored at?
 
I will be writing such a HOWTO soon, but here are the basics on how to merge a mod with BUG.

1. Pick a unique valid Python identifier (starts with a letter, only letters, numbers and underscore) for your mod. Do not put two consecutive underscores in it ("__").

2. Create a config XML file in Assets/Config with whatever valid file name you want, e.g. "My Really Cool Mod.xml". It doesn't have to match the ID from (1).

Here's an example template based on the Reminder mod as it's fairly typical as far as modcomps go. It assumes that you have a single INI file for your modcomp with a single "Enabled" option.

Code: 
<?xml version="1.0" encoding="ISO-8859-1" ?>
<mod id="[B]<mod-ID>[/B]">
	 
	<options id="[B]<mod-ID>[/B]" file="[B]<ini-file-name>[/B]">
		<section id="[B]<section>[/B]">
			<option id="Enabled" type="boolean" default="True"/>
		</section>
	</options>
	
	<events module="[B]<your-event-manager-module>[/B]"/>

</mod>

This setup will work with an event manager that uses Dr. Elmer Jiggle's CvCustomEventManager class. You don't have to modify the central event manager to add your manager anymore. The above expects you to have a class named the same as your module (add a class="<class>" attribute to the <events> tag if not) whose __init__() method takes an eventManager as its only non-self argument.

Code: 
## YourEventManager.py

... imports ...
... globals ...

class YourEventManager:
    def __init__(self, eventManager):
        eventManager.addEventHandler("kbdEvent", self.onKbdEvent)
        ...

3. Add your config file to Assets/Config/init.xml:

Code: 
<!-- Mods -->

<load mod="BUG Main Interface"/>
...
<load mod="Unit Naming"/>

[B]<load mod="<mod-name>"/>[/B]

The mod attribute is used to locate your xml file by adding ".xml" to it.

4. Access your options from your modules.

  • Import BugCore
  • Get a handle to your mod configuration
  • Check an option value
Code: 
## YourMod.py

import BugCore    # A

YourModOpt = BugCore.game.YourModID    # B
...
if YourModOpt.Enabled():    # C
    ...

That's it in a nutshell. Please ask questions where things aren't clear as it will help when I write the HOWTO. Thanks for being a guinea pig. :D

BTW, The location where INI files are stored and read hasn't changed. It looks in the same locations as before for a folder named CvModName.modName.
 
·Imhotep·;7183703 said:
The glorious chance for me to do a fresh checkout and install BUG from scratch :) .
Click to expand...

The latest SVN version now creates INI files using the hover help text and default values for any INI file that doesn't exist when you start up a game. I'll soon add the ability to reset to defaults any individual tab or all options, but for now you can just remove the INI file you want reset.

WARNING: Adv Unit Naming.ini does not get rebuilt in this way because it's abnormal. It's default state will continue to live in SVN should you accidentally torch your copy. :mischief:
 
ad 1: The valid Python identifier is the name of the file? Or do you speak of something else?
ad 4: This isn't really required? I'd still could use my old way, or will I have to use this way from now? (thinking of tons of code to rewrite ;) )

EmperorFool said:
Thanks for being a guinea pig. :D
Click to expand...
That's one of my #1 hobbies :D

I'm testing it in a mod's folder, and it sores at MyGames. Is there a code that can be commented out or that can be exactly defined for just one specific folder?

Apologizing for driving you nuts.:blush:
 
Caesium said:
ad 1: The valid Python identifier is the name of the file? Or do you speak of something else?
Click to expand...

No, the ID you choose must be inside the config xml file:

Code: 
<mod id="<mod-ID>">

The name of the file must match the line in init.xml that you use to load it. For example,

ID: RCM
Name: Really Cool Mod

Really Cool Mod.xml:

Code: 
<mod id="[B]RCM[/B]">

init.xml:

Code: 
<load mod="[B]Really Cool Mod[/B]">

The ID (RCM) will be used to get your mod config from within Python:

Code: 
import BugCore

if BugCore.game.RCM.Enabled():
   ...

This last piece is the reason for an ID that must be a valid Python identifier. If you choose a mod name that is a valid identifier, you can use it for the ID. The Reminder mod uses "Reminder" as its name and ID.

Caesium said:
ad 4: This isn't really required? I'd still could use my old way, or will I have to use this way from now?
Click to expand...

I'm not sure I understand. Did you create options that got stored in "BUG Mod.ini" already? Did you use BugOptions.getOptions() to access its options? If so, converting to this way should be fairly easy. If instead you load your INI using some other non-BUG code, feel free to continue doing it that way. In that case your config xml file will just tell BUG about your event manager.

Is that what you meant?

Caesium said:
I'm testing it in a mod's folder, and it sores at MyGames. Is there a code that can be commented out or that can be exactly defined for just one specific folder?
Click to expand...

Let's assume your mod is installed in

My Games/Beyond the Sword/Mods/CaesiumMod/​

and you've changed CvModName.modName to "CaesiumMod". I wrote BUgPath so that you can create a folder in "Mods/CaesiumMod" called "CaesiumMod" (yes, that will look strange) to hold your INI files. However, it probably looks in "My Games" first, so make sure you delete that folder.

If this isn't what's working for you, please explain in detail the directory layout, including the name of the mod, folders, and what you have for CvModName.modName. And are you using BugPath.findIniFile() or something else?

Caesium said:
Apologizing for driving you nuts.:blush:
Click to expand...

No worries. Much of my motivation for rewriting the BUG core was to make it easier for modders to use BUG and write their own mods using it as a base. I know it's a lot to digest, so I greatly appreciate having modders willing to blaze a trail into unknown territory. :D
 
Ah, I think I understood how to add modules or mods.
EmperorFool said:
I'm not sure I understand. Did you create options that got stored in "BUG Mod.ini" already? Did you use BugOptions.getOptions() to access its options? If so, converting to this way should be fairly easy. If instead you load your INI using some other non-BUG code, feel free to continue doing it that way. In that case your config xml file will just tell BUG about your event manager.

Is that what you meant?
Click to expand...
I rewrote my Warlords Mod for BtS and using Jiggles code, I use "my" mod's components parallel to bug's components, which also results in an own ini file. (for example revolution mod)
It's hard for me, to give up the hard learned way ;)

EmperorFool said:
Let's assume your mod is installed in

My Games/Beyond the Sword/Mods/CaesiumMod/​

and you've changed CvModName.modName to "CaesiumMod". I wrote BUgPath so that you can create a folder in "Mods/CaesiumMod" called "CaesiumMod" (yes, that will look strange) to hold your INI files. However, it probably looks in "My Games" first, so make sure you delete that folder.
Click to expand...
That's a good idea, but Civ creates this path when starting.

EmperorFool said:
If this isn't what's working for you, please explain in detail the directory layout, including the name of the mod, folders, and what you have for CvModName.modName. And are you using BugPath.findIniFile() or something else?
Click to expand...
A really detailed layout is the main problem. If I'd only wanted to use the mod on my own I'd have changed it to my path, but I also want to release the mod in future, so the structure to the inis should be something like Mods\Caesium v3.0\ini-Files for example.


EmperorFool said:
No worries. Much of my motivation for rewriting the BUG core was to make it easier for modders to use BUG and write their own mods using it as a base. I know it's a lot to digest, so I greatly appreciate having modders willing to blaze a trail into unknown territory. :D
Click to expand...
:)
 
I still don't understand what exactly is happening. You're saying that Civ creates this folder:

My Games/Caesium​

??

AFAIK, it should only create

My Games/Beyond the Sword​

How are you getting to your INI file? CvPath? BugPath? os.path? I can't figure out what's wrong if I don't know. Feel free to post some code. :)
 
No.
Civ doesn't create any new folders. It creates the bug ini-files in My Documents\My Games\Beyond the Sword instead of D:\Civilization 4\Beyond the Sword\Mods\Caesium v3.0, from where I started the mod, but thats only with the bug's inis, because my "own" ini can't be changed in game. I didn't change the bugs "filestoring"-code.

And the next question is: How to store bug's inis to a subfolder, for example D:\Civilization 4\Beyond the Sword\Mods\Caesium v3.0\ini-Files, and also moving the Adv Unit Naming.ini there.
 
Is that double underspace in the tags of BUGOptions_CIV4GameText.xml intended?

Example:
Old - TXT_KEY_BUG_OPT_ALERT_REMINDERS_TEXT
New - TXT_KEY_BUG_OPT_REMINDER__ENABLED_TEXT

Just curious, because I haven't seen tags with double underspace in the other BUG text-files. :dunno:
 
The Doc said:
Is that double underspace in the tags of BUGOptions_CIV4GameText.xml intended?
Click to expand...

Yes, it is very much intended. Option IDs are now built from their mod ID and option ID. The double underscore is used as a separator and enforces uniqueness should the rare corner case occur where two IDs end up munging to the same value:

1: Mod: XX, Option: YY_ZZ
2. Mod: XX_YY, Option: ZZ

They would both become XX_YY_ZZ and clash without the double-underscore. With it -- and the restriction that __ cannot be used in a mod ID -- they will always be unique.

I wanted to use "." but just didn't get around to doing it. Plus I don't know how Civ will like . in its XML tags, though I seriously doubt there'd be a problem. I could translate . to __ in the tag, but then we'd still have __ so I left it. :)

@Caesium - I'll take a look at what I can do for ya tomorrow. Now I need to get some sleep. If you want to poke around, take a look at BugPath. Note that it builds a set of ini search paths (shown in the options screen's Config tab).

I suspect you can get what you want by creating a folder with the name of your mod inside your mod's folder (e.g. "Mods/BUG Mod/BUG Mod/") as long as CvModName.modName matches this folder. Then remove the one in MG/BTS. I still don't understand how the BUG ini files are showing up in your BTS folder and not inside their own "BUG Mod" folder inside it.

You're running the latest from Subversion, right?
 
Two-and-a-half quick questions:

1) What is "branches\bug-new-core...\", aside from the obvious — is it really buggy/incomplete/for-developers-only, or should we be switching to it if we want to see new BUG features and are alright with the odd hiccup (i.e. typical beta testing stuff)? If it's the latter, then for future reference, can we comfortably use any of the SVN stuff in a beta testing capacity or should we wait until we hear mention of a stable SVN build? (That was the "half," for those keeping count.)

2) What is "Patch 3.17" in the BAT Mod folder? That's been there for awhile, and I've always been copying its contents over the BAT Mod XML. (I've assumed it contains files I should be using under Patch 3.17, but then I wonder why it hasn't been merged with the BAT stuff already — are that many people still running 3.13?)
 
Eunomiac said:
Two-and-a-half quick questions:

1) What is "branches\bug-new-core...\", aside from the obvious — is it really buggy/incomplete/for-developers-only, or should we be switching to it if we want to see new BUG features and are alright with the odd hiccup (i.e. typical beta testing stuff)?
Click to expand...

It was the place in which EF put the new BUG core for developing it and for us to test it, before putting it in the main SVN folder.
So, for what I know, now that folder only contains the same files which are in the main one.
@EF
some reason for keeping it in SVN or can it be deleted?

Eunomiac said:
If it's the latter, then for future reference, can we comfortably use any of the SVN stuff in a beta testing capacity or should we wait until we hear mention of a stable SVN build? (That was the "half," for those keeping count.)
Click to expand...

Well, IMHO you are always allowed to use everything in the SVN repo, but always at your own risk :)
Theorically, only the released versions are "supported" by the BUG Team, even if usually we are happy to answer questions about the SVN versions also. In short: no bug complains about SVN files, they are there to be tested... but on the other side, bug notifications about them are welcame.
Having this in mind, you are free to play with files that you find in the repo, but if yuo find some strange folder of which we have not spoken here, use the files inside with caution :)

Eunomiac said:
2) What is "Patch 3.17" in the BAT Mod folder? That's been there for awhile, and I've always been copying its contents over the BAT Mod XML. (I've assumed it contains files I should be using under Patch 3.17, but then I wonder why it hasn't been merged with the BAT stuff already — are that many people still running 3.13?)
Click to expand...

I think the reason is the one you have guessed, that is to keep BAT 1.0compatible with 3.13. Maybe next released version will be compatible with 3.17 (maybe with a patch for people still using 3.13)
 
Cammagno nailed them all. In the future, I'll start a thread specifically about the branches and their uses for those that are SVN-curious. I mentioned it in passing somewhere (probably the team mailing list tho), but I'll make a thread for it for the next branch.

Yes, all the files are in what's called the trunk (main line of development), and I will delete the branch shortly.
 
Got the saving of the inis to work in a subfolder. Just changed
PHP: 
<options id="Scores" file="Advanced Scoreboard.ini">
to
PHP: 
<options id="Scores" file="ini-Files\Advanced Scoreboard.ini">
and it works with the files in that subfolder (in the other xmls I did the same).

Could you please rewrite the added CvCustomEventManager for the work with BUG?
 

Attachments

You must log in or register to reply here.

Similar threads

C
SVN update issue
2
Replies
21
Views
1K
Santa Klaus
Santa Klaus
W
How to persist values across saves
2 3
Replies
59
Views
2K
DeckerdJames
D
Taefin
Taefin's More AI Cheats
Replies
2
Views
627
Taefin
Taefin
B
Am I the only one disappointed that this "big" patch barely fixed any bugs?
3 4 5
Replies
95
Views
6K
bumpyglint
B
The_J
Old World update #133
Replies
9
Views
998
Dale
Dale
Back
Top Bottom