Development Thread

EmperorFool said:

The zoom city buttons were hidden when the specialists were showing by design, probably because of the way the button was attached to the table. Since i fixed that I tried now with the zoom buttons showing -- works fine.

Click to expand...

The same for me

EmperorFool said:

I also added buttons to toggle whether the page should show the specialists/gp/culture. Since I couldn't think of a button to use for the specialists, the figurehead is used for both GP legend and specialists. They don't show the current state, so they are a little confusing. If someone can think of some DDS files that could be used (or make some), I'll swap them out for the highlighting buttons like the "customize mode" toggle button.

Click to expand...

Good idea
I think that a unique button can be enough: if someone want to visualize the bottom bar with the specialists and GP levels, I don't think he can have any reason to want to hide the culture levels, and vice versa. The good thing is to have a button to choose if visualize that bar ("loosing" some rows of cities) or not.
So, my opinion is that you can merge the two buttons in one and use for them the highlighting "customize mode" toggle button, placing it a bit upper than now, near the upper line of buttons (but a bit far from them on the left, as the two buttons are now).

EmperorFool said:

@Cammagno - Could you please commit your CDA.txt file to the repo at the same level as the INI? I think that's where we eventually want it to live, right? I'll work on fixing the location code soon (maybe tonight).

Click to expand...

Done.

I took your advice and replaced the two "text" buttons with a single "checkbox" button (like the customizing button with a yellow outline when on). I used the standard citizen graphic, and it sits next to the "rename" button.

I also fixed the customizing button so it shows the full graphic.

And finally, the file is now loaded/saved from/to "My Games\Beyond the Sword\CustomDomAdv\CustomDomAdv.txt". I put the directory in there in case we create multiple pagesets and provide a way to switch from within the options screen. It's not worth it yet since we'll ship with just one version, but maybe if others create pagesets.

Have I missed any other crucial features for this screen? If not, I'm going to see about cleaning up the other minor things so we can release this bad boy.

EmperorFool said:

I took your advice and replaced the two "text" buttons with a single "checkbox" button (like the customizing button with a yellow outline when on). I used the standard citizen graphic, and it sits next to the "rename" button.

I also fixed the customizing button so it shows the full graphic.

And finally, the file is now loaded/saved from/to "My Games\Beyond the Sword\CustomDomAdv\CustomDomAdv.txt". I put the directory in there in case we create multiple pagesets and provide a way to switch from within the options screen. It's not worth it yet since we'll ship with just one version, but maybe if others create pagesets.

Have I missed any other crucial features for this screen? If not, I'm going to see about cleaning up the other minor things so we can release this bad boy.

Click to expand...

I think you have done everything, many many thanks!

@ BUG Team
Till now, the FBUG Mod folder in the SF repo has only the flavor files, not the BUG files.
It is better for working on them, but it is worse for creating the release packs and for users who download FBUG directly from SVN repo (they have also to download BUG files and put them inside BtS folder).
On the other side, we release FBUG packs with the BUG files included.
Besides, some of the FBUG docs refer only to the flavor mods, other refer to the whole FBUG mod (which include BUG files), making things even more confusing.

So, IMO we have two options:

- release and consider FBUG as an addition of BUG, so without BUG files (and fixing all FBUG docs to refer only to flavor mods and files), and say clearly that BUG mod is also needed.
Better for us (not for making release packs, though), worse for users

- release and consider FBUG as the bigger brother of BUG, so with BUG files included into it (and fixing all FBUG docs to refer to all the flavor and BUG mods and files); in this case, I think that we have to copy all the BUG files in the repo inside the FBUG folder, and keep it updated (maybe not each time we update a file in the BUG folder, but somebody need to update daily the FBUG folder with the new file committed to the BUG folder... if nobody else, I can do it).
Worse for us (but easier to make release packs), better for users

Now that we are near the first official release, I think that we have to choose one of these 2 options (the hybrid solution we are using now is too confusing, IMO), what do you think about it?

I haven't inspected FBUG at all yet (busy busy), but my assumption is that they have no files in common. Specifically, you can install BUG and then FBUG or FBUG and then BUG and it won't make any difference -- you end up with the same files. Is this correct?

In any case, we should not try to duplicate files and keep things in sync. That way madness lies. Rather I would say anyone that wants to access SVN directly is going to be knowledgeable enough to understand that they must install both separately, one over the other. It's a PITA to stay current, but that's the price for bleeding edge greatness.

When we make a release (which should be infrequently, 1.0, then 1.01 and 1.02 for fixes, but then at least several weeks/months before 2.0, etc.) we can package BUG with FBUG. The releases are geared to normal users that need a little more hand-holding.

There's another thread that states that the installer deletes CustomAssets before installing. Is this how it works? If so, why? Why not just have it install over the existing directory, overwriting any files in common but otherwise leaving existing files in tact? This would make installing FBUG a process of 1) install BUG, 2) install FBUG on top. Wouldn't that work, or am I not grasping something here?

My main hesitation with doing manual copies on our end every day or so is not just that it's more work. The problem is that frequent manual processes are fraught with errors. It's not a fun process, and it'll be less fun when things go awry. One maxim we use to maintain a happy repo is to never ever put any generated (output) files into the repo. Don't package a release and put it in the repo. Don't put compiled binaries in the repo. Etc.

Well, copying files from one repo to another is the same thing, and it's bound to go bad at some point. That's my take after quite a few years of experience.

Having said that, this is a team effort and a learning experience for everyone. I'm totally open to trying anything new as that's how we learn the things that we think we know are actually totally bogus. Besides, I haven't lifted a finger for FBUG so it's really up to everyone else.

EmperorFool said:

I haven't inspected FBUG at all yet (busy busy), but my assumption is that they have no files in common. Specifically, you can install BUG and then FBUG or FBUG and then BUG and it won't make any difference -- you end up with the same files. Is this correct?

Click to expand...

Correct. This is why my choice would be to keep them separated.

EmperorFool said:

In any case, we should not try to duplicate files and keep things in sync. That way madness lies. Rather I would say anyone that wants to access SVN directly is going to be knowledgeable enough to understand that they must install both separately, one over the other. It's a PITA to stay current, but that's the price for bleeding edge greatness.

Click to expand...

I fully agree with you, but we have to say (in the readmes and in the main page) that they are 2 different mods, and that you have to download and install both of them if you want everything.
Now the things are confusing, because in different places we say and different things, and now FBUG is spoken about as two different things (the mod with the flavor files and the mod with both the flavor files and the BUG files). -this is the reason for which I asked what we wnat to do.

EmperorFool said:

When we make a release (which should be infrequently, 1.0, then 1.01 and 1.02 for fixes, but then at least several weeks/months before 2.0, etc.) we can package BUG with FBUG. The releases are geared to normal users that need a little more hand-holding.

Click to expand...

Here I don't agree. Or maybe yes, but we must be clear about this.
IMHO, we have to release a Bug Mod Setup and a FBUG Mod Setup *without* BUG files. -Even because somebody may like flavor files but not BUG ones. In addition (but only in addition) we may release a BUG+FBUG Mod setup, with both groups of files. But the Docs file will be made for the 2 mods independently. At least, this is my opinion about this.
[note for Alerum... due to the big size and complexity of FBUG, I agree to have only exe versions, they maske things easier for user].

EmperorFool said:

There's another thread that states that the installer deletes CustomAssets before installing. Is this how it works? If so, why? Why not just have it install over the existing directory, overwriting any files in common but otherwise leaving existing files in tact? This would make installing FBUG a process of 1) install BUG, 2) install FBUG on top. Wouldn't that work, or am I not grasping something here?

Click to expand...

The same question from me... Alerum, may you explain again this thing?

EmperorFool said:

My main hesitation with doing manual copies on our end every day or so is not just that it's more work. The problem is that frequent manual processes are fraught with errors. It's not a fun process, and it'll be less fun when things go awry. One maxim we use to maintain a happy repo is to never ever put any generated (output) files into the repo. Don't package a release and put it in the repo. Don't put compiled binaries in the repo. Etc.
Well, copying files from one repo to another is the same thing, and it's bound to go bad at some point. That's my take after quite a few years of experience.

Having said that, this is a team effort and a learning experience for everyone. I'm totally open to trying anything new as that's how we learn the things that we think we know are actually totally bogus. Besides, I haven't lifted a finger for FBUG so it's really up to everyone else.

Click to expand...

I want to make clear that I only reported the 2 options, but I didn't intended to suggest the second, I'm strongly in favor of the first one.
But in that case, I'm also strongly for keeping the two mods divided in the docs and in the releases (even if, as I said, we can release a BUG+FBUG pack, made simply putting files together... but I don't think it's so useful).

I think we take a leaf out of Firaxis's book. That way, BUG is the main mod (similar to Civ4) and FBUG is an expansion pack mod (similar to Warlords or BtS). You need to install BUG and then FBUG if you want the expansion pack mod.

ruff_hi said:

I think we take a leaf out of Firaxis's book. That way, BUG is the main mod (similar to Civ4) and FBUG is an expansion pack mod (similar to Warlords or BtS). You need to install BUG and then FBUG if you want the expansion pack mod.

Click to expand...

Yes, this is the general idea
So, if everybody agrees, this evening I'll update the docs accordingly.

Sorry I didn't have time to read everyone's reply but what I've been doing is leaving the 2 seperate, and including BUG with FBUG in the install.... we don't want to do this anymore?

Also we're getting alot of people having to go to SVN, which tells me we REALLY need to put out 1.0, or at least 0.17. Are we ready for 1.0?

I was searching for a way to "share" the files in SVN, like it's possible with Visual Source Safe (VSS). I found something here about using svn:externals in the properties of the project (search the page for "share"). The only problem is that you can do it only within directories, not files. For the majority of the cases it could be used. Say, /Flavor Mod/CustomAssets/Python points to /Bug Mod/CustomAssets/Python. When you commit bug, you would commit FBug too. There are some cases, like the /CustomAssets/Art/Interface or the /CustomAssets/Xml/Art that wouldn't work like this.

It's just another idea. I do think the better way is to use FBug as an expansion of BUG.

alerum68 said:

Sorry I didn't have time to read everyone's reply but what I've been doing is leaving the 2 seperate, and including BUG with FBUG in the install.... we don't want to do this anymore?

Click to expand...

It is good to keep BUG and FBUG separate, but this should be done even in the docs (now, FBUG is not considered to be an addition to BUG, but as if it a mod with both flavor and BUG files) and in the released setup files (which should be 2, one for BUG and another for FBUG with only flavor files).
So, the setup process for the user that wants both will be:
1) install BUG Mod
2) install FBUG Mod (over BUG)

alerum68 said:

Also we're getting alot of people having to go to SVN, which tells me we REALLY need to put out 1.0, or at least 0.17. Are we ready for 1.0?

Click to expand...

I think that in one (max 2) days we'll be ready.

Given the responses, my gut reaction is to choose a new name for FBUG that doesn't have BUG in the title. These are two separate mods as I understand it. Much of the confusion is that FBUG implies BUG + F, and I'd assume that it includes the BUG mod already in the install.

Regardless, I'm on board with complete separate of documentation and files. I just think a new name will make it totally clear for everyone. Plus it gives us another chance to be creative.

I plan on making up the Screen Shots in the new couple of days. Which features should I get some screenshots of, and should I do it with BlueMarble uninstalled to show just BUG

@EF

What about the credits page in our option screen?
I think a normal one could be enugh, no real need for interactivity there.

I think without BM so the user is clear what exactly BUG provides. BM looks nicer, but I don't want anyone being disappointed when they don't see BM after installing BUG. That and all the posts asking why it looks different.

Major things to hit for me would include

• Main Screen (2 versions with different settings on each one for variety).
• City Screen
• CDA (maybe 1 page and then the customizing view)
• Sevopedia? A couple shots there? Ours isn't any difference from Sevo's, so maybe just include his shots.
• Tech Chooser (I'm biased of course ), make sure to select a couple techs to research so the tech prefs are different.
• Each of the options screen.

The option screen shots will be key to hammering home the point that everything is customizable.

In one of the main screen shots, maybe enable the Ctrl-Alt-O reminder and capture the flashing message, again to push the customizability of our killer mod.

@Cammagno - Yes, list item 362 I think. I'm focusing on nailing down those loose stragglers now -- I've put Whip Assist on the back burner, fun as it is -- and will keep tackling these tasks until we release. 3.13 should be this week, right? If so, then maybe this weekend, next weekend at the latest.

EmperorFool said:

In one of the main screen shots, maybe enable the Ctrl-Alt-O reminder and capture the flashing message, again to push the customizability of our killer mod.

Click to expand...

In the second, you may select a renamed unit

If you hover over a stack of renamed units using various naming schemes, will the screenshot capture the hover text?

EmperorFool said:

If you hover over a stack of renamed units using various naming schemes, will the screenshot capture the hover text?

Click to expand...

Yes it will. That is a good idea.

I think we're going to have to delay releasing FBUG 1.0 for a while. There are alot of fixes to make to missing units, and unless all of us who know XML work on it, I don't seeing being able to finish before the end of next week. I'll install the latest update from the EDU thread, but I still think we have a number of units that are going to be blank. I haven't taken a look at the VD mod pack completely, but I think merging that will install several of the missing units. Will take a look at that as well. Nik, if you get a chance today can you take a look at the VD thread and make sure it fits BUG requirments?

Anyway, I'll do what I can to get the flavor version out tomorrow.

alerum68 said:

I think we're going to have to delay releasing FBUG 1.0 for a while.

Click to expand...

I think that if needed (and wanted) we can release BUG this w/e and FBUG next w/e (together with BUG 1.1, fixed for BtS 3.13).
Or we can wait and release them together next w/e.

I think the first solution may be better, it's a lot from when we released 0.16, and a lot of work has been done in this time.