Well you would be in trouble if you were actually early in nanotech era, when you would start colonizing moon.
While Pepper module doesn't rely on buildings directly from Moon Colony, Pepper may be relying on resources produced by those buildings in moon colony.
Also there may be units or improvements needed to start up moon colony.
Looks like in Moon Colony there is improvement needed to build moon colony - that is you can build moon colony only on Lunar Base improvement that is defined in Moon Colony.
He swears its better in every way and there's nothing keeping us from its use here soooooo... I guess we'll give it a try unless we find it cannot manage something. I think @alberts2 has been wanting this as well, right Alberts?
Git has been designed to work source code and doesn't play well with binary files. There is the GIT LFS extension for improving that but the git hosting providers don't really offer large enought free storage space for something like C2C.
ALSO: @All: BillW has been setting up a git repository for us all so we'll probably be changing to that soon after release and I've asked him to write a post here on how to go about that for all of us. We will probably be leaving Tortoise behind soon depending on how this goes (which it's not working right for me since work demanded I get Dropbox installed on my computer anyhow - it takes over all the folder icons and Tortoise isn't allowed to use them anymore!!! rrrrrgh) He swears its better in every way and there's nothing keeping us from its use here soooooo... I guess we'll give it a try unless we find it cannot manage something. I think @alberts2 has been wanting this as well, right Alberts?
There should be installation settings in Dropbox from taking over all folder icons.
Or maybe there is some guide on to have Dropbox and Tortoise without conflicts.
Color me impressed but I would insist you playtest it for a while before trying to merge it - there's GOT to be some bugs. I mean you had NO trouble with building limit counts and all that huh? And tags in units and specialunitintos and traits and civics and on and on on that refer to buildingclass? I mean, damn that's a LOT of effort I would've expected would take months.
Damn I hope I didn't say that! It in better is a lot of ways, but still has some draw backs compared to centralized version control systems (e.g. svn, perforce), and I am just experimenting to see IF it can be used!
Git has been designed to work source code and doesn't play well with binary files. There is the GIT LFS extension for improving that but the git hosting providers don't really offer large enought free storage space for something like C2C.
Hosting size limits is certainly a problem. Currently I am seeing what the repo size looks like after I move all the binary stuff into git lfs and cleanup the commit history, then I will know more how feasible it is. Before cleanup the whole SVN history with all versions is 30GB in git!
Damn I hope I didn't say that! It in better is a lot of ways, but still has some draw backs compared to centralized version control systems (e.g. svn, perforce), and I am just experimenting to see IF it can be used!
Hosting size limits is certainly a problem. Currently I am seeing what the repo size looks like after I move all the binary stuff into git lfs and cleanup the commit history, then I will know more how feasible it is. Before cleanup the whole SVN history with all versions is 30GB in git!
Hosting size limits is certainly a problem. Currently I am seeing what the repo size looks like after I move all the binary stuff into git lfs and cleanup the commit history, then I will know more how feasible it is. Before cleanup the whole SVN history with all versions is 30GB in git!
From my on tests i remember. Having the art in huge FPK's is a no go with lose art files the repo size and growth over time will be much lower. The same goes for compiled binarys like dll or pdb.
Thank you for the heads up! Seem like an arbitrary number by your suggestion. I would like to go increments by 1 so we don't need to really keep track of this number and pick at random the next version number to use.
That's right. I didn't review my changes but only fixed typos to get my work to compile. It's hard to come up with a new mechanism to keep the two features I've noted that relied on civilization Unique Building to work working. I switch to do work on the XML manually, and have just processed 100 something classes at this moment.
When I was trying to compile it, there's even a python name clash with CyCity::getBuildingProductionModifier that took me a few tries to really figure out. I had to rename the BuildingClass version of this function to getBuildingProductionModifierRaw and changeBuildingProductionModifierRaw, but I think this is a bad practice. Where can I record the python API for fellow modders?
From my on tests i remember. Having the art in huge FPK's is a no go with lose art files the repo size and growth over time will be much lower. The same goss for compiled binarys like dll or pdb.
Looks like $5 a month for 50GB, if I host the repo I am happy to pay it (I already have github pro as well so unlimited collaborators), but I understand if other people aren't happy about it.
Personally I would go with the other solution you allude to and remove the DLL and FPKs from the repo and instead use automated releases via appveyor, and maybe trim the history as it currently is (just keep the last 6 months or a year of commits from svn), and then I expect it will be a lot more manageable!
/edit My intention was to investigate and work all this stuff out and then present a solution if I get to one, but TB dropped spoilers! Actually my original intention was just to use this for myself locally but it spun out a bit.
Personally I would go with the other solution you allude to and remove the DLL and FPKs from the repo and instead use automated releases via appveyor, and maybe trim the history as it currently is (just keep the last 6 months or a year of commits from svn), and then I expect it will be a lot more manageable!
That would be the way to go and i wouldn't keep the history just start a new repo.
One reason i stopped thinking about moving to git was that nobody here really knows anything about git or things like appveyor.
Another was that having loose art and no compiled dll in the repo would complicate modding as you can't just checkout make changes and commit them. Starting C2C with loose art insted of FPK's takes forever.
Erm, I've always treated the Cy(something)Interface.cpp files as an API documentation when I mod python.
I do check the vanilla API (LINK) sometimes though, as most of the vanilla API is still valid for C2C. The non-sdk stuff is only in the vanilla API.
The content of those Cy____Interface.cpp files are so well structured and easy to read, search and find stuff in that I actually often prefer to look in them.
I agree, it's a nice offer and all, but it creates a precedence of spending money on C2C.
So if billw2015 someday leaves C2C then someone has to take over paying for it or we are forced to return to the SVN, and then I guess we would loose commit history again.
I can't say I feel there is any critical downsides with the SVN really.
Pretty happy with the way things are, and if it ain't broke, why fix it. ^^
Yeah, that is why I say my preference would be to do it the other way. However to be clear I am not pushing for this project to move to git and abandon svn. It is something I am trying firstly for myself, and secondarily anyone who wants to use it. I just noted that a few people expressed interest, and was told that it was looked into before. In the short time I have been reading these forums I also noted a few issues that seemed like they stem directly from svn, including new content going to trunk when a release is trying to be stabilized, concern and discussion about how to do branching, connection problems to hosting, low visibility on other peoples changes. Couple that with the antiquated tooling, and essentially deprecated nature of svn leads me to think it is worth spending some effort in experimenting with what a git solution might look like. If people don't like what it looks like then nothing is lost, but given the longevity of this project, even small gains will add up over time.
ALSO: I was planning to bundle the release of v39 tonight but I was up early and am exhausted now and I don't want to screw anything up so I'm gonna wait til tomorrow and hopefully I'll have some time in the morning with a fresh head.
Yeah, that is why I say my preference would be to do it the other way. However to be clear I am not pushing for this project to move to git and abandon svn. It is something I am trying firstly for myself, and secondarily anyone who wants to use it. I just noted that a few people expressed interest, and was told that it was looked into before. In the short time I have been reading these forums I also noted a few issues that seemed like they stem directly from svn, including new content going to trunk when a release is trying to be stabilized, concern and discussion about how to do branching, connection problems to hosting, low visibility on other peoples changes. Couple that with the antiquated tooling, and essentially deprecated nature of svn leads me to think it is worth spending some effort in experimenting with what a git solution might look like. If people don't like what it looks like then nothing is lost, but given the longevity of this project, even small gains will add up over time.
Alternatives are indeed worth looking into, I'm glad that you are doing so. ^^
Just expressing some healthy skepticism is all.
SpoilerSome thoughts of mine :
I don't think all the issues you list there are as serious as they sound like.
1. Commits coming in during freeze period that should wait due to potential destabilizing content.
It's not hard for other team members to check what was changed and voice concerns if something looks fishy with the commit (not a real bug fix, or faulty logic in the changes).
Easy to revert changes of one revision even if there has been newer revisions since the problematic revision.
I prefer that team members have a high level of freedom and that a good team cohesion is a requirement for it to work, it forces us to discover and work out differences between team members about the lay of the land.
That last one is a bit abstract, I mean, loose rules that can be bent is in many cases better than enforced rules that are completely rigid. (don't know if this point is relevant for git vs SVN though)
2. Technical concerns about advanced SVN functions like branching in a group consisting of laymen of every kind.
I'm pretty sure similar technical discussions and conserns would arise in the git environment as well, perhaps more so?
I dunno, seems to me that tortoise is a pretty straight forward tool is all, quite accessible imo.
Spoilere.g. :
I was contacted on PM from one who claimed to be a "computer illiterate", he/she had some pretty clueless questions that indicated that it was indeed the case.
He/She had problem getting the latest release to work at all.
I told this person that I really recommended the development build of C2C at this point as the latest release was so old.
After instructing him/her on whether to download 32 or 64 bit tortoise I said this.
After Tortoise SVN is successfully installed, (you may need to restart your computer at this point) -
-navigate to this folder: Steam\steamapps\common\Sid Meier's Civilization IV Beyond the Sword\Beyond the Sword\Mods\
Create an empty folder there called Caveman2Cosmos
Right click that empty folder and you should see something like SVN Checkout in the context menu. Click that.
When it asks you for the repository URL enter 'svn://svn.code.sf.net/p/caveman2cosmos/code/trunk'
That was all I had to say, he/she got it working right away and was amazed at how easy it was.
3. Connection problems happens sometimes, sure, though I don't see it as a very bad thing with a little delay now and again. A minor issue imo, something to expect from a free platform.
The modding hobby can be an obsessive monster sometimes, may be healthy to be forced to slow down a bit on that front once in a while. ^^
One can always keep modding without making commits too if there's nothing else one would rather do.
4. Low visibility on other peoples changes....
I'm not sure how it could be much more visible, each revision state exactly which files that were changed, and it's easy to compare the exact changes within each file. Most modders are diligent at adding a describing comment to each revision about the goal of the revision changes too.
5. Old and antiquated is imo not really a big problem if it works. Tortoise does have regular updates, but you were probably referring to something else I guess, like the underlying repository platform.
Yeah, that is why I say my preference would be to do it the other way. However to be clear I am not pushing for this project to move to git and abandon svn. It is something I am trying firstly for myself, and secondarily anyone who wants to use it. I just noted that a few people expressed interest, and was told that it was looked into before. In the short time I have been reading these forums I also noted a few issues that seemed like they stem directly from svn, including new content going to trunk when a release is trying to be stabilized, concern and discussion about how to do branching, connection problems to hosting, low visibility on other peoples changes. Couple that with the antiquated tooling, and essentially deprecated nature of svn leads me to think it is worth spending some effort in experimenting with what a git solution might look like. If people don't like what it looks like then nothing is lost, but given the longevity of this project, even small gains will add up over time.
C2C would benefit but going from svn to git is just not as simple as it seems first. Small CivIV mods have done it already but once again the size of C2C is a problem. It would be necessary to find solutions for the issues i posted before.
Even a svn repo would benefit from using loose art files insted of packend fpk's. But starting the game with that manny loose art files is just too slow. It would be necessary to manually create a fpk and make the loose files hidden to be able to start the game. It would be possible to create a programm that takes care of that.
The same goes for the dll.
I have already created a small took for xml validation and formating. This could be extended to create a c2c_temp.fpk and hide the loose files...........
Thanks, and yeah skepticism is certainly warranted. I won't address the issues you replied to unless you specifically want to hear my thoughts on them, because probably I would be telling you things you already know and have considered.
Even a svn repo would benefit from using loose art files insted of packend fpk's. But starting the game with that manny loose art files is just too slow. It would be necessary to manually create a fpk and make the loose files hidden to be able to start the game. It would be possible to create a programm that takes care of that.
The same goes for the dll.
Yeah I was discussing this on discord just now. PakBuild has a CLI, and it can automatically make split files based on size. My intent is to put pakbuild.exe into the git repo (its small), uncompress the fpks into a single art folder, then write a script that paks them back up into fpks like c2c1.fpk, c2c2.fpk etc. This should make artist workflow easier I think.
For the DLL, for now I am just going to put it in git as it is. Both the DLL and PDB are well below 100MB file size limit, and the repo size limit as discussed is 100GB.
In the long term I would package the dev environment, write a script that will fetch and install it, and one that will build (and optionally deploy) the DLL. It can also be responsible for locating your mod folder etc. I want this anyway just to reduce friction for anyone who wants to contribute on the code side.
This can of course also run on appveyor when master branch changes (hopefully only via PRs), and then create a release containing the DLL, and/or the PKGs. And in that case some people could just run a script that downloads that instead.
Not sure what the implications of all this is until I try it out, but I think it makes workflows nicer in a few cases. e.g. modifying art just means changing the files in the art folder and running the build script again, testing in game is potentially easier as the build script can deploy straight to the game folder.
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.
