Jump to content

Forge 804 install http 403 forbidden error [RESOLVED]


Satscape

Recommended Posts

*UPDATE* Just double clicked the 804 install again, all working again..Thanks whoever it was who applied a redstone signal to the webserver, that fixed it!  :D

---------------------------------------------------

 

Doing a fresh install of Forge 804 today, double click the install.bat and I get this, tried 800, gonna keep going back just in case one of them works...but thought I'd let you know.

 

Fixing MCP Workspace
Traceback (most recent call last):
  File "install.py", line 76, in <module>
    decompile=options.decompile, gen_conf=False)
  File "install.py", line 17, in fml_main
    disable_assets=disable_assets)
  File "S:\Java Source code\forge\fml\fml.py", line 1013, in decompile_minecraft

    pre_decompile(mcp_dir, fml_dir, disable_assets=disable_assets)
  File "S:\Java Source code\forge\fml\fml.py", line 1061, in pre_decompile
    download_minecraft(mcp_dir, fml_dir)
  File "S:\Java Source code\forge\fml\fml.py", line 1125, in download_minecraft
    failed = download_libraries(mcp_dir, version_json['libraries'], mc_info['nat
ives_dir']) or failed
  File "S:\Java Source code\forge\fml\fml.py", line 1181, in download_libraries
    headers = get_headers(url)
  File "S:\Java Source code\forge\fml\fml.py", line 173, in get_headers
    response = urllib2.urlopen(HeadRequest(url))
  File "urllib2.pyc", line 126, in urlopen
  File "urllib2.pyc", line 406, in open
  File "urllib2.pyc", line 519, in http_response
  File "urllib2.pyc", line 444, in error
  File "urllib2.pyc", line 378, in _call_chain
  File "urllib2.pyc", line 527, in http_error_default
urllib2.HTTPError: HTTP Error 403: Forbidden

Link to comment
Share on other sites

  • 4 months later...

have now the same problem, linux mint 16 64bit

 

deekay@stand-pc ~/Downloads/forge $ ./install.sh 
================ Forge ModLoader Setup Start ===================
MCP Detected already, not downloading
Setting up MCP
Patching commands.py
patching file commands.py
    Commands patch applied successfully
Copying FML conf
Creating Repackaged data
    Creating re-packaged srg
    Creating re-packaged exc
    Creating re-packaged MCP patches
Traceback (most recent call last):
  File "install.py", line 76, in <module>
    decompile=options.decompile, gen_conf=False)
  File "install.py", line 17, in fml_main
    disable_assets=disable_assets)
  File "/home/deekay/Downloads/forge/fml/fml.py", line 1013, in decompile_minecraft
    pre_decompile(mcp_dir, fml_dir, disable_assets=disable_assets)
  File "/home/deekay/Downloads/forge/fml/fml.py", line 1061, in pre_decompile
    download_minecraft(mcp_dir, fml_dir)
  File "/home/deekay/Downloads/forge/fml/fml.py", line 1125, in download_minecraft
    failed = download_libraries(mcp_dir, version_json['libraries'], mc_info['natives_dir']) or failed
  File "/home/deekay/Downloads/forge/fml/fml.py", line 1181, in download_libraries
    headers = get_headers(url)
  File "/home/deekay/Downloads/forge/fml/fml.py", line 173, in get_headers
    response = urllib2.urlopen(HeadRequest(url))
  File "/usr/lib/python2.7/urllib2.py", line 127, in urlopen
    return _opener.open(url, data, timeout)
  File "/usr/lib/python2.7/urllib2.py", line 410, in open
    response = meth(req, response)
  File "/usr/lib/python2.7/urllib2.py", line 523, in http_response
    'http', request, response, code, msg, hdrs)
  File "/usr/lib/python2.7/urllib2.py", line 448, in error
    return self._call_chain(*args)
  File "/usr/lib/python2.7/urllib2.py", line 382, in _call_chain
    result = func(*args)
  File "/usr/lib/python2.7/urllib2.py", line 531, in http_error_default
    raise HTTPError(req.get_full_url(), code, msg, hdrs, fp)
urllib2.HTTPError: HTTP Error 403: Forbidden

Link to comment
Share on other sites

The resources will need to be updated as they changed the format on the server entirely.

However, you guys should update to the gradle as that's the future, and we're not gunna update anything that's old.

The new Gradle system allows us to update things like this on our end and you devs gets the changes automatically.

I do Forge for free, however the servers to run it arn't free, so anything is appreciated.
Consider supporting the team on Patreon

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Announcements



  • Recently Browsing

    • No registered users viewing this page.
  • Posts

    • I am not using hardcoded recipes, I'm using Vanilla's already existing code for leather armor dying. (via extending and implementing DyeableArmorItem / DyeableLeatherItem respectively) I have actually figured out that it's something to do with registering item colors to the ItemColors instance, but I'm trying to figure out where exactly in my mod's code I would be placing a call to the required event handler. Unfortunately the tutorial is criminally undescriptive. The most I've found is that it has to be done during client initialization. I'm currently trying to do the necessary setup via hijacking the item registry since trying to modify the item classes directly (via using SubscribeEvent in the item's constructor didn't work. Class so far: // mrrp mrow - mcmod item painter v1.0 - catzrule ch package catzadvitems.init; import net.minecraft.client.color.item.ItemColors; import net.minecraft.world.item.Item; import net.minecraftforge.registries.ObjectHolder; import net.minecraftforge.fml.event.lifecycle.FMLClientSetupEvent; import net.minecraftforge.fml.common.Mod; import net.minecraftforge.eventbus.api.SubscribeEvent; import net.minecraftforge.client.event.ColorHandlerEvent; import catzadvitems.item.DyeableWoolArmorItem; @Mod.EventBusSubscriber(bus = Mod.EventBusSubscriber.Bus.MOD) public class Painter { @ObjectHolder("cai:dyeable_wool_chestplate") public static final Item W_CHEST = null; @ObjectHolder("cai:dyeable_wool_leggings") public static final Item W_LEGS = null; @ObjectHolder("cai:dyeable_wool_boots") public static final Item W_SOCKS = null; public Painter() { // left blank, idk if forge throws a fit if constructors are missing, not taking the chance of it happening. } @SubscribeEvent public static void init(FMLClientSetupEvent event) { new Painter(); } @Mod.EventBusSubscriber private static class ForgeBusEvents { @SubscribeEvent public static void registerItemColors(ColorHandlerEvent.Item event) { ItemColors col = event.getItemColors(); col.register(DyeableUnderArmorItem::getItemDyedColor, W_CHEST, W_LEGS, W_SOCKS); //placeholder for other dye-able items here later.. } } } (for those wondering, i couldn't think of a creative wool helmet name)
    • nvm found out it was because i had create h and not f
    • Maybe there's something happening in the 'leather armor + dye' recipe itself that would be updating the held item texture?
    • @SubscribeEvent public static void onRenderPlayer(RenderPlayerEvent.Pre e) { e.setCanceled(true); model.renderToBuffer(e.getPoseStack(), pBuffer, e.getPackedLight(), 0f, 0f, 0f, 0f, 0f); //ToaPlayerRenderer.render(); } Since getting the render method from a separate class is proving to be bit of a brick wall for me (but seems to be the solution in older versions of minecraft/forge) I've decided to try and pursue using the renderToBuffer method directly from the model itself. I've tried this route before but can't figure out what variables to feed it for the vertexConsumer and still can't seem to figure it out; if this is even a path to pursue.  The vanilla model files do not include any form of render methods, and seem to be fully constructed from their layer definitions? Their renderer files seem to take their layers which are used by the render method in the vanilla MobRenderer class. But for modded entities we @Override this function and don't have to feed the method variables because of that? I assume that the render method in the extended renderer takes the layer definitions from the renderer classes which take those from the model files. Or maybe instead of trying to use a render method I should be calling the super from the renderer like   new ToaPlayerRenderer(context, false); Except I'm not sure what I would provide for context? There's a context method in the vanilla EntityRendererProvider class which doesn't look especially helpful. I've been trying something like <e.getEntity(), model<e.getEntity()>> since that generally seems to be what is provided to the renderers for context, but I don't know if it's THE context I'm looking for? Especially since the method being called doesn't want to take this or variations of this.   In short; I feel like I'm super super close but I have to be missing something obvious? Maybe this insane inane ramble post will provide some insight into this puzzle?
  • Topics

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.