1. Firaxis celebrates the "Asian American and Pacific Islander Heritage Month", and offers a give-away of a Civ6 anthology copy (5 in total)! For all the details, please check the thread here. .
    Dismiss Notice
  2. Old World has finally been released on GOG and Steam, besides also being available in the Epic store . Come to our Old World forum and discuss with us!
    Dismiss Notice

Assembling the team

Discussion in 'Civ3 Future Development' started by WildWeazel, Nov 6, 2021.

  1. WildWeazel

    WildWeazel Carthago Creanda Est

    Joined:
    Jul 14, 2003
    Messages:
    7,206
    Location:
    %CIV3%\Conquests\Scenarios\
    If they're not issues I think you have to just recreate it. Issues can be added to multiple boards.
     
  2. Quintillus

    Quintillus Archiving Civ3 Content Supporter

    Joined:
    Mar 17, 2007
    Messages:
    7,166
    Location:
    Ohio
    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:

    upload_2021-11-29_21-30-54.png
     
    Puppeteer likes this.
  3. Ozymandias

    Ozymandias Archivist, redux Supporter

    Joined:
    Nov 5, 2001
    Messages:
    10,133
    Gender:
    Male
    Location:
    The lone and level sands
    I just realized that I never responded: :goodjob::goodjob::goodjob: 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.
     
    WildWeazel likes this.
  4. Ozymandias

    Ozymandias Archivist, redux Supporter

    Joined:
    Nov 5, 2001
    Messages:
    10,133
    Gender:
    Male
    Location:
    The lone and level sands
    I still wish that there could be a way to convert ( :undecide: )_ 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.)
     
  5. Puppeteer

    Puppeteer Emperor

    Joined:
    Oct 4, 2003
    Messages:
    1,687
    Location:
    Silverdale, WA, USA
    I have SMAC...on CD and GoG. Never looked at its art...just pulled it up...

    It's PCX. :shifty: 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: Nov 30, 2021
  6. WildWeazel

    WildWeazel Carthago Creanda Est

    Joined:
    Jul 14, 2003
    Messages:
    7,206
    Location:
    %CIV3%\Conquests\Scenarios\
    @Lanzelot are you still with us? Do you have mod powers here?
     
  7. Lanzelot

    Lanzelot Moderator Moderator

    Joined:
    Jun 25, 2007
    Messages:
    5,938
    Location:
    Heidelberg
    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: Dec 17, 2021
  8. WildWeazel

    WildWeazel Carthago Creanda Est

    Joined:
    Jul 14, 2003
    Messages:
    7,206
    Location:
    %CIV3%\Conquests\Scenarios\
    :yeah:

    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
     
  9. Kyriakos

    Kyriakos Creator

    Joined:
    Oct 15, 2003
    Messages:
    65,796
    Location:
    The Dream
    Well, I am here too. So you should have some new terrain/city gfx.
     
    Puppeteer and Quintillus like this.
  10. Quintillus

    Quintillus Archiving Civ3 Content Supporter

    Joined:
    Mar 17, 2007
    Messages:
    7,166
    Location:
    Ohio
    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.
     
  11. Puppeteer

    Puppeteer Emperor

    Joined:
    Oct 4, 2003
    Messages:
    1,687
    Location:
    Silverdale, WA, USA
    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.
     
    Quintillus likes this.
  12. Lanzelot

    Lanzelot Moderator Moderator

    Joined:
    Jun 25, 2007
    Messages:
    5,938
    Location:
    Heidelberg
    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?? :dunno:

    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... :cry: )

    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: Dec 14, 2021
  13. Lanzelot

    Lanzelot Moderator Moderator

    Joined:
    Jun 25, 2007
    Messages:
    5,938
    Location:
    Heidelberg
    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?
     
  14. Puppeteer

    Puppeteer Emperor

    Joined:
    Oct 4, 2003
    Messages:
    1,687
    Location:
    Silverdale, WA, USA
    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.
     
  15. Lanzelot

    Lanzelot Moderator Moderator

    Joined:
    Jun 25, 2007
    Messages:
    5,938
    Location:
    Heidelberg
    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...)
     
    Puppeteer likes this.
  16. Quintillus

    Quintillus Archiving Civ3 Content Supporter

    Joined:
    Mar 17, 2007
    Messages:
    7,166
    Location:
    Ohio
    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.

    Spoiler Term Definitions, with Perforce synonyms where possible :
    clone (verb) - to make a copy of a repository, usually to your computer from a server. Copies down the code, but also the version control history. This is unique to distributed version control systems, where everyone has an entire copy of the repository. Centralized ones (such as Subversion, and it appears Perforce) only have one central copy. The closest thing in Subversion is checkout (although it doesn't copy the entire history to your computer); it appears that sync is the closest Perforce concept.

    clone (noun) - The copy of the repository on your computer. Informally also called your copy of the code. Not used frequently as a noun, but I will be using the noun in subsequent definitions.

    pull (verb) - To synchronize the latest updates from the server to the clone on your computer. This is a one-way sync; it does not also move your changes to the server. Let's say I finished up my changes yesterday, and Puppeteer made some changes today, and I want to have his changes locally. I would run git pull to "pull" in his changes.

    fetch (verb) - This is a kind of confusing one. This asks the server what the latest changes are, so your local copy is aware of them. But it doesn't actually update your local copy. I rarely find myself running this.

    branch (noun) - A separate line of development work. The Perforce term of closest approximation appears to be codeline or maybe stream. Used when your line of work may take awhile, and you don't want it to affect other developers in the mean time. For example, Flintlock's animation work is in a branch as it takes awhile to finish up, and that way the other developers don't have half-baked animation in the mean time. Many teams get in a habit of creating a branch for all updates, as you can delete them later, and that helps avoids stepping on each other's toes.

    commit (verb) - To create a batch of changes that will live in the history of the repository, all grouped nicely together. This appears to be closest to submit in Perforce, although in Git the batch of changes initially will only be on your computer. This has some benefits, for example I could create a Git commit locally a couple weekends ago when I didn't have Internet at home, and thus logically group my batches of changes despite being offline. To get it online, you then need to...

    push (verb) - To move your changes, already committed, to the server. For simplicity's sake, we'll treat the copy on GitHub as the only server (which is the case for C7, and which de facto is the source of truth for C7). This one at least does what the name suggests!

    cherry-pick (verb) - This is a more advanced concepts; it's not uncommon for me to meet developers who've used Git for a couple years and don't know this term. It's best explained by an example. Let's say I am working on displaying marshes, and Puppeteer is working on displaying resources. We each have our own branches for the work. Along the way, Puppeteer figures out how to solve the gaps in the map that appear at certain zoom levels, and makes a commit of that fix to his branch. I have been annoyed by that bug, and want that change now, rather than waiting for our branches to finish up. I can cherry-pick just the commit where Puppeteer fixed the gap in the map (but not his changes related to displaying resources) to also appear in my branch. Essentially, it's a way of automatically duplicating change sets across branches, as opposed to manually making the same fix in two places. Niche, but can be handy at times.

    rebase (verb) - More common than cherry-pick, yet tougher to understand. Let's go back to the same example. Puppeteer and I both created our branches on Monday. Displaying marshes takes longer than displaying resources. Tonight (Tuesday), Puppeteer finishes displaying resources, and merges his branch into our primary branch (in C7, called Development; historically the most common name for the primary branch in Git is master. Subversion, and it looks like maybe Perforce, use the term trunk for the primary branch). I can continue working on displaying Marshes without Puppeteer's changes locally. However, I can also rebase my local copy, which rearranges the changes to it would appear that instead of starting from Monday's changes, I started with Puppeteer's changes already present. This can be useful when you are working on something that takes a long time, as the product may change significantly during that time. In the event that multiple people are working in the same area and occasionally changing the same code, it can also be useful so that if you are stepping on each other's toes, you learn that incrementally when you rebase, rather than all at once at the end.

    fork (verb) - To make another copy on the server of a repository (code base). This allows there to be not just one copy of C7 on GitHub, but I can create my own copy, that still lives on the server, but is entirely separate, including from an administration standpoint. There isn't really an analogy to this in Subversion or other centralized source control systems, beyond standing up another Subversion server and all the work that would involve. Can be used as a contribution model, as Puppeteer notes (and Lucien has done), can also be used to get a fresh copy to make changes to an open-source project that has been abandoned, or which a subset of the developers think should behave differently than it does. Named such because you get two (or more) twines coming from one base, like on the dining utensil.


    -------------

    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.git
    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.

    Code:
    git checkout -b HighScores
    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.

    upload_2021-12-14_18-50-39.png
    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:

    upload_2021-12-14_18-55-16.png

    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 push
    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:

    Code:
    git push --set-upstream origin HighScores
    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:

    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_map
    
    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:

    upload_2021-12-14_19-6-56.png

    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: Dec 14, 2021
    Lanzelot likes this.
  17. WildWeazel

    WildWeazel Carthago Creanda Est

    Joined:
    Jul 14, 2003
    Messages:
    7,206
    Location:
    %CIV3%\Conquests\Scenarios\
    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.
     
  18. Lanzelot

    Lanzelot Moderator Moderator

    Joined:
    Jun 25, 2007
    Messages:
    5,938
    Location:
    Heidelberg
    Thanks guys, you made my day. This Git cheat-sheet will come in handy indeed! :goodjob:

    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: Dec 15, 2021
    Quintillus likes this.
  19. Lanzelot

    Lanzelot Moderator Moderator

    Joined:
    Jun 25, 2007
    Messages:
    5,938
    Location:
    Heidelberg
    ... 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

    remove_ref.png

    (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?
     
  20. Puppeteer

    Puppeteer Emperor

    Joined:
    Oct 4, 2003
    Messages:
    1,687
    Location:
    Silverdale, WA, USA
    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.
     
    Last edited: Dec 15, 2021

Share This Page