Newbie question

If I were to go into vehicle_parts.json and add the WINDOW flag to the heavy duty hatch, would that allow curtains to be installed on it? If not, how can I make that happen?

And if I do make some small but potentially useful change to a json, is there a Complete Idiot’s Guide to getting it to someone who can include it? Git is scary, but I wouldn’t mind making myself useful by doing small things that more experienced people probably can’t be bothered with.

Window on hatch won’t work - I tried. The problem is that open/close system doesn’t understand multi-tile doors with curtains on them. It will open the doors, but leave curtains closed, which makes them block vision but not movement.

Git is scary (because there isn’t “one guide to all things git that you can just copy+paste”), but not actually hard. For small repos, it’s almost always the same, so you can just do what someone else did and it will work. Using console git, it’s like this:

[ol][li]Fork the repo on github (there’s a button that does it in the upper right part of the page)[/li]
[li]git clone[/li]
[li]git checkout -b my_branch_name[/li]
[li]Change the files (mod the jsons, overwrite the files etc.)[/li]
[li]git commit -a[/li]
[li]git push -u origin my_branch_name[/li][/ol]

Then you go to and the new branch will be there.
That’s it for the first PR.
Notice how almost all of those points are basically ctrl+c+v level of complexity.

Some further small Github notes:

[ol][li]You only need to do the fork & “clone” parts the first time. No need to do them on further PR’s. (If that wasn’t obvious).[/li]
[li]If you decide to modify a PR further (say to include some needed fixes) there’s no need to make a new branch and PR with those changes. Just do “git checkout pr_branch_name” (note the lack of a “-b”) make your changes, commit them, and then push them.[/li]
[li]New PR = new branch you make with git checkout. Don’t mix PR’s on the same branch, and don’t put PR’s on your master branch![/li]
[li]I find it’s helpful to add an upstream for your master branch (some git clients already do this automatically). Just run
"git remote add upstream" the very first time you do anything.[/li]
[li]Generally most times before you start a new PR (step 3 below) you will want to do this:
[list type=decimal]
[li]“git checkout master”[/li]
[li]“git pull upstream master”[/li]
That will ensure that your master branch is up to date with the latest experimental, and you aren’t accidentally trying to add changes to code that is a month old and totally different from what you are currently seeing.[/li]
[li]Just for some basic command meanings:
[li]git checkout X - Change to branch X. “-b” actually means “make a new branch with this name”, but if you leave it off for a new branch and you are only working with the C:DDA github repository then it will usually just automatically assume it as needed.[/li]
[li]git commit - Basically a “I’m ready to add these files to my local copy” command. Adds any files that have been changed and saved to your current branch.[/li]
[li]git push X - Says “take my local copy of these files, and then add them to the internet copy at X”. Once again a fair bit of git clients will automatically assume the “-u origin my_branch_name” part of the command, so it’s not necessarily needed depending on your client.[/li]
[li]git pull X - Says “take the internet copy of the files at X, and try to merge them into what I’ve got here in my current local branch”. This one can get kinda complicated at times if you are trying to update PR’s, but if you are just using it to update your master branch (such as I mentioned in #5) then it’s just a fire and forget command like any of the others.[/li]
[li]Here’s the basic method to update a PR (lots of the time you won’t need this, but it’s fairly daunting so it’s good to know ahead of time).
[list type=decimal]
[li]“git checkout X” to whatever PR branch you want to update.[/li]
[li]“git fetch upstream master”[/li]
[li]“git merge -X patience FETCH_HEAD” (the patience part is especially important for JSON merging, since they break rather easily).[/li]
[li]If it mentions something about conflicts then open up what files it says conflict and look for the “>>>>>>>>>>>>” (preferably with a find command). There might be multiple of these. Basically this means that both you and someone in the main branch changed the same bit of code, and you need to decide what is important and what isn’t. The two options will be divided by a =========== for comparison purposes, usually you will need to take the bits of your changes that are important and the bits of their changes that are important and manually merge them into a single cohesive whole.[/li]
[li]If you had to do the previous step, then do “git commit -a” once you are done fixing all of the conflicts[/li]
[li]Assuming you did all of the previous steps correctly, you should be done merging! Do “git push” and pat yourself on the back. :)[/li]
[li]Don’t use the basic notepad, wordpad, or microsoft word to edit files. I personally suggest using Notepad++, it’s all you will need in most cases.[/li]
[li]Don’t use tabs. Seriously, use 4 spaces instead. If you are using Notepad++ there is an option to make it so when you hit the TAB key it automatically uses 4 spaces instead, to save you some time.[/li][/ol]

And that’s about it from me. I look forward to giving my input on any changes you decide to try to PR. Happy developing! :smiley:

I understood basically none of that and have no idea what it means to “checkout -b” something. Sorry.

I do have notepad++ and will be clicking around git for a while trying to figure it out.

Just paste those in git console (after installing git and opening the console).

The easiest way to do it is to download a git client (There are a bunch to choose from). Afterwords you will be able to put the listed commands into the terminal window which you can open through your client, usually through a preference menu somewhere.

You can also install git directly and then use it through any terminal of your choice, but I find working with a GUI is a little nicer for people not too comfortable with the command line.