When you are using Minecraft forge, it creates an external /mods/ folder that you place your mods in. Is there a way to package all the mods, configuration settings (like splash.propreties) and assets into a single .jar file for ease of distribution?
I am making a custom mod pack, and I don't like the fact that you have to install forge, then download the mod pack, then install the mods in order to run my mod pack. Is there a way to package it into a single jar so that you can just add it as a profile in the launcher and not have to do anything else?
I also need to be able to modify configuration files like splash.propreties, and I would like these to be packaged into the jar as well.
Note: I do not want to use premade launchers like Twitch or Technic.
I'm not aware of a way to package all of your mods into a single jar; there is such thing as a 'fat jar', but it's not what you're after. StackOverflow is intended more for code so you might find some more helpful advice over on the Forge forums.
That being said, you could utilise a Self Extracting Archive (SFX) such as IExpress or 7zip to package all of your mods into one, compressed, file which when executed can extract the mods into the right place. As for having one profile, as I'm sure you're aware, within your /mods directory, you can have another directory for profile-specific mods. So you could have your mods extract to a /mods/modpackname/... directory. Forge doesn't have great documentation but this writeup explains the process step by step.
Hope that helps
Related
When developing packages in R all R source files are put in the subdirectory R/, and all compiled code is put in the subdirectory src/.
I would like to add some organisation to files within these folders, rather than have everything dumped at the top level. For example, lets say I'm hypothetically developing a client-server application. Logically, I would like to organise all my client R source files in R/client/ and all my server R source files in R/server/.
Is it possible to organise code in subfolders when developing a package, and if so, how? The Writing R Extensions manual doesn't offer any guidance, nor does R CMD build detect files stored in subfolders under R/.
You can't use subfolders without additional setup (like defining a custom makefile). The best you can do is to use prefixes: client-a.r, client-b.r, server-a.r, server-b.r, etc.
Expanding the comment to Hadley's IMHO incorrect answer:
Look at the Matrix package (written by R Core members) which has five folders below src/, and two of these contain other subfolders. Other example is the Rsymphony packages (co-)written and maintained by an R Core member.
Doing this is not for the faint of heart. R strongly prefers a src/Makevars fragment over a full src/Makefile in order to be able to construct its own Makefile versions for the different subarchitectures. But if you know a little make and are willing to put the effort in, this is entirely doable -- and being done.
That still does not make it recommended though.
I argued with R core team Allow for sub-folders in "package/R/" directory . They seem not really want improve it. So my workflow is as follows.
1) Create an R project same as other packages but allow sub-directories in folder R/ such as
R/mcmc/a.R
R/mcmc/b.R
R/prediction/p1.R
R/predection/p2.R
2) When I need to pack them, I convert all files under R/ as
R/mcmc_a.R
R/mcmc_b.R
R/prediction_p1.R
R/predection_p2.R
...
with my package.flatten() function
3) Then I install the flattened version to R.
I wrote a simple script for Linux to do everything
https://github.com/feng-li/flutils/blob/master/inst/bin/install.HS
Recognizing the thread is a bit old, I just thought I'd throw in my solution to this problem. Note that my issue is similar, but I am only concerned with preserving folder hierarchies in development.
In development, I organize my script files in subfolders to my heart's content, but rather than fight R's flat hierarchy in production, I added my own "compile-time constant", so to speak.
That is, in every file located in a subfolder (not in top-level scripts/), I add the following:
if (!exists("script.debug"))
script.debug = FALSE
Then, I load whatever other dependencies are required as follows:
source.list <- c(
"script_1.R",
"script_2.R",
"script_3.R",
"script_4.R"
)
if (script.debug)
source.list <- paste("./script_subfolder/", source.list, sep="")
lapply(source.list, source)
The default assumption is that the code is in production, (source.debug = FALSE), so when in development, just ensure that source.debug = TRUE and the project's script/ folder is set as the working directory before loading any script files.
Of course, this example's a bit simple - it assumes that all script file dependencies exist in the same folder, but it seems a simple issue to devise a system that would suit more complicated development folder hierarchies.
I have a .tar.gz file of a MeteorJS application. This file was created using this command "meteor build --architecture=os.linux.x86_64 ./". I don't have original source code of this app because the author dev disappeared totally. Now I want to convert the .tar.gz file to a normal MeteorJS source code to add some changes (add third-party packages ...). So is there any way to do this? If not, is there any way to add new third-party packages to the app? Thank you in advance!
I think you probably can reconstruct it.
Looking at one of my projects, under
bundle/programs/server/app/app.js
This file is a concatenation of my source files. You could probably write a script to unpack this into separate files. I don't know if anyone has done it before, but it might be useful to post the tool when you have built it.
I install all 3rd party apps in "/opt" which I need to install manually i.e without any package manager.
So to use all those manually installed apps from TERMINAL I need to add them in PATH variable.
But I find that PATH variable should not be longer otherwise it can make system slower, very negligible but it will. So I added symlinks of the executables in a path which is already added in PATH variable like "/usr/bin".
My question is I didn't find any side effects of this technique, it's working well.
But I want to know if there will be any problem later by doing this. As far I know "/usr/bin", "/bin", "/sbin" this folders are managed by package managers. So will it make any problem to package managers by adding symlinks like this?
That would only confuse package managers if the packages might use those same pathnames. There are a few drawbacks to the symlink approach:
you have to maintain the links (and remember to remove broken links if you remove the packages which they correspond to).
occasionally you will encounter a package which is run via a shell script that checks to see where it is run from (such as the symbolic link in /usr/bin) and then assumes that all of its other parts are available on the same path (again /usr/bin). If that extends into sibling directories such as /usr/lib, it can be tedious to manage the links.
One way to deal with the links would be to make a meta-package of your own which installs the packages and adds your own post-install/uninstall rules to maintain the links.
I'm trying to write my first Qt installer and having trouble. In my installer, in one of the packages, I need to run an .exe file at the end of the installation and add an environment variable as well.
I think the way to do it is with the script option in the package.xml file but I don't know how to write that script, I cannot find a step by step explanation of how to do it anywhere.
Can someone help?
I have been recently suffering the same fate as yourself but have managed, for the most part, to achieve what you are trying to do from the Qt installer framework examples and documentation found here http://qt-project.org/doc/qtinstallerframework-1.5/index.html and http://doc.qt.io/qtinstallerframework/qtifwexamples.html.
The information provided on these pages is a little ambiguous but with a little experimentation you should be able to create the install script that you require.
The package.xml file you would like to implement the install script requires that you add a
<Script>installscript.qs</Script>
tag and that the installscript.qs its self should be located in the meta folder of that package. The installscript.qs will then contain, among a few other things, a
component.addOperation("Execute".....)
command which will execute your required .exe. The same process for the environment variable could be implemented using the execute operation to run a batch file which creates the variable on the users system.
I have been trying over the last few weeks to implement the custom operations detailed in the qt installer framework documentation but have so far been unsuccessful so if you make any progress in this area feel free to pass the information on ;)
When developing packages in R all R source files are put in the subdirectory R/, and all compiled code is put in the subdirectory src/.
I would like to add some organisation to files within these folders, rather than have everything dumped at the top level. For example, lets say I'm hypothetically developing a client-server application. Logically, I would like to organise all my client R source files in R/client/ and all my server R source files in R/server/.
Is it possible to organise code in subfolders when developing a package, and if so, how? The Writing R Extensions manual doesn't offer any guidance, nor does R CMD build detect files stored in subfolders under R/.
You can't use subfolders without additional setup (like defining a custom makefile). The best you can do is to use prefixes: client-a.r, client-b.r, server-a.r, server-b.r, etc.
Expanding the comment to Hadley's IMHO incorrect answer:
Look at the Matrix package (written by R Core members) which has five folders below src/, and two of these contain other subfolders. Other example is the Rsymphony packages (co-)written and maintained by an R Core member.
Doing this is not for the faint of heart. R strongly prefers a src/Makevars fragment over a full src/Makefile in order to be able to construct its own Makefile versions for the different subarchitectures. But if you know a little make and are willing to put the effort in, this is entirely doable -- and being done.
That still does not make it recommended though.
I argued with R core team Allow for sub-folders in "package/R/" directory . They seem not really want improve it. So my workflow is as follows.
1) Create an R project same as other packages but allow sub-directories in folder R/ such as
R/mcmc/a.R
R/mcmc/b.R
R/prediction/p1.R
R/predection/p2.R
2) When I need to pack them, I convert all files under R/ as
R/mcmc_a.R
R/mcmc_b.R
R/prediction_p1.R
R/predection_p2.R
...
with my package.flatten() function
3) Then I install the flattened version to R.
I wrote a simple script for Linux to do everything
https://github.com/feng-li/flutils/blob/master/inst/bin/install.HS
Recognizing the thread is a bit old, I just thought I'd throw in my solution to this problem. Note that my issue is similar, but I am only concerned with preserving folder hierarchies in development.
In development, I organize my script files in subfolders to my heart's content, but rather than fight R's flat hierarchy in production, I added my own "compile-time constant", so to speak.
That is, in every file located in a subfolder (not in top-level scripts/), I add the following:
if (!exists("script.debug"))
script.debug = FALSE
Then, I load whatever other dependencies are required as follows:
source.list <- c(
"script_1.R",
"script_2.R",
"script_3.R",
"script_4.R"
)
if (script.debug)
source.list <- paste("./script_subfolder/", source.list, sep="")
lapply(source.list, source)
The default assumption is that the code is in production, (source.debug = FALSE), so when in development, just ensure that source.debug = TRUE and the project's script/ folder is set as the working directory before loading any script files.
Of course, this example's a bit simple - it assumes that all script file dependencies exist in the same folder, but it seems a simple issue to devise a system that would suit more complicated development folder hierarchies.