Well, this doesn't seem right. I took the screenshot the correct way, but this is what it gave me.
I'm running Minecraft 1.3.2 on Ubuntu 12.04 LTS (64-bit) using OpenJDK 7. I have the 1.3.2 version of the mod, and the only other mods I have installed are Forge, Modloader, SPC, Opti-Fine, Minema, and CameraStudio, all up-to-date and there were no error messages.
Well, this doesn't seem right. I took the screenshot the correct way, but this is what it gave me.
I'm running Minecraft 1.3.2 on Ubuntu 12.04 LTS (64-bit) using OpenJDK 7. I have the 1.3.2 version of the mod, and the only other mods I have installed are Forge, Modloader, SPC, Opti-Fine, Minema, and CameraStudio, all up-to-date and there were no error messages.
Hm, that's weird. Obviously, the camera modifications are ignored for some reason, so the normal view is simply repeated on all tiles. Since there's no error message, it's hard to find out the reason for that...
The mods alone shouldn't be a problem, since I'm using heuristic reflection to find and modify the fields that are used to set the camera zoom and offset. Unless they're completely removed, of course.
Just updated to the 1.5 ModLoader release which as things most expectantly go, broke your mod. Any idea on when a 1.5 ModLoader compatible release will become available? Thanks!
1.5.1 unofficial (by me)
Compiled (for users): http://ge.tt/9lzBpDd/v/0?c
Source (for devs) http://ge.tt/6LwMpDd/v/0?c
Hint to BarracudaATA: change all instances of controlList in GuiScreenSettings.java to buttonList.
Okay, I just released Mineshot 1.4 for Minecraft 1.5.1, which now supports orthographic projection. The code for that was mostly finished for some time and I already used it for many images on the Minecraft Wiki, but it required modifications on a vanilla class. This is no longer required thanks to an internal change in Minecraft, so I included the code in Mineshot.
Here's a small example gallery that demonstrates what is now possible using just Minecraft, Forge and Mineshot: http://imgur.com/a/1sSNW
1.5.1 unofficial (by me)
Compiled (for users): http://ge.tt/9lzBpDd/v/0?c
Source (for devs) http://ge.tt/6LwMpDd/v/0?c
Hint to BarracudaATA: change all instances of controlList in GuiScreenSettings.java to buttonList.
Thanks, that bridged the time for the update. Since 1.4 requires Forge now, I'll add yours on the first page.
sadly mineshot breaks the Macro /Keybinding Mod which is changing the control settings gui and also adding a new control overview (and ofc a lot of macro features).
I have the newest version of both mods and the #659 version of Forge.
May you change the way you implemented the mineshot keys to a Macro/Keybinding Mod compatible way, please?
(other mods that add new keys works fine with the Macro mod)
He should be doing the EXACT same thing with the keybindings of everything else. No idea what hacks the macro/keybinding mod uses to do what it does, so it's probably the weird hacks that the keybinding mod does, and has nothing to do with mineshot.
Is there anything you could do about that pls, Barracuda?
I don't think so. I hoped nobody else uses that hooking method and I don't plan to use liteloader, since most of its functionality is already integrated into Forge. The only realistic chance is that the profiler hooking finds its way into the Forge code base so multiple mods can use it.
I understand that you don't like to use another loader, but can't you just hook into an other way / does Forge has no functionality for that?
There's no other way other than to modify Minecraft's classes directly, which is very ugly and causes just more compatibility issues. The isometric mode requires it to run special OpenGL commands at the right time to override the camera projection mode.
But I could add a config value to disable the hooks. This would also disable the isometric camera when enabled, but at least other mods won't break.
There's no other way other than to modify Minecraft's classes directly, which is very ugly and causes just more compatibility issues. The isometric mode requires it to run special OpenGL commands at the right time to override the camera projection mode.
But I could add a config value to disable the hooks. This would also disable the isometric camera when enabled, but at least other mods won't break.
If you did this I could also provide a LiteMod which could call the relevant function in your mod at the right point in order to preserve the isometric rendering. I strongly suspect that one of the hooks in either my RenderListener or PostRenderListener interfaces would do the job. In fact all your mod would need to do to get these callbacks itself would be to call (using reflection if you don't want to create a dependency) LiteLoader.addRenderListener() passing itself as an argument.
Just a thought. To clarify, the main reason LiteLoader uses the profiler hooking method is to steer clear of things like Forge and ModLoader which don't touch it, to allow forge mods and litemods to exist side by side. Because of this it is safe to have forge mods also use liteloader callbacks because the two loaders shouldn't interfere with one another.
At any rate, it should be possible to not conflict with LiteLoader without having to create a separate version which depends on it, aside from importing 2 interfaces. I'm fastidious about not altering the interfaces once published so it's safe for you to copy the interfaces as-is directly into your workspace without fear that they might change in the future.
Obviously this may all seem like too much of a hassle for you, and that's a fair comment, just thought I'd at least chip in to mention this in case it's of use to you.
If you did this I could also provide a LiteMod which could call the relevant function in your mod at the right point in order to preserve the isometric rendering. I strongly suspect that one of the hooks in either my RenderListener or PostRenderListener interfaces would do the job. In fact all your mod would need to do to get these callbacks itself would be to call (using reflection if you don't want to create a dependency) LiteLoader.addRenderListener() passing itself as an argument.
Just a thought. To clarify, the main reason LiteLoader uses the profiler hooking method is to steer clear of things like Forge and ModLoader which don't touch it, to allow forge mods and litemods to exist side by side. Because of this it is safe to have forge mods also use liteloader callbacks because the two loaders shouldn't interfere with one another.
At any rate, it should be possible to not conflict with LiteLoader without having to create a separate version which depends on it, aside from importing 2 interfaces. I'm fastidious about not altering the interfaces once published so it's safe for you to copy the interfaces as-is directly into your workspace without fear that they might change in the future.
Obviously this may all seem like too much of a hassle for you, and that's a fair comment, just thought I'd at least chip in to mention this in case it's of use to you.
Well, I fixed it in 1.41 by using the previously defined profiler instance as a proxy when it's using an extended non-vanilla profiler class. It produces slightly more overhead this way, but it seems to work. Don't get me wrong, I'm not trying to avoid LiteLoader at all costs, but the current solution should also support other mods or APIs that override the profiler via reflection, in case any exists or will ever exist. Of course, there's no 100% guarantee, but it seems that you can never be completely sure when developing software.
How does this work? Does it take a larger image and then shrink to your set size?
EDIT:
I just realized that's what supersampling is!
Exactly!
I'm running Minecraft 1.3.2 on Ubuntu 12.04 LTS (64-bit) using OpenJDK 7. I have the 1.3.2 version of the mod, and the only other mods I have installed are Forge, Modloader, SPC, Opti-Fine, Minema, and CameraStudio, all up-to-date and there were no error messages.
Hm, that's weird. Obviously, the camera modifications are ignored for some reason, so the normal view is simply repeated on all tiles. Since there's no error message, it's hard to find out the reason for that...
The mods alone shouldn't be a problem, since I'm using heuristic reflection to find and modify the fields that are used to set the camera zoom and offset. Unless they're completely removed, of course.
http://i.imgur.com/s5Xsq5k.png (MCF hates big images
Hint: Some GUI changes
http://i.imgur.com/s5Xsq5k.png (MCF hates big images
Compiled (for users): http://ge.tt/9lzBpDd/v/0?c
Source (for devs) http://ge.tt/6LwMpDd/v/0?c
Hint to BarracudaATA: change all instances of controlList in GuiScreenSettings.java to buttonList.
http://i.imgur.com/s5Xsq5k.png (MCF hates big images
This is what I made after what I guess you could call a hello world.
http://i.imgur.com/s5Xsq5k.png (MCF hates big images
Here's a small example gallery that demonstrates what is now possible using just Minecraft, Forge and Mineshot: http://imgur.com/a/1sSNW
Thanks, that bridged the time for the update. Since 1.4 requires Forge now, I'll add yours on the first page.
He should be doing the EXACT same thing with the keybindings of everything else. No idea what hacks the macro/keybinding mod uses to do what it does, so it's probably the weird hacks that the keybinding mod does, and has nothing to do with mineshot.
http://i.imgur.com/s5Xsq5k.png (MCF hates big images
I don't think so. I hoped nobody else uses that hooking method and I don't plan to use liteloader, since most of its functionality is already integrated into Forge. The only realistic chance is that the profiler hooking finds its way into the Forge code base so multiple mods can use it.
There's no other way other than to modify Minecraft's classes directly, which is very ugly and causes just more compatibility issues. The isometric mode requires it to run special OpenGL commands at the right time to override the camera projection mode.
But I could add a config value to disable the hooks. This would also disable the isometric camera when enabled, but at least other mods won't break.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumIf you did this I could also provide a LiteMod which could call the relevant function in your mod at the right point in order to preserve the isometric rendering. I strongly suspect that one of the hooks in either my RenderListener or PostRenderListener interfaces would do the job. In fact all your mod would need to do to get these callbacks itself would be to call (using reflection if you don't want to create a dependency) LiteLoader.addRenderListener() passing itself as an argument.
Just a thought. To clarify, the main reason LiteLoader uses the profiler hooking method is to steer clear of things like Forge and ModLoader which don't touch it, to allow forge mods and litemods to exist side by side. Because of this it is safe to have forge mods also use liteloader callbacks because the two loaders shouldn't interfere with one another.
At any rate, it should be possible to not conflict with LiteLoader without having to create a separate version which depends on it, aside from importing 2 interfaces. I'm fastidious about not altering the interfaces once published so it's safe for you to copy the interfaces as-is directly into your workspace without fear that they might change in the future.
Obviously this may all seem like too much of a hassle for you, and that's a fair comment, just thought I'd at least chip in to mention this in case it's of use to you.
Well, I fixed it in 1.41 by using the previously defined profiler instance as a proxy when it's using an extended non-vanilla profiler class. It produces slightly more overhead this way, but it seems to work. Don't get me wrong, I'm not trying to avoid LiteLoader at all costs, but the current solution should also support other mods or APIs that override the profiler via reflection, in case any exists or will ever exist. Of course, there's no 100% guarantee, but it seems that you can never be completely sure when developing software.