Help improve the expansion pack!

I don't know what editor MinGW is set up to use by default. You can try typing "echo $EDITOR" at the console. I use Cygwin which uses vi by default, and to exit from that is "ESC : w q". You might be using pico or nano which is "CTRL+X Y <enter>" IIRC. I found instructions on setting up your own editor such as Notepad++.

When you say "remove the password" do you mean from your account? All free repositories are public and don't require a password to read from, but only you can commit to it.

This question asks about defaulting to a different directory, and the first answer has several options. Easiest is to add "cd <path>" to the end of your ~/.bashrc file (~ is your home directory which is where you should start normally).

Remember, it's never too late to rename all those directories and files to remove the spaces. :D
 
#5 worked to change starting directory, thanks!

Ctrl and escape didn't work in the editor, but I managed to commit with -m. Is the repository accessible to you now?

Adding ""s to deal with spaces are a small sacrifice there, but a big help for readability in the normal IDE. :)
 
You need to push your changes after committing. Git is different from other systems in that you have a fully-functional repository in that folder. It contains all history and allows branching and committing without involving a server. You fetch from and push to Github to synchronize your local repository with the one there.

In that main folder use "git push" to push up your changes and "git fetch" to bring changes down (won't be any unless someone else commits to it and pushes their changes). When you do these operations you'll see messages about how many changed objects it packs up and sends/receives.
 
What needs fixing? (screenshot)

The online git tutorial really didn't have enough information about committing changes... the most important part! :lol:
 

Attachments

  • Git Commit.PNG
    Git Commit.PNG
    39.5 KB · Views: 138
Oops, use "git push origin master". Here "origin" is the default name of the remote repository and "master" is the default branch. If that doesn't work, enter "git remote -v" and "git branch -a" and show the output. I highly recommend reading Pro Git. It has a section on dealing with remote repositories.
 
Congrats! I forked the project (so I can commit to my own version and send you pull requests) and checked it out locally. All is well. I'll take the patches I submitted before and put them through as pull requests so you can see how that works. It's a lot easier than dealing with patch files. :)

BTW, is this what you get on your end? The "$" denotes where I'm typing a command at the shell prompt which usually ends in "$". Don't type the "$" itself. This command tells you how much each directory/file takes up on disk.

Code:
$ du -hs .git *

73M     .git
124M    CiVUP and VEM
4.0K    CiVUP and VEM.civ5sln
100M    Textures

The .git folder contains all the history and metadata, so that's not a concern. The final installed mod is 6.5M for me. Where does the other 217.5M come from? I tried to dig into the other folders, but the spaces in their names breaks using "*" to glob files.

No worries if this is what belongs in the project such as ModBoddy files and such, but if any of those files are temporary files--such as a packaged ZIP or other things--it's best to leave them out of the project. You can add file paths to a ".gitignore" text file.

For example, things like CivDdsUnpacker.exe and Textures.7z should probably be omitted since you can download the exe elsewhere and the files in the archive are already expanded in the same folder. If there are a lot of large files like this that you can remove, you may want to delete and recreate the repository (I know, that blows) because once those files are in the history, they will always be downloaded. Every git repo--remote or local--contains the entire history and current state of affairs. If you won't save much space, I'd just delete the files and live with the bloated history. It's up to you. :)
 
Check the vem/leaders folder and you'll see the problem.

Sometimes modbuddy creates these bizzare recursive folder chains which stretch on until the path gets too long and breaks the operating system. The leader folder's real contents are 5mb, but become 90mb. This accounts for 70% of the upload. It's unpredictable when or where this problem will occur. Unless if you can think of a good regex to catch things like this, we'll just have to be very careful when committing files. Unfortunately I forgot to check before doing this first commit. :think:

Most of the rest of the archive is images which will rarely (if ever) change.

I've deleted the bugged repository and am uploading a new one to Thalassicus/civup-vem. Removing the bugged folder chain and textures.7z dropped the repository size about 50%.
 
Once you've got the correct structure, you'll specifically add new files to git before committing them, so even if ModBuddy creates a bunch of crap, it'll be obvious and you just avoid adding them. I would be .gitignore allows standard glob patterns (? and *), but I'll look to see if it allows regex.
 
I found another broken directory chain and deleted it. The civup-vem folder is now 7M - those two bugs comprised 94.3% of the total size. :lol: I checked the textures folder, but it looks like there's not much I can remove from there. Most of the space is taken up with the expensive photoshop files.

I deleted and re-uploaded the repository again.
 
Nice. That just seems to be one of the things you end up doing when you learn to use a version control system, and git in particular as I've found with my projects.

In Subversion you can branch but it's very expensive and takes time, so I usually avoided it unless it was a major, ongoing change. With git they are super cheap. However, you must take care if you branch a lot to create the branch from the right part. I kept branching from other branches and then scratching my head as to why branch B had all the unfinished changes from branch A. I've deleted and recreated many a repo/branch over the past year due to this. :lol:

If you are interested in the technical aspects of git, I highly suggest visiting gitguys.com. Their tutorial on the index (staging area I mentioned) and how all the files are organized is very good with helpful diagrams to clear things up.
 
I was thinking about making a list of thing G&K which could require some changes when it is released. It would help to adapt the project quickly to G&K when it is released. What do u think about it ? :)
Here is a small list :-
Change Huns UUs. Change the name of Horse archer to Tarkan maybe & Rams should be replacing catapults with higher strength & melee attack.
- Changing names of Great War era units (except landships) to something less ridiculus.
- Some changes to Bazar or Dutch UA as they are overlapping quite much.
- Balancing beliefs.
 
I was thinking about making a list of thing G&K which could require some changes when it is released. It would help to adapt the project quickly to G&K when it is released. What do u think about it ? :)
Here is a small list :-
Change Huns UUs. Change the name of Horse archer to Tarkan maybe & Rams should be replacing catapults with higher strength & melee attack.
- Changing names of Great War era units (except landships) to something less ridiculus.
- Some changes to Bazar or Dutch UA as they are overlapping quite much.
- Balancing beliefs.

Thal is part of the Frankenstein test group, and has mentioned that he already has plans for a VEM/G&K. However, I vote for waiting until the expansion is released and we all get a chance to play it before agreeing to drastic changes like the Huns' UUs. I agree about the Great War units' names, and have no problem making cosmetic decisions like that, but who's to say Firaxis won't be changing the belief benefits, names or details about the new civs in the coming months? I think much of the major mechanics are probably set firmly in stone at this point, but the details are probably going to be tweaked right up until launch (hopefully from Thal's and other's feedback).
 
I vote for waiting until the expansion is released and we all get a chance to play it before agreeing to drastic changes like the Huns' UUs.

I agree about the Great War units' names, and have no problem making cosmetic decisions like that.

Definitely agree on waiting on gameplay changes. Are there other suboptimal Great War names besides Landships? The problem with changing that one, of course, is that this is what they were called.
 
I agree. While there are already decisions Firaxis has made that I am skeptical of, and some that I simply find backwards, I would give them the benefit of the doubt until at the very least the game is released, and even then, I am sure that many regulars on this forum (despite, like me, being dependant on Thal's mod for the perfect Civ experience ;)) will want to play it unmodded for a week or two.
 
@Txuce - I think he was suggesting leaving the Landship's name and renaming the units that are simply called "Geat War X" which are, well, uninspired to say the least.

@albie - With every major patch I've made a point of playing a game or two of vanilla to try to understand the rationale behind the changes - some of which I've argued in favor of for inclusion in VEM when noone else did! MadDjinn and others' LPs on YouTube are also a fast and easy (and often entertaining) way to get the "feel" of vanilla and it's strategies (some of which I've applied successfully in VEM) if you don't care to play a game yourself.
 
@albie - With every major patch I've made a point of playing a game or two of vanilla to try to understand the rationale behind the changes - some of which I've argued in favor of for inclusion in VEM when noone else did! MadDjinn and others' LPs on YouTube are also a fast and easy (and often entertaining) way to get the "feel" of vanilla and it's strategies (some of which I've applied successfully in VEM) if you don't care to play a game yourself.

I actually also do this to get a feel for vanilla's changes as well. I haven't played a vanilla game for probably six months though.
 
When a civilization dies, set all CS influence to 0.

Code:
function ResetCsFriendships(iPlayer)
  for iCs = GameDefines.MAX_MAJOR_CIVS, GameDefines.MAX_CIV_PLAYERS-1, 1 do
    local pCs = Players[iCs]

    if (pCs:IsEverAlive()) then
      pCs:ChangeMinorCivFriendshipWithMajor(iPlayer, -1 * pCs:GetMinorCivFriendshipWithMajor(iPlayer))
    end
  end
end


-- The player may have opted for "complete kills"
function OnUnitKilledInCombat(iPlayer, iKilledPlayer)
  if (not Players[iKilledPlayer]:IsAlive()) then
    ResetCsFriendships(iKilledPlayer)
  end
end
GameEvents.UnitKilledInCombat.Add(OnUnitKilledInCombat) 

function OnCityCaptureComplete(iOldOwner, bIsCapital, iX, iY, iNewOwner)
  if (not Players[iOldOwner]:IsAlive()) then
    ResetCsFriendships(iOldOwner)
  end
end
GameEvents.CityCaptureComplete.Add(OnCityCaptureComplete)
 
Back
Top Bottom