Compiling Instructions?

[alexguzman]

It would be nice if there were a script or at least a set of instructions for compiling this pack so people can help test the latest commits.

I guess the part that isn't very intuitive is the location of the regular Minecraft textures, and what takes precedence – especially now that there is a “Legacy” edition that I'm assuming has a different compiling procedure.

Just a thought.

[damonmensch]

One thing most people don't realize is a resource pack doesn't have to be
in a zip file for Minecraft to be able to use it. It's been that way since
as early as beta 1.3.

All you need to do is download the files and put them in this new folder
with a properties folder. I just use the one from the pack's zip downloaded
from the site.

Now don't put each of these files in there, what you need to put in there
is the "assets" folders in those folders. Then add this new resource pack
folder you made to the active packs and there you have it.
On Jan 25, 2015 6:57 PM, "Alex Guzman" notifications@github.com wrote:

It would be nice if there where a script or at least a set of instructions
for compiling this pack so people can help test the latest commits.

I guess the part that isn't very intuitive is the location of the regular
Minecraft textures, and what takes precedence – especially now that there
is a “Legacy” edition that I'm assuming has a different compiling procedure.

Just a thought.

—
Reply to this email directly or view it on GitHub
#59.

[alexguzman]

Yes, I know you can put the raw assets folders in there and manually piece it together.

This repository doesn't seem to have all the vanilla assets, and I'm not quite sure where they're at. And with the most recent changes to the metals/ores I wouldn't know if the DL on the JSLegacy website for the vanilla textures are necessarily the ones used to create this finished pack.

I was asking merely because the procedure is probably already fleshed out (and most likely at least partially automated) by one of the main devs (@goldbattle ?) so having them add it to the README would be helpful when the website lags behind, or you want to test a custom branch without pushing/merging.

EDIT:

Saying this, it seems that some files are located here: http://github.com/John-Smith-Modded/JSTR-Overwrites

[goldbattle]

Right now I have a script that I use to compile the script. I have a
"modded vanilla" pack that I hand create to be the base pack. It is
composed of textures from the overwrite repo and a base vanilla pack. I
have to take out a lot of ctm etc to make it work for modded clients. Last
time I checked it was the latest 1.7.x vanilla pack that jimstonecraft has
created. Not positive on that. What the script does is it loops through
each folder and is overlapped on top of the base vanilla pack. For the
legacy pack I just have the script simply zip up the legacy folder into its
own pack. It is a modified soartex script so I can't publicly share it.

Now the way that the system is suppose to work, is the folders provide the
structure. For example I never have more then maybe 5 modded folders copied
into my minecraft instance. I just copy in the textures from the folder,
test it, and then go from there. The point of having the textures under git
control is to allow for people to push ideas or textures that they want
others to see. Once I have textures created I copy them into my github
folder and push it upstream. So basically a short answer is I don't have a
way for people to create test packs. At soartex, we usually just take a
look over the textures in the commit, and copy them into our game instance
if needed.

On Mon, Jan 26, 2015 at 12:41 AM, Alex Guzman notifications@github.com
wrote:

Yes, I know you can put the raw assets folders in there and manually piece
it together.

This repository doesn't seem to have all the vanilla assets, and I'm not
quite sure where they're at. And with the most recent changes to the
metals/ores I wouldn't know if the DL on the JSLegacy website for the
vanilla textures are necessarily the ones used to create this finished pack.

I was asking merely because the procedure is probably already fleshed out
(and most likely at least partially automated) by one of the main devs (
@goldbattle https://github.com/goldbattle ?) so having them add it to
the README would be helpful when the website lags behind, or you want to
test a custom branch without pushing/merging.

—
Reply to this email directly or view it on GitHub
#59 (comment)
.

Patrick Geneva | Administrator | pgb@soartex.net

[goldbattle]

I'll see if I can whip something up, but a bit busy at the moment with in
real life stuff. Feel free to ask any more questions.

On Mon, Jan 26, 2015 at 1:25 AM, Patrick Geneva pgb@soartex.net wrote:

Right now I have a script that I use to compile the script. I have a
"modded vanilla" pack that I hand create to be the base pack. It is
composed of textures from the overwrite repo and a base vanilla pack. I
have to take out a lot of ctm etc to make it work for modded clients. Last
time I checked it was the latest 1.7.x vanilla pack that jimstonecraft has
created. Not positive on that. What the script does is it loops through
each folder and is overlapped on top of the base vanilla pack. For the
legacy pack I just have the script simply zip up the legacy folder into its
own pack. It is a modified soartex script so I can't publicly share it.

Now the way that the system is suppose to work, is the folders provide the
structure. For example I never have more then maybe 5 modded folders copied
into my minecraft instance. I just copy in the textures from the folder,
test it, and then go from there. The point of having the textures under git
control is to allow for people to push ideas or textures that they want
others to see. Once I have textures created I copy them into my github
folder and push it upstream. So basically a short answer is I don't have a
way for people to create test packs. At soartex, we usually just take a
look over the textures in the commit, and copy them into our game instance
if needed.

On Mon, Jan 26, 2015 at 12:41 AM, Alex Guzman notifications@github.com
wrote:

Yes, I know you can put the raw assets folders in there and manually
piece it together.

This repository doesn't seem to have all the vanilla assets, and I'm not
quite sure where they're at. And with the most recent changes to the
metals/ores I wouldn't know if the DL on the JSLegacy website for the
vanilla textures are necessarily the ones used to create this finished pack.

I was asking merely because the procedure is probably already fleshed out
(and most likely at least partially automated) by one of the main devs (
@goldbattle https://github.com/goldbattle ?) so having them add it to
the README would be helpful when the website lags behind, or you want to
test a custom branch without pushing/merging.

—
Reply to this email directly or view it on GitHub
#59 (comment)
.

Patrick Geneva | Administrator | pgb@soartex.net

Patrick Geneva | Administrator | pgb@soartex.net

[Greenhawk837]

In the meantime what I do is open up the JSTR 1-7.x folder and then search 'assets' into the search bar. Then copy all of the assets folders into my vanilla pack, and its ready to use. Doesn't take long at all.

For the vanilla pack you could just download it from JimStoneCraft's website and then copy the files from the overwrites repo over the top.

[alexguzman]

If I have some spare time later, I could write up a quick script but I've been doing what @Greenhawk837 has been doing in the meantime.

The cmt thing brings up another question, how does this resource pack handle mcpatcher vs optifine? Because for modded minecraft launchers, mcpatcher no longer seems to work (atlauncher, technic, ftb) – or at least it's very difficult to do so. Many of the devs on the forums will simply tell you to use optifine instead for better texture support.

Unless, if one of you knows how to bundle mcpatcher into a modpack compatible with these launchers, that would be great.

[alexguzman]

It seems one reason for the existence of the other repo was for better optifine/mcpatcher support... #3

On the note about getting mcpatcher to work with mods, anyone here know if it's possible to bundle mcpatcher's changes into a jar. That would probably do the trick with the modded launchers.

But in all honesty, is there really much of a difference between the 1.7.10 optifine and mcpatcher?

[damonmensch]

my 1.7.10 Optifine actually uses the mcpatcher files in the pack's zip. And correctly I might add.