WildWeazel
Carthago Creanda Est
If they're not issues I think you have to just recreate it. Issues can be added to multiple boards.
Assembling the team
- Thread starter WildWeazel
- Start date
- Joined
- Mar 17, 2007
- Messages
- 9,284
WildWeazel is right; Notes cannot be moved, only Issues. I've been converting non-completed ones to Issues. But since I already brought up MSPaint and added a few arrows, I'll include that screenshot as well:
I just realized that I never responded: 
to both the "team" as well as retaining this as our development forums, as I'm certain that there's plenty of info here that we might wish to refer to.
to both the "team" as well as retaining this as our development forums, as I'm certain that there's plenty of info here that we might wish to refer to.
I still wish that there could be a way to convert ( 
)_ SMAC graphics (and I certainly hope that we wind up with a plethora of SF units.)
Also, another thought: Perhaps we should tackle this effort one era at a time, releasing it to the overall community with some sort of (Era I Ancient?) scenario. An Ancient Era would also provide the least number of challenges, and any ad hoc development efforts could be incorporated into a better, more thoroughly Beta Release Testing in this fashion, as well. (Consider the lengthy, and still ongoing threads, for @AnthonyBoscia and @Civinator's mods.)
)_ SMAC graphics (and I certainly hope that we wind up with a plethora of SF units.)Also, another thought: Perhaps we should tackle this effort one era at a time, releasing it to the overall community with some sort of (Era I Ancient?) scenario. An Ancient Era would also provide the least number of challenges, and any ad hoc development efforts could be incorporated into a better, more thoroughly Beta Release Testing in this fashion, as well. (Consider the lengthy, and still ongoing threads, for @AnthonyBoscia and @Civinator's mods.)
Puppeteer
Emperor
I still wish that there could be a way to convert (
I have SMAC...on CD and GoG. Never looked at its art...just pulled it up...
It's PCX.
And the Godot PCX reader we have can read them. Although I have yet to find any units or terrain; just techs, facilities, projects, "alternative art" (UI splash screens?)... Some .bmps for explosions.Cut scenes are .wve names...never heard of that, but VLC plays them, so an open source thing can read them. I found one FLC so far, "faction.flc", but I don't have a point-and-click way to check it right now.
Audio appears to be .wav and .mp3 .
There are some .cvr files, but I have no idea what those are. AA-ROVER.cvr, for example. Maybe those are a bundled unit format? In SMAC there is no "unit a, unit b, etc.", but a handful of chassies and configurable weapon, armor, power plant, and some other stuff.
Nothing terrain-y jumps out at me so far.
But that is an interesting idea...launch the ship, continue the game on Alpha Centauri!
Edit: A thread that mentions cvr and SMAC, but it sounds like as of 2014 they didn't know how to read it: https://alphacentauri2.info/index.php?topic=6124.30
Edit 2: Oh, the guy did figure out much of it...more info:
https://alphacentauri2.info/index.php?topic=6909.0
https://alphacentauri2.info/index.php?topic=21024.0
.cvr's *are* units, and they are 3d voxel format. Cool.
Edit 3: Oh, VLC plays FLCs, too. I recall now the challenge with PCX and FLC for Godot was that no C# implementation exists because the formats are ancient and C# relatively new, and nobody had made an open source C# reader library available. Oh, right, and that Civ3 FLCs for units are custom. But VLC plays the FLCs in SMAC which are presumably normal single-animation FLCs.
Last edited:
WildWeazel
Carthago Creanda Est
First question: I haven't been following this the last couple of months, as I had lot's of other stuff to do and didn't want to invest time as long as it wasn't clear to me what "the plan" was (exe patching, waiting for getting the original C++ sources from Firaxis, starting from scratch -- and if the last option, then in what language...)
But I just read the last couple posts here, and it looks like alea iacta est? Starting from scratch it is, using C# and Godot! So in that case I can say: reporting to duty!
Just assign me a few not too time-consuming tasks that allow me to get the hang of it. (As I said, I'm no game developer and have no experience with graphics and engines like Godot. But I could do some work on the game engine or the network stuff for multiplayer, etc.)
Second question: yes. Do you need to move/cleanup some posts/threads?
Last edited:
WildWeazel
Carthago Creanda Est
Starting from scratch it is, using C# and Godot! So in that case I can say: reporting to duty!
Then you're not far behind the rest of us. I take it you'd be most interested in the pure C# game logic? We haven't really gotten into multiplayer considerations yet, but we should. Quintillus made a thread with some suggested tasks for new developers, and there may be some unassigned tasks on the repo board. And like most projects, we need documentation and test code.
I was just going to ask if you could sticky the 3 new threads I created: Getting Started, Feature Requests, and Troubleshooting and Bug Reports
- Joined
- Mar 17, 2007
- Messages
- 9,284
Good news, I see that Lucien (is Lucien on CFC?) has made a PR, with a lot of BIQ sections added! I went ahead and reviewed it; it looks pretty good, I learned a new C# technique, and added some notes mostly around BIQ peculiarities. I should probably also note that sometimes I write comments along the line of "I like how you did that", so X comments from me means X - SomeNumber of things to consider.
It also made me think it's time to touch base on the dev model. In the Alpha milestone, one of the pending review items is Branch Workflow. I think we're doing this pretty consistently now. I know Flintlock has branches, I've been using them, Lucien has a fork with PRs which is equivalent (should Lucien be added to the main repo if that isn't already done?). I think I've seen some Puppeteer branches too? If so, I think we're done with that item.
The other one is if we want any more formality around PRs? I've been opening PRs for my branches, but if no one reviews them after 6-48 hours, doing a self review to see if there's anything in the diff that looks wrong after a break, or which I didn't intend to commit, and merging if it looks good. I'm not sure that the slowdown of a formal, required review process is worth it at this stage (if we grow enough, my thoughts may change). But in this case, I saw a review and since it was a first contribution, and because I probably have the most documentation/in-depth knowledge of the BIQ format, thought it might be worth doing an actual review.
It also made me think it's time to touch base on the dev model. In the Alpha milestone, one of the pending review items is Branch Workflow. I think we're doing this pretty consistently now. I know Flintlock has branches, I've been using them, Lucien has a fork with PRs which is equivalent (should Lucien be added to the main repo if that isn't already done?). I think I've seen some Puppeteer branches too? If so, I think we're done with that item.
The other one is if we want any more formality around PRs? I've been opening PRs for my branches, but if no one reviews them after 6-48 hours, doing a self review to see if there's anything in the diff that looks wrong after a break, or which I didn't intend to commit, and merging if it looks good. I'm not sure that the slowdown of a formal, required review process is worth it at this stage (if we grow enough, my thoughts may change). But in this case, I saw a review and since it was a first contribution, and because I probably have the most documentation/in-depth knowledge of the BIQ format, thought it might be worth doing an actual review.
Puppeteer
Emperor
So far I've just been merging my PRs. I'm not saying that's always going to work well. I'm not sure where to put my foot on the scales here as I can imagine all sorts of issues no matter which way we go.
I've probably had the least group-coding experience of anyone here, and I'm not sure any of us have experience managing a volunteer open-source project like this. The labor is enthusiasm-fueled, so I'm not sure aping a compensated labor model will work well here, but again, way out of my area of experience.
Not an actionable comment, but for what it's worth those are my thoughts.
I've probably had the least group-coding experience of anyone here, and I'm not sure any of us have experience managing a volunteer open-source project like this. The labor is enthusiasm-fueled, so I'm not sure aping a compensated labor model will work well here, but again, way out of my area of experience.
Not an actionable comment, but for what it's worth those are my thoughts.
Ok, guys, let me be honest: I spent a while on the weekend, trying to understand Git and to get the source code on my desktop.
But I failed.
Git and my brain simply seem to be incompatible. clone, pull or fetch?! Commit and push... Why do I need to create a "branch", what is cherry-pick and rebase and all that other stuff. Holy cow, all I want to do is get a source file on my computer, make a change to it and push it back on the server...
I have been working with Perforce for 20+ years, it was easy, self-explanatory and intuitive, and now on my old days I have to put up with some strange, buggy, non-intuitive, over-complicated tool like Git... It maybe hip these days, but I guess I'll never understand why people like it... What has Linus been smoking??
I saw that the Github project has a "Download as zip file" button, but I guess, if I use that, I won't be able to contribute... So please bear with me, it'll be another while before I will be able to join you...
But perhaps you can already answer another question: atm I have VS 2017 at home, is this ok for our project, or should I spend the time and upgrade? (At work we have 2019, and it's a bit better, but not much, but I attended the Microsoft Release Workshop for VS 2022 in November, and was quite impressed... Can't wait until we'll use it at work. However, at home I still have Windows 7 and that's no longer supported by VS 2022...
)
Edit: ok, I finally downloaded the code and opened the C7.sln
# Visual Studio 2012
Really? I hope I don't need to downgrade?!
But I failed.
Git and my brain simply seem to be incompatible. clone, pull or fetch?! Commit and push... Why do I need to create a "branch", what is cherry-pick and rebase and all that other stuff. Holy cow, all I want to do is get a source file on my computer, make a change to it and push it back on the server...
I have been working with Perforce for 20+ years, it was easy, self-explanatory and intuitive, and now on my old days I have to put up with some strange, buggy, non-intuitive, over-complicated tool like Git... It maybe hip these days, but I guess I'll never understand why people like it... What has Linus been smoking??
I saw that the Github project has a "Download as zip file" button, but I guess, if I use that, I won't be able to contribute... So please bear with me, it'll be another while before I will be able to join you...
But perhaps you can already answer another question: atm I have VS 2017 at home, is this ok for our project, or should I spend the time and upgrade? (At work we have 2019, and it's a bit better, but not much, but I attended the Microsoft Release Workshop for VS 2022 in November, and was quite impressed... Can't wait until we'll use it at work. However, at home I still have Windows 7 and that's no longer supported by VS 2022...
)Edit: ok, I finally downloaded the code and opened the C7.sln
# Visual Studio 2012
Really? I hope I don't need to downgrade?!
Last edited:
Ok, here is finally something I know from Perforce...:
Line-endings: Windows-style, Unix-style or "as is", what's the etiquette in your project?
Line-endings: Windows-style, Unix-style or "as is", what's the etiquette in your project?
Puppeteer
Emperor
On that one, Unix-style, but the .gitattributes file has settings to force conversion to Unix in the repo when you commit.
Yeah, git has a learning curve, and branching strategy is well into that curve. To do as you say it may be easier for you to fork the repo, push updates to your forked repo then make a pull request across repos. That's how big projects allow contributions from non-core developers. Not saying you're not a core developer! I'm just offering a workaround you might be more comfortable with than learning git before contributing.
One of the harder-to-grok things about git versus many other source/version control systems is that it's distributed, and any hierarchy is by convention, not enforced by design. There is no one source of truth in git, no main branch (aside from name by convention); every copy of the repo is functionally identical.
Also, branches and tags are simply just pointers to a commit; there's nothing magical about them other than the git software considering the current working folder is operating in the context of a branch and pushes the branch pointer forward when you commit in that context.
Well, we can worry about that, when I get to this point... First I need to be able to build the current project.
While installing & learning about Godot, I found out that the Godot C# tools require VS 2019...
So I started the installation of the Community edition with all Godot requirements (and C++, while I am at it... perhaps I can then uninstall my current 2017 version). It's 18GB, so it'll take a while. Going to bed for now...
(BTW: the other 5 projects, that do not depend on the Godot assemblies, I was able to compile successfully with 2017. So I am of good hope to manage the last steps tomorrow...)
While installing & learning about Godot, I found out that the Godot C# tools require VS 2019...
So I started the installation of the Community edition with all Godot requirements (and C++, while I am at it... perhaps I can then uninstall my current 2017 version). It's 18GB, so it'll take a while. Going to bed for now...
(BTW: the other 5 projects, that do not depend on the Godot assemblies, I was able to compile successfully with 2017. So I am of good hope to manage the last steps tomorrow...)
- Joined
- Mar 17, 2007
- Messages
- 9,284
Unpopular opinion: Git is popular because Linus Torvalds developed it, and enough of the potential audience thought, "Well, Linus developed Linux and that was good, so Git must be the way to go, too."
Not that it doesn't have some advantages, but IMO its rival Mercurial is more intuitive (a less steep learning curve), as well as its predecessor Subversion. I haven't used the early distributed version control systems (such as the eponymous DVCS), or Darcs. Alas, I haven't used Perforce, either, so I am not going to be as useful at translating terminology as I can be for Mercurial (Hg) or Subversion.
But I'll try to define the terms already mentioned in the thread.
-------------
Practical Example of C7 Development with Git Workflows and Screenshots
So what's that mean in practice? I'll use an example where I want to work on C7 at a coffee shop, on a laptop that doesn't have the C7 code, and finish the work at home on my desktop.
I'll also recommend using TortoiseGit since you are on Windows, as it lets you perform the Git actions via a context menu, and simplifies some steps. I wouldn't say it makes it easy, but more like using TortoiseGit is like learning to ski with an instructor, and using just the command line is like learning to ski just based on the instruction book that came with your skis, without an instructor. (This analogy might not be great; I'll report back in a month or two when I try to learn to ski)
So, I fire up my laptop, and need to get the code. I run, from my C:\ command prompt
This can also be done with TortoiseGit by right-clicking anywhere in Explorer, and choosing "Git clone...". If you have already copied the address (git@github.com:C7-Game/Prototype.git), Tortoise will auto-populate it by default. You will now have a folder C:\Development\Prototype, which contains the C7 code.
--
By default, the code will be on the Development branch. Let's say you want to add the High Scores screen. The next step would be to create a branch for it.
Already we've hit an unintuitive area. You would logically expect git branch to be used to create branches, but it doesn't (it lists available branches, with an indication of which one you are using). Instead, you have to pass the -b option to the git checkout command. But regardless, this creates a HighScores branch for your changes.
You can also do this in Tortoise, via right-click on the Prototype folder, and choosing TortoiseGit --> Create Branch. Enter the name, make sure you check the "Switch to New Branch" box, and click OK. You are now on the HighScores branch.
Don't forget that check box, or you will have created the branch but still be on Development
--
Now make some changes. Let's say you the background displaying, and decide that is a good batch of changes. You are ready to commit. This is another area where Tortoise is easier than the command line. In Tortoise, simply right-click on Prototype, and choose "Git Commit -> HighScores". It displays this screen:
New files and existing files are separated out; assuming you want the new files (they weren't just temporary scratch files), you will want to click either of the red buttons indicated to include them, as appropriate. You can also see in green that it shows that you are committing to the HighScores branch, which is correct. If you forgot to create a branch, it's easy to do so here, via the "new branch" option, which will cause a text field to appear for the new branch name.
You can also right-click on each file and choose "Compare with base" to review what you've changed, if you'd like.
If you do this process from the command line, you must first use git add to "add" your changes (the term stage your changes is also used), and then do a git commit. It also is easier to commit to a branch you don't intend to from the command line, assuming you are using the default Windows command line. While there are some benefits to git add, as a beginner to Git I strongly recommend ignoring it and using the simpler TortoiseGit workflow instead. Even as someone who's used Git off and on since 2013, I haven't used the command line version of this workflow on this project, and haven't missed it.
----
Now let's say I made another commit, and then it's time to head home. To do so, I would push. You'll notice that Tortoise gives you a "Commit & Push" option above (if you don't see it by default, it will be available via the dropdown next to the same button, which is likely labeled "Commit". As a beginner, I recommend simply using Commit & Push all the time. That way, your changes will always be on the server. If you are offline, you may have to simply Commit, without pushing. In that case, you can push by right-clicking on Prototype and choosing "TortoiseGit -> Push".
From the command line, in theory you can push with:
However, it usually isn't smart enough to realize you want to push to the branch you just created, and will give an error about how you need to run:
If you run that, it will work. But it's another example of where Git is not user-friendly by default, and TortoiseGit makes the process more approachable.
----
Now let's say you get home, and want to finish up the HighScores work. You already have the code on this computer, but not the HighScores work. This is a two-step process via Tortoise.
First, right-click on the Prototype folder and choose "TortoiseGit -> fetch". The default options are all okay. You'll see it print some stuff out, such as:
Notice that [new branch] - It's your HighScores branch! Close the fetch window, and then choose TortoiseGit -> Switch/Checkout. There will be a drop-down that defaults to your current branch, likely Development. Click the dropdown, and choose remotes/origins/HighScores:
The remotes/origin/ is only necessary the first time you switch to a new branch.
Select OK, and the dialog will switch you to the HighScores branch.
----
Now, make some changes, commit, them, and push them. Once you are done, you can use the GitHub user interface to open a Pull Request. If you load GitHub shortly after pushing changes, there will be a banner at the top suggesting that action. It will give you a comparison of your changes to what you started with, which can be useful for a self review, and will also list all of the commits. If you're like me, then if you don't push every time you commit, you might occasionally find you forgot to push the latest changes.
----
That's the basic workflow. As you can see, Tortoise simplifies a few things, and while its context menu has a lot of options, you can ignore the ones you don't know about until you learn about them. Is it simpler than Perforce? Probably not. But it's better than having to figure it all out at the command line, or trying to learn everything up front. There are definitely still areas of Git that I don't know about, as well as Tortoise context menus that I have rarely if ever used.
But that's in some ways the beauty of it - you can start with a few things, and ignore the rest until something goes horribly wrong and those advanced commands are the only way to fix things. In a lot of those cases of things being horribly wrong, it's easier to delete everything locally and start over with a clone than to fix the problem. Which isn't great, but is an acceptable work-around more often than not.
------------------
From what I've heard, Perforce is the best of the commercial source control systems. Why do 97% of new projects use Git? Well, companies are cheap, for one, and don't want to spend money. Two, other commercial source control products gave commercial source control a bad name. Visual Source Safe was especially notorious in this regard, sometimes messing up the code it was supposed to keep safe. But Team Foundation Server had its issues (though I hear it has gradually improved), and CA Harvest is awful to anyone who's ever used Subversion, probably to anyone who's ever used CVS as well. A lot of companies that got burned by VSS or Harvest were probably skeptical of spending money on another commercial solution that may have looked similar at the surface when open-source Subversion already had a better reputation than what they had been using (I've personally worked for a company that went Harvest/TFS -> Subversion -> Git, incrementally and sadly with Harvest not full eliminated before I started). And three, the people making these decisions are usually either in the business (thus not knowing how hard the products are to use), or already the experts (thus past the learning curve, perhaps by enough to not remember it). My hypothesis is many of these expert technical users jumped on Git fairly early due to Linus's close association with it.
Lastly, now we're at the point where that 97% figure is fairly accurate, so there's an incumbent effect favoring Git. It's also easier to use on open-source projects than the commercial alternatives since it's free, although that alone doesn't make it any better of an option than Subversion or Mercurial, or even older options such as Dachs. The other factor that makes it more common for open-source is that there have been a lot of web services built around it, most prominently GitHub. I've read several articles over the years arguing that it was really GitHub, rather than anything inherent to Git itself, that caused Git to win the version control wars - and those articles have a good point. There are some alternatives to GitHub that support Subversion or Mercurial, but there are far fewer options to choose from. And even then, while Mercurial and Subversion are IMO easier to learn than Git, I don't know how much easier they would be from a Perforce background.
Not that it doesn't have some advantages, but IMO its rival Mercurial is more intuitive (a less steep learning curve), as well as its predecessor Subversion. I haven't used the early distributed version control systems (such as the eponymous DVCS), or Darcs. Alas, I haven't used Perforce, either, so I am not going to be as useful at translating terminology as I can be for Mercurial (Hg) or Subversion.
But I'll try to define the terms already mentioned in the thread.
Spoiler Term Definitions, with Perforce synonyms where possible :
-------------
Practical Example of C7 Development with Git Workflows and Screenshots
So what's that mean in practice? I'll use an example where I want to work on C7 at a coffee shop, on a laptop that doesn't have the C7 code, and finish the work at home on my desktop.
I'll also recommend using TortoiseGit since you are on Windows, as it lets you perform the Git actions via a context menu, and simplifies some steps. I wouldn't say it makes it easy, but more like using TortoiseGit is like learning to ski with an instructor, and using just the command line is like learning to ski just based on the instruction book that came with your skis, without an instructor. (This analogy might not be great; I'll report back in a month or two when I try to learn to ski)
So, I fire up my laptop, and need to get the code. I run, from my C:\ command prompt
Code:
cd Development
git clone git@github.com:C7-Game/Prototype.gitThis can also be done with TortoiseGit by right-clicking anywhere in Explorer, and choosing "Git clone...". If you have already copied the address (git@github.com:C7-Game/Prototype.git), Tortoise will auto-populate it by default. You will now have a folder C:\Development\Prototype, which contains the C7 code.
--
By default, the code will be on the Development branch. Let's say you want to add the High Scores screen. The next step would be to create a branch for it.
Code:
git checkout -b HighScoresAlready we've hit an unintuitive area. You would logically expect git branch to be used to create branches, but it doesn't (it lists available branches, with an indication of which one you are using). Instead, you have to pass the -b option to the git checkout command. But regardless, this creates a HighScores branch for your changes.
You can also do this in Tortoise, via right-click on the Prototype folder, and choosing TortoiseGit --> Create Branch. Enter the name, make sure you check the "Switch to New Branch" box, and click OK. You are now on the HighScores branch.
Don't forget that check box, or you will have created the branch but still be on Development
--
Now make some changes. Let's say you the background displaying, and decide that is a good batch of changes. You are ready to commit. This is another area where Tortoise is easier than the command line. In Tortoise, simply right-click on Prototype, and choose "Git Commit -> HighScores". It displays this screen:
New files and existing files are separated out; assuming you want the new files (they weren't just temporary scratch files), you will want to click either of the red buttons indicated to include them, as appropriate. You can also see in green that it shows that you are committing to the HighScores branch, which is correct. If you forgot to create a branch, it's easy to do so here, via the "new branch" option, which will cause a text field to appear for the new branch name.
You can also right-click on each file and choose "Compare with base" to review what you've changed, if you'd like.
If you do this process from the command line, you must first use git add to "add" your changes (the term stage your changes is also used), and then do a git commit. It also is easier to commit to a branch you don't intend to from the command line, assuming you are using the default Windows command line. While there are some benefits to git add, as a beginner to Git I strongly recommend ignoring it and using the simpler TortoiseGit workflow instead. Even as someone who's used Git off and on since 2013, I haven't used the command line version of this workflow on this project, and haven't missed it.
----
Now let's say I made another commit, and then it's time to head home. To do so, I would push. You'll notice that Tortoise gives you a "Commit & Push" option above (if you don't see it by default, it will be available via the dropdown next to the same button, which is likely labeled "Commit". As a beginner, I recommend simply using Commit & Push all the time. That way, your changes will always be on the server. If you are offline, you may have to simply Commit, without pushing. In that case, you can push by right-clicking on Prototype and choosing "TortoiseGit -> Push".
From the command line, in theory you can push with:
Code:
git pushHowever, it usually isn't smart enough to realize you want to push to the branch you just created, and will give an error about how you need to run:
Code:
git push --set-upstream origin HighScoresIf you run that, it will work. But it's another example of where Git is not user-friendly by default, and TortoiseGit makes the process more approachable.
----
Now let's say you get home, and want to finish up the HighScores work. You already have the code on this computer, but not the HighScores work. This is a two-step process via Tortoise.
First, right-click on the Prototype folder and choose "TortoiseGit -> fetch". The default options are all okay. You'll see it print some stuff out, such as:
Code:
f3c03dd..3182552 Development -> origin/Development
= [up to date] BarbariansOnTheProwl -> origin/BarbariansOnTheProwl
= [up to date] ExperimentsWithMapView -> origin/ExperimentsWithMapView
= [up to date] ExperimentsWithMapView2 -> origin/ExperimentsWithMapView2
* [new branch] HighScores -> origin/HighScores
87fc49c..38c3bdb UnitAnimation -> origin/UnitAnimation
76016f6..068c159 civ3-home -> origin/civ3-home
= [up to date] console-lua-civ3 -> origin/console-lua-civ3
= [up to date] exp-mapgen -> origin/exp-mapgen
= [up to date] load-game -> origin/load-game
= [up to date] main -> origin/main
= [up to date] mod-media-support -> origin/mod-media-support
= [up to date] repeating_tile_map -> origin/repeating_tile_mapNotice that [new branch] - It's your HighScores branch! Close the fetch window, and then choose TortoiseGit -> Switch/Checkout. There will be a drop-down that defaults to your current branch, likely Development. Click the dropdown, and choose remotes/origins/HighScores:
The remotes/origin/ is only necessary the first time you switch to a new branch.
Select OK, and the dialog will switch you to the HighScores branch.
----
Now, make some changes, commit, them, and push them. Once you are done, you can use the GitHub user interface to open a Pull Request. If you load GitHub shortly after pushing changes, there will be a banner at the top suggesting that action. It will give you a comparison of your changes to what you started with, which can be useful for a self review, and will also list all of the commits. If you're like me, then if you don't push every time you commit, you might occasionally find you forgot to push the latest changes.
----
That's the basic workflow. As you can see, Tortoise simplifies a few things, and while its context menu has a lot of options, you can ignore the ones you don't know about until you learn about them. Is it simpler than Perforce? Probably not. But it's better than having to figure it all out at the command line, or trying to learn everything up front. There are definitely still areas of Git that I don't know about, as well as Tortoise context menus that I have rarely if ever used.
But that's in some ways the beauty of it - you can start with a few things, and ignore the rest until something goes horribly wrong and those advanced commands are the only way to fix things. In a lot of those cases of things being horribly wrong, it's easier to delete everything locally and start over with a clone than to fix the problem. Which isn't great, but is an acceptable work-around more often than not.
------------------
From what I've heard, Perforce is the best of the commercial source control systems. Why do 97% of new projects use Git? Well, companies are cheap, for one, and don't want to spend money. Two, other commercial source control products gave commercial source control a bad name. Visual Source Safe was especially notorious in this regard, sometimes messing up the code it was supposed to keep safe. But Team Foundation Server had its issues (though I hear it has gradually improved), and CA Harvest is awful to anyone who's ever used Subversion, probably to anyone who's ever used CVS as well. A lot of companies that got burned by VSS or Harvest were probably skeptical of spending money on another commercial solution that may have looked similar at the surface when open-source Subversion already had a better reputation than what they had been using (I've personally worked for a company that went Harvest/TFS -> Subversion -> Git, incrementally and sadly with Harvest not full eliminated before I started). And three, the people making these decisions are usually either in the business (thus not knowing how hard the products are to use), or already the experts (thus past the learning curve, perhaps by enough to not remember it). My hypothesis is many of these expert technical users jumped on Git fairly early due to Linus's close association with it.
Lastly, now we're at the point where that 97% figure is fairly accurate, so there's an incumbent effect favoring Git. It's also easier to use on open-source projects than the commercial alternatives since it's free, although that alone doesn't make it any better of an option than Subversion or Mercurial, or even older options such as Dachs. The other factor that makes it more common for open-source is that there have been a lot of web services built around it, most prominently GitHub. I've read several articles over the years arguing that it was really GitHub, rather than anything inherent to Git itself, that caused Git to win the version control wars - and those articles have a good point. There are some alternatives to GitHub that support Subversion or Mercurial, but there are far fewer options to choose from. And even then, while Mercurial and Subversion are IMO easier to learn than Git, I don't know how much easier they would be from a Perforce background.
Last edited:
WildWeazel
Carthago Creanda Est
Coming from Subversion, git was strange and confusing at first but I got the hang of it by working on side projects with it and googling how to do X, and eventually came to appreciate it. (FWIW I never found a GUI I was satisfied with, and only use the CLI) It is overly complicated and unintuitive in some ways but all you really need to know for most cases is pull, push, status, add, commit, diff, and checkout.
Of all the guides out there I found this gamified one the most helpful: https://learngitbranching.js.org/
---
On branch workflow, I'm kind of torn. Right, let's not be too formal and quash motivation. I also want to get off on the right foot, and am hoping this grows to a mature OSS project with contribution standards and automated tests and a CI/CD pipeline and all that. Let's at least keep doing work in branches, and try to get somebody to look at it before merging to development even if just a sanity check. It'll be more of a concern as the software gets bigger and more complex, but even now I'd like to (a) get in the habit of putting everything through a PR, and (b) have more eyes on the core code while it's still a manageable size.
Of all the guides out there I found this gamified one the most helpful: https://learngitbranching.js.org/
---
On branch workflow, I'm kind of torn. Right, let's not be too formal and quash motivation. I also want to get off on the right foot, and am hoping this grows to a mature OSS project with contribution standards and automated tests and a CI/CD pipeline and all that. Let's at least keep doing work in branches, and try to get somebody to look at it before merging to development even if just a sanity check. It'll be more of a concern as the software gets bigger and more complex, but even now I'd like to (a) get in the habit of putting everything through a PR, and (b) have more eyes on the core code while it's still a manageable size.
Thanks guys, you made my day. This Git cheat-sheet will come in handy indeed!
So VS 2019 and the Godot plugin for VS 2019 ("GodotAddinVS.vsix") installed successfully, but nevertheless I'm still missing the Godot assemblies:
and same for "GodotSharpEditor".
I looked on the Godot homepage and asked Google but couldn't find any place where to download these?!
Also there is a warning that worries me a bit:
Allthough the projects using ini-parser all compile ok.
Edit: Ok, never mind, found them...
So VS 2019 and the Godot plugin for VS 2019 ("GodotAddinVS.vsix") installed successfully, but nevertheless I'm still missing the Godot assemblies:
Code:
Could not resolve this reference. Could not locate the assembly "GodotSharp".and same for "GodotSharpEditor".
I looked on the Godot homepage and asked Google but couldn't find any place where to download these?!
Also there is a warning that worries me a bit:
Code:
Warning NU1701 Package 'ini-parser 3.4.0' was restored using '.NETFramework,Version=v4.6.1, .NETFramework,Version=v4.6.2, .NETFramework,Version=v4.7, .NETFramework,Version=v4.7.1, .NETFramework,Version=v4.7.2, .NETFramework,Version=v4.8' instead of the project target framework '.NETStandard,Version=v2.0'. This package may not be fully compatible with your project.Allthough the projects using ini-parser all compile ok.
Edit: Ok, never mind, found them...
Last edited:
... but for the life of mine I cannot add a reference to the two dlls?!
VS 2019 does nothing, no error, no nothing, and when I try to remove the (broken) reference in VS 2017, it says
(I have extracted the Godot SDK to D: and the two DLLs are there under ...\Godot_v3.4\GodotSharp\Api\Debug|Release)
I tried to fix this by editing C7.csproj in an editor, but it is more or less empty?! No references are maintained here? Where are these settings located?
VS 2019 does nothing, no error, no nothing, and when I try to remove the (broken) reference in VS 2017, it says
(I have extracted the Godot SDK to D: and the two DLLs are there under ...\Godot_v3.4\GodotSharp\Api\Debug|Release)
I tried to fix this by editing C7.csproj in an editor, but it is more or less empty?! No references are maintained here? Where are these settings located?
Puppeteer
Emperor
TL;DR: Edit in VS, build from Godot. Don't fret the netstandard compatibility warning. You may need to set the Godot editor to link to VS. There may be other VS-specific needs to make Intellisense work well, but as far as I know the rest of us are using VSCode. (Edit: I had a link here for Godot and Visual Studio, but it was wrong. If you see a mention of SCons, you're reading the wrong document to help with C7. SCons is for actually compiling the Godot C++ binary.) https://godotengine.org/article/csharp-vs-and-vscode - Ah, ok, I do have this plugin installed (for VSCode, but there is a VS version, too). I don't recall installing it, but it's there. That must be the magic to make the Godot SDK references work.
I'm using VSCode for editing, but for actually compiling I have to go into Godot itself and build the project. I briefly tried to figure out if I could compile code outside of Godot (for xUnit tests) but was unable to figure it out. Then again, I'm pretty new to C#. I don't seem to be able to just grab the Godot SDK and go to town outside of Godot.
I guess I should back up and explain a little about the whole environment: Godot itself is in C++, but we're not generally (or at all so far) compiling Godot code. To make a distributable game, you export it from the Godot editor. All that really does from a high level is to package up the project folder into a PCK or ZIP file and drop it alongside a precompiled redistributable Godot binary. (I mean, it's also open-source code, so you *could* compile your own binary if you want, but not from Godot itself.)
From a typical Godot game creator's point of view, they would use the Godot UI and scene tree to make most of the game, then connect some scripting (in GDScript which is basically Python syntax) for the advanced bits. The Mono version of Godot allows C# "scripts".
As code developers, we're coming at it C# first and using Godot as a UI library for the most part. So let's look at the export again from a Mono C# point of view: The Godot SDK exposes to the C# environment the C++ objects in Godot, so whenever we're using a Godot namespace object it's *probably* just a bridge to the C++ code which may have some edge case implications we bump into but for the most part should be able to ignore. (e.g. We can't necessarily expect dropping all references to a Godot object to free its memory, but in most cases that probably doesn't matter.) So on export, Godot compiles the C# code into Mono dlls, then bundles the project folder and drops it alongside a precompiled redistributable Godot binary.
I'm not sure exactly how that C# to Godot bridge works or if that's even the right way to talk about it, but maybe that's why we cant seem to build directly from VSCode or VS.
Godot can be configure to open VSCode (and I think Visual Studio) and act as a language server for it. I don't fully understand what that means, but I usually don't do it that way because it only opens the Godot project and not the whole repo with our other libraries. I just alt-tab back to Godot for building and testing.
I should probably make some videos on this.
Don't worry about those "incompatible" warnings for now. Quintillus and I have discussed it in the Godot / Mono Synchronization Thread thread. We should probably fix it by changing the target framework of the libraries, but at the moment it doesn't appear to have any actual impact, and I'm still trying to get a feel for if anyone else besides Quintillus and I are using any of the command line things I've done. If not, then I think we're ready to synchronize the targets as soon as both Quintillus and I (and anyone else using them) are confident in running console apps in Mono instead of dotnet.
(In short, netstandardx.x targets are virtual targets intended to be language-feature-compatible with both Mono and dotnetcore build tools, and I was using dotnetcore/dotnet for console apps using these libraries because I had no clue how to do Mono on the console, but I think I've figured it out now.)
I'm also getting some other warnings about our code when building, but everything is in such a state of flux right now that I'm not terribly worried about it.
I'm using VSCode for editing, but for actually compiling I have to go into Godot itself and build the project. I briefly tried to figure out if I could compile code outside of Godot (for xUnit tests) but was unable to figure it out. Then again, I'm pretty new to C#. I don't seem to be able to just grab the Godot SDK and go to town outside of Godot.
I guess I should back up and explain a little about the whole environment: Godot itself is in C++, but we're not generally (or at all so far) compiling Godot code. To make a distributable game, you export it from the Godot editor. All that really does from a high level is to package up the project folder into a PCK or ZIP file and drop it alongside a precompiled redistributable Godot binary. (I mean, it's also open-source code, so you *could* compile your own binary if you want, but not from Godot itself.)
From a typical Godot game creator's point of view, they would use the Godot UI and scene tree to make most of the game, then connect some scripting (in GDScript which is basically Python syntax) for the advanced bits. The Mono version of Godot allows C# "scripts".
As code developers, we're coming at it C# first and using Godot as a UI library for the most part. So let's look at the export again from a Mono C# point of view: The Godot SDK exposes to the C# environment the C++ objects in Godot, so whenever we're using a Godot namespace object it's *probably* just a bridge to the C++ code which may have some edge case implications we bump into but for the most part should be able to ignore. (e.g. We can't necessarily expect dropping all references to a Godot object to free its memory, but in most cases that probably doesn't matter.) So on export, Godot compiles the C# code into Mono dlls, then bundles the project folder and drops it alongside a precompiled redistributable Godot binary.
I'm not sure exactly how that C# to Godot bridge works or if that's even the right way to talk about it, but maybe that's why we cant seem to build directly from VSCode or VS.
Godot can be configure to open VSCode (and I think Visual Studio) and act as a language server for it. I don't fully understand what that means, but I usually don't do it that way because it only opens the Godot project and not the whole repo with our other libraries. I just alt-tab back to Godot for building and testing.
I should probably make some videos on this.
Don't worry about those "incompatible" warnings for now. Quintillus and I have discussed it in the Godot / Mono Synchronization Thread thread. We should probably fix it by changing the target framework of the libraries, but at the moment it doesn't appear to have any actual impact, and I'm still trying to get a feel for if anyone else besides Quintillus and I are using any of the command line things I've done. If not, then I think we're ready to synchronize the targets as soon as both Quintillus and I (and anyone else using them) are confident in running console apps in Mono instead of dotnet.
(In short, netstandardx.x targets are virtual targets intended to be language-feature-compatible with both Mono and dotnetcore build tools, and I was using dotnetcore/dotnet for console apps using these libraries because I had no clue how to do Mono on the console, but I think I've figured it out now.)
I'm also getting some other warnings about our code when building, but everything is in such a state of flux right now that I'm not terribly worried about it.
Last edited:
