• fileSize property on files are not serialized
• files need to be bootstrapped...

link

cant get it by the ?tree= either, weird

mcman errors by saying:

2: Fetching jenkins builds
3: missing field `fileName`

Would be nice if you could just do mcman run --ngrok and it would also start ngrok

or playit.gg or other alternatives :p

Currently, mcman has no licence.
See here why you should choose one: https://choosealicense.com/no-permission/

Customizable build hooks, e.g. to fetch information from the host OS when building, do things differently based on the environment, etc.

First idea for how the configuration of this would look:

An mcman repository would get an optional hooks/ folder, containing any number of files, to be named freely by the user.

The server.toml file will get a new section:

[hooks.{filename}]
when = "post" | "pre" | "post_unpack" | ...
onfail = "error" | "ignore" | "warn"
output = "show" | "hide"
description = "Fetch current admins from a matrix chatroom and /op them in every world"
env = { default_admin = "john" }

When running mcman build, each file in the hooks folder named after a corresponding "hooks" subsection in server.toml will be executed at the specified "when" moment. The description would be displayed to the terminal for every hook.

Each hook executed will get access to some environment variables, which will depend on the settings specified in server.toml, such as the "env" setting, as well as the "when" setting (e.g. a post_unpack hook would get the folder to which a world has been unpacked passed in some environment variable).

In this proposal, arguments to programs go unused.

I changed the PORT variable in server.toml to 25001, but it didn't change in server.properties after running mcman build.
Is this a bug, or am I doing something wrong.

This is server.toml (without all the mods):

name = "exploration++"
mc_version = "1.20.1"

[jar]
type = "fabric"
loader = "0.15.3"
installer = "latest"

[variables]
PORT = "25001"

[launcher]
eula_args = true
nogui = true

And this is the generated server.properties:

enable-jmx-monitoring=false
rcon.port=25575
level-seed=
gamemode=survival
enable-command-block=false
enable-query=false
generator-settings={}
enforce-secure-profile=true
level-name=world
motd=${SERVER_NAME\:A Minecraft Server}
query.port=25565
pvp=true
generate-structures=true
max-chained-neighbor-updates=1000000
difficulty=easy
network-compression-threshold=256
max-tick-time=60000
require-resource-pack=false
use-native-transport=true
max-players=20
online-mode=true
enable-status=true
allow-flight=false
initial-disabled-packs=
broadcast-rcon-to-ops=true
view-distance=10
server-ip=
resource-pack-prompt=
allow-nether=true
server-port=25565
enable-rcon=false
sync-chunk-writes=true
op-permission-level=4
prevent-proxy-connections=false
hide-online-players=false
resource-pack=
entity-broadcast-range-percentage=100
simulation-distance=10
rcon.password=
player-idle-timeout=0
force-gamemode=false
rate-limit=0
hardcore=false
white-list=false
broadcast-console-to-ops=true
spawn-npcs=true
spawn-animals=true
function-permission-level=2
initial-enabled-packs=vanilla,fabric,tectonic\:terratonic
level-type=bclib\:normal
text-filtering-config=
spawn-monsters=true
enforce-whitelist=false
spawn-protection=16
resource-pack-sha1=
max-world-size=29999984

small utility to export as a bash file containing wget commands :p might not implement

• pufferfish
• folia
• plazma
• sponge

a very bad issue right now is that deleted addons in server.toml do not get deleted. a metafile containing metadata could be a fix to this and allow us to have many more quality of life features

name ideas:

• .server.toml.lock
• .server.lock
• .mcman.lock
• .mcman.json
• .server.json

what itll contain:

• last build date, and how long it took
• resolved downloadable infos
• list of downloadables downloaded
• server type
• list of bootstrapped files
• possibly server variables
• hashes of files?

what thisll allow:

• deleting removed downloadables' files
• being able to keep a list of changes
• could also be used as a semaphore, not allowing multiple builds at once

idk

The idea is that filenames would be written in server.toml and mcman would pull the said files from server/ to config/ if they were modified

For example:

[extra]
autopull = [
  "whitelist.json"
]

would this be a good idea?

Datapack projects can have mod versions ex: https://modrinth.com/datapack/tectonic

Also maybe just support for datapacks as a whole

I encountered this while trying to install and build the the lost era modpack.
If you try to run a 1.7.10 forge installer, it uses a wrong download url during the build step.
I get this error:
Error: HTTP status client error (404 Not Found) for url (https://maven.minecraftforge.net/net/minecraftforge/forge/1.7.10-10.13.4.1614/forge-1.7.10-10.13.4.1614-installer.jar)

The actual url is:
https://maven.minecraftforge.net/net/minecraftforge/forge/1.7.10-10.13.4.1614-1.7.10/forge-1.7.10-10.13.4.1614-1.7.10-installer.jar
so a -1.7.10 is missing.

Should actually work tbh idk needs to be tested if it works

Support for modrinth modpacks (.mrpack)

the code shouuld be in my dms somewhere, just needs some superglue :3

command would probably be mcman import mrpack <url | file>

If you use too many Downloadable::GithubRelease you might get rate limited...

Possible Solutions:

• Cache responses
• some GITHUB_TOKEN env variable for GitHub rest api bearer auth

current rate limit seems to be.. 60 req per... hour? which is very low damn

This new API would provide a way to manage installed java versions and handle which java binary to use on tasks (such as server installation and running the server)

This feature would also most likely add some commands:

• mcman java list
• mcman java add <path>
• mcman java install <version> [flavor]
• mcman java uninstall

I tried to run ncman --version, just to see it fail.

Just for the sake of correctness, I would propose:

1. mcman --version printing just the current version
2. mcman self-update updating mcman. However, that shouldn’t work when installed via some package manager, so I would propose to check if the executable is /usr/bin/mcman, and otherwise continue to self-update (just like rustup: rustup self update is disabled when installed via package manager).

EDIT: just had a look in the code and saw that mcman version doesn’t update mcman.
Cargo handles cargo --version and cargo version the same; I think it would be nice to do the same.

would use lockfile ( #19 ) to get the past versions of addons and compare, then make a list of changelogs

probably would create a txt file with markdown, or a special markdown template that appends to the contents

or maybe even use stdout which would be useful in scripts and such

Implement some commands for editing, removing or adding a new Downloadable to datapacks, plugins or mods.

I'm thinking of:

• mcman add <source> <query/id/term>
• mcman remove <query>

For example:

• mcman add modrinth create-fabric
• mcman add cr toomanyitems

add and remove would not immediately add anything, they would do a search and let the user pick from the results. This also makes removing different kinds of Downloadables easier and with less confusion.

editing

An edit command could be implemented which would be kind of like a terminal-ui, with a list of addons and remove/add buttons etc. This would be kinda tricky though...

things to consider

• an "all" source argument to search from multiple sources at once? might be a bad idea.
• Modrinth, Curserinth etc filtering needs to be improved

If you change the PORT in server.toml and run mcman build, it wont update an already existing server/server.properties file if .mcman.lock is present.

Command: mcman probe <jar>

Probes a jar file and shows info about what it is

• Forge mod - META-INF/mods.toml spec
• Quilt mod - quilt.mod.json spec
• Fabric mod - fabric.mod.json spec
• Plugins - plugin.yml paper spec / spigot spec
• Paper Plugins - paper-plugin.yml spec
• Datapacks - pack.mcmeta spec

And optionally try to find the source of it:

• Modrinth api => hash to project endpoint
• Various fields in metadata

Lets say theres a plugin named Banana

And lets also say Banana has a directory in */plugins/banana/assets which contain some "assets"

A special file of some sorts could be used in config/plugins/banana/assets/a.mcman.dl which would contain a Downloadable:

type = "url"
url = "..."

This would basically allow using downloadables in every directory and not only plugins/mods/datapacks

Maybe the file extension could be changed:

• .dl
• .dl.toml
• .mcman
• .mcman.toml

These are the few i got on my mind, idk

I'm thinking of this:

• a worlds/ folder with .zip files (or maybe .tar.gz)
• mcman world pack <name>
• mcman world unpack <name>

and also

# unsure about this one tbh
[worlds.plotworld.download]
type = "url"
url = "..."

On build, the worlds/ would be unpacked (unzipped) to server/ (output) if they dont exist.

This can happen servers which have a lobby/static world, or ones that want to preserve the updated worlds (?)

v0.4: The Rewrite

The 0.4 release will include tons of new features and improvements overall.

Current progress can be found under the source-rewrite branch

Summary

Here are some notable things:

• ⚡ 0.4 adds a new server/.mcman.lock file (called the lockfile) containing metadata about the last build. This file will be used (if it exists) to validate and skip files that do not need to be downloaded or bootstrapped again (making builds get a lot faster)
• 📦 0.4 also adds global caching - most downloaded files and useful metadata will be cached under these directories.
  • Windows: %localappdata%/mcman
  • Linux: ~/.cache/mcman (most likely)
• Github rate limiting should be fixed! I mean unless you have like a billion ghrel's. Because of the caching system, metadata from GitHub get cached. mcman can use this metadata to send conditional requests which do not count towards the rate limit.
• 🔒 File hash checksums are also implemented, meaning more secure and stable downloads. (Yes, cached files also get checked)
• 📜 Visual overhaul: mcman's got a new look. There are now progress bars and spinners everywhere, and its more consistent overall.
• ☔ Hot reloading with development sessions, you can develop your server without having to build it every time you change something!
• 🌐 Worlds You can now download (in server.toml) and store (worlds/) worlds!
• ☕ Java environment variables You can now set the java version to use (server.toml) and mcman will use JAVA_*_BIN variables to find and use the java with the version
• ✨ Networks Have multiple servers? network.toml is now here! Have common addons, common configs and variables! It can also help you manage port configurations with special variables like ${NETWORK_VELOCITY_SERVERS}
• 📎 mclo.gs mcman run and mcman dev can auto-upload logs to mclo.gs

Progress

• Internal common file resolving
• File Checksums
  • Download
  • Copy from Cache
• Retry mechanism
• #19
  • Lockfile-based building
    • Skip more downloadables easily
    • [x]
    • Bootstrap only changed files
• #13
• Local (global) caching
  • Downloaded files
  • Metadata
    • GitHub
  • mcman cache command
    • mcman cache open
    • mcman cache list
    • mcman cache clear
• #27
• #3
  • using env GITHUB_TOKEN
  • cache api will also help
• refactor basically everything
• Maven Downloadable
• Refactor Jenkins API
• Forge, NeoForge, etc.
• Hangar Downloadable
• #7
• #26
  • Build step
    • Download
    • Unpack
  • mcman world unpack
  • mcman world pack
  • impl .gitattributes
• Some global flags if possible
  • --no-cache
  • -v <prop>=<value> or --var <prop>=<value>
  • --skip-md and --render-md
  • --dry (do not save files)
• mcman print <var> could be useful for scripts
• maybe, just maybe, json output

:3

The following reproduces the error on mcman 0.4.4:

TMPDIR=$(mktemp -d)
cd $TMPDIR
echo "Changing to $TMPDIR"
mcman init
cat <<EOF >> "$TMPDIR/server.toml"

[[plugins]]
type = "modrinth"
id = "dynmap"
version = "5F9fwzR1"
EOF
cat "$TMPDIR/server.toml"

mcman md

And the error is:

Caused by:
    0: error decoding response body: unknown variant `unknown`, expected one of `required`, `optional`, `incompatible`, `embedded`, `unsupported` at line 1 column 24
    1: unknown variant `unknown`, expected one of `required`, `optional`, `incompatible`, `embedded`, `unsupported` at line 1 column 24

Support for packwiz using most likely rpackwiz

TODO

• structs
• import from a packwiz pack
• clientside mods in server.toml
• packwiz export (clientside)

I mean, I think it could make the code in most places better and less clumped.

We could still support the "base sources" like so:

pub struct ServerType {
  Vanilla,
  Paper { build },
  Other(Downloadable)
}

title is self explanatory. should be easy because i think its similar to mrpacks - a zip file with metadata etc

I'm thinking either we include this in server.launcher or a file like this:

echo Starting server
${command}
echo ended

If we do include it in the ServerLauncher, we should add 3 versions: platform independent, windows and linux

Trying to use a type = "vanilla" [jar] section with mc_version = "1.12.2" leads to the following error on running mcman build:

Error: Resolving Vanilla

Caused by:
    0: error decoding response body: missing field `name` at line 1 column 11698
    1: missing field `name` at line 1 column 11698

I've gotten around this by instead using:

[jar]
type = "url"
url = "https://piston-data.mojang.com/v1/objects/886945bfb2b978778c3a0288fd7fab09d315b25f/server.jar"

Which works, but also means that I have to manually edit the EULA file before starting the server.

It's nice that the system is flexible enough to support this fix, but the whole situation leads to two things:

• This bug report (of the issue with vanilla servers)
• A feature request: custom build hooks (I could add a hook that simply performs echo "eula=true" > eula.txt

Add support for maven which would allow forge and neoforged (probably)

This should be easy because from what ive seen maven sources have some sort of maven-metadata.xml which list the releases

• maven for neoforged

I've almost perfected the modrinth project version selector/filterer for mcman add modrinth and it could be re-used for this.

this wasnt possible because modrinth versions are a bit complicated

• ignore game_versions on proxy servers
• sort by loaders (datapacks etc!)

this means.. more arguments for source::modrinth::*!...

• actually it would be a good idea to just server: &Server...

add the hangar api

maybe the file watcher is broken idk

Im thinking of mcman download|dl <type> <args..>

no server.toml - just download a downloadable to current directory

you could use the path to an existing modded profile, to create a server from it
mcman would detect the modloader and mc version and copy all the non client-side mods over.

When getting rate limited, mcman seems to pick a very very large number of seconds to sleep. While I can work around this by just using a token, it seems this is not ideal behavior.

also credit oatmealine and IogaMaster

should be a simple fix

the problem with this one is that quilt servers for some reason 100% require some libraries in libraries/ folder. also quilt doesnt provide direct links to download a single server jar

current plan is to

1. download quilt-installer
2. run quilt-installer to install server in build stage 1 after downloading server jar (which is quilt-installer in this case...)

On ModFest 1.20's CI, there have been a lot of inconsistent errors involving modrinth mods

Example runs:

• mcman test
• mcman export packwiz

524 means a timeout... is modrinth ok?

Most addons could be downloaded but some are compiled. This proposal (that will require a lot of code change) will allow there to be more complex addons.

The idea is that a Downloadable, instead of returning a ResolvedFile, will return Vec<Step>

pub enum Step {
  Download(ResolvedFile),
  Execute(...),
  Compile(...),
}

a better support for proxy networks (velocity, waterfall, bungeecord)

folder structure would look something like this:

• network.toml
  • proxy/
    • server.toml
  • lobby/
    • server.toml
  • survival/
    • server.toml
  • creative/
    • server.toml

network.toml

name = "Cool Ass Server:tm"
proxy = "proxy" # folder/server name
port = "25565"

[servers.lobby]
port = 25566
# ...
[servers.creative]
port = 25567
# ...etc

[variables]
some_var = "1"
# exported as "nw_some_var" or "network_some_var"

[[groups.games.plugins]]
# downloadable

groups

servers would be able to be grouped and every group would have its own "preset" plugins/mods and config files.

special variables

NW_VELOCITY_SERVERS

[servers]
lobby = "25566"
creative = "25567"

NW_PROXY_SERVERS

servers:
  lobby:
    motd: '&1Just another BungeeCord - Forced Host'
    address: localhost:25565
    restricted: false

smth like that idk

Hi,

I wrote a hook to move some addons inside the right folder when the test succeeds.
Even though it says that the test passed, my hook is not run.

The postbuild hook works perfectly fine.

I use mcman version 0.4.4

Here the hook inside the server.toml:

[hooks.move-bentobox-addons-in]
linux = "move-bentobox-addons-in.sh"
windows = "move-bentobox-addons-in.bat"
when = "testsuccess"
onfail = "Error"
output = "hide"
description = "Move all BentoBox's addons to the BentoBox's \"addons\" folder"

Is my hook correct?

Add more env commands, such as velocity, luckperms, etc.

Might also add mc-modpack-kit after ParadigmMC/mc-modpack-kit#48

might also also add a multiselect to mcman init with the env options