At the moment we use the minecraft folder with all fiels inside

i feel it would by more usful to adapt MultiMC's structure
and keep alpacka related files outside of the minecraft folder
i think it will help with implementing features later because we do not have
feature/feature_name/somefiles in the minecraft folder where some mod or minecraft itself might mess with it
the gitignore rules will be more compley because we have to ignore the patches/ folder and instance.cfg.. although the latter could be kept in source control if one so desires (not recommended)

i would guess the rewrite caused this..

that specific json file is nonexistant

• not all versions are listed
• and not all unlisted versions have files ?

happens when trying to call gitmc update which installs forge

example URL: https://meta.multimc.org/net.minecraftforge/1.11.2-13.20.0.2262.json

at GitMC.Lib.Instances.MultiMC.MultiMCMeta.GetForgePatch(String fullVersion) in D:\dev\gitmc\src\GitMC.Lib\Instances\MultiMC\MultiMCMeta.cs:line 32

allow installing the pack and running all command without actually doing anything special, like installing mc versions or forge versions

Currently if the cache contains the file, it will simply return it without checking if it has the latest version.

downloading the patch files is no longer necessary,
instead set
ForgeVersion=13.20.0.2282 in instance.cfg

there seems to be no libgit2sharp equivalent to git checkout -b branchname
so for now that has to be done manually

WE NEED LOGGERS

config file wrapper that asks the user for values if they are not set or invalid

dumb installer scripts

• Windows (BAT)
  • any
  • win7-x64
• OSX (bash)
  • any
  • osx.10.11-x64
• Linux (bash)
  • any
  • ubuntu.16.10-x64

packet managers

• AUR (pkgbuild)

smart wrapper scripts

installs gitmc

open terminal for user input

• Windows
• Linux
• OSX

currently overriding name, description and links
so any field from https://github.com/NikkyAI/alpacka/blob/master/src/Alpacka.Lib/Pack/EntryMod.cs
is ignored and does not appear in the packbuild.json

example:

- src: https://asie.pl/files/minecraft/foamfix-0.6.2-beta1-anarchy.jar
  description: cool stuff
  name: fomafix
  links:
    website: https://asie.pl/Projects/Minecraft/Mods/FoamFix/

results in

{
  "src": "https://asie.pl/files/minecraft/foamfix-0.6.2-beta1-anarchy.jar",
  "version": "recommended",
  "path": "mods/foamfix-0.6.2-beta1-anarchy.jar"
},

Create an interface / callback that allows tracking download progress of both specific files and batches of files, so this can eventually be displayed in the GUI as well as CLI. This would also include the CLI implementation.

• Command Documentation
• tutorials
  • gitignore

instead of using hardcoded $multimcpath/instance
read InstanceDir=instances from multimc.cfg

add general better handling of parsing and editing
key=value
format for multimc configuration files

edit:
final strusture we go for is

files:
  common:
    - foo

  server:
    side: server
    list:
      - foo

  client:
    side: client
    list:
      - foo
    optional:
      feature: optional
      version: latest
      list:
        - foo

with the options of using & to link the keys

splitting the mods list in multiple client / server lists
with different sets of default values could allow for a much lighter and easier readable config file

mods:											# Dictionary<string, ModList>
  list_Name: 									# ModList
    defaults: 									# ModEntry
      value: default
      othervalue: blub
    list: 										# List<ModEntry>
      - mod name
      - src: http://example.com/file.jar
        version: x.y.z
  other_list:
  ...

the comments specify the type of the compound object

the type of mods would change from a list into a dictionary of lists with defaults, which would probably be another custom type
it can all be compacted into a single list for emitting json

examples of the new forma and a comparison to the old onet:
https://gist.github.com/NikkyAI/d7a0fd44e101c85220d4fab715cdb0e4
the old format as far fewer simple lists of strings and lots of repetition, the proposed format looks cleaner, sliwghtly mpre compact and saves ~30 lines in this example

Problematic because the factory methods are not part of the lock itself - a task could be created more than once before an element is added in some rare corner cases. Not super important but I want to do it right anyway. Just use a regular Dictionary with locks.

TEMPORARY FIX:
replace the file ~/.nuget/packages/libgit2sharp.nativebinaries/1.0.165/runtimes/linux-x64/native/libgit2-1196807.so with the libgit2.so file installed on your system

edit: the binaries supplied by libgit2sharp.nativebinaries are complied on ubuntu and will most likely only work on ubuntu derivates libgit2/libgit2sharp.nativebinaries#48

options are to wait or to try compiling libgit2 on archlinux and replace the binary in the aur package

on linux (tested on at least arch and centos) it does not find the .so file correctly when trying to do any git operations

email from the dev ( @AArnott )

Sorry to hear that. I suggest you take this up with the CoreCLR folks. The libgit2sharp library just depends on the libgit2sharp.native package, which uses the package format that CoreCLR is supposed to know how to load from. Apparently it doesn't work on Centos 7, which is a bit surprising.
As a possible workaround, you could derive your own class from AssemblyLoadContext where you can override the native library load method and help it find the right one.

Nothing more I can do for you though. Sorry.

downloading the packs zip, unpacking in minecraft
parsing the versions
projectid -> project name
fileid -> filename (version part)

requires: #31

features will live in separate folders

challenges

selecting features when downloading / updating a pack

a simple CLI input or selecting checkboxes / radiobuttons with a cursor is sufficient
this will be also useful fo #4

installing features, especially mods and removing them

in short.. keeping track of files and being able to reverse a transaction before applying a different one

identifying incompatible features

and disabling incompatible features or preventing it from being enabled at the same time
can be done by matching the paths of the resource entries

live sync of files back into the feature folders

useful for development, but could generally be always useful
maybe just use symlinks on unix and junction points on windows
although junctions only work for folders.. so that might be a pain
and i am not sure how minecraft reacts to symlinks or junctions

changes

mods in packbuild.json will have to change to files or something similar

packbuild.json needs to include metadata for the features

most important keys and names
as well group info and incompatibilities / exclude data

we can resolve the download url from
http://docs.solder.io/docs/apimodmodnamemodversion

add a functione to create a empty instance of any type
command should be
alpacka init [type] --name "new pack" -- description ... --author "Nikky" --author "copygirl"
custom directory setting might be useful for initializing as a server but should probably be ignored when initializing a multimc pack