It's feature complete compared to the base class version. That is to say, the 3 classes added there can replace all the base class edits and do all the same things. If someone else is working on this, feel free to steal any of that, it's pretty much done.
*EDIT* looking at julialy's it looks like we've independently done pretty much the same exact thing haha
Anyway, if my pull request (the observer part) gets merged, this will work fine with VoxelMap forever with no loss of functionality for either. Otherwise, things will remain broken until I roll out a new VoxelMap compiled against WDL's new package (and which will as before have reduced map functionality as long as WDL is downloading)
Hi Mamiy . We're sill getting the "Is modified is false error" with the new worlddownloader versions liteloader , forge and Nariol's July 10 compile
strange thing is Nariols WDL code from july 2 works and Nariol and myself can't see why that is , can you check into this ? then we can update the WDL1.7.10 liteloader mod code
This would be because WDL is in a different package now, and importing net.minecraft.wdl.WDL; does nothing, so Voxelmap can't read WDL.downloading and WDL.saving to know when not to mess with isChanged anymore
I can fix the import and hope no one is using a WDL in the old package location.
So: isChanged. VoxelMap and WDL are using it for much the same thing: to know when a chunk needs to be refreshed / saved (because it has changed). It's a bit hard for more than one mod to use that variable, since both change it to false once done with the refresh / save so as not to do it again.
A while back, I made a liteloader version of WDL (to see if I could - no changes to base classes meant it could run with or without Forge with no changes, either way Forge wouldn't know it was there). To work around both voxelmap and liteloader.WDL wanting to use isChanged, Voxelmap polled chunks' isModified, and if it was true, set it to false, and fired setChanged() and notifyObservers() in a notifier. liteloader.WDL registered as an observer of said notifier, and when it was notified thereby of a chunk change, it knew to save.
code for the observer:
public class WDLChunkChangeObserver implements Observer {
public WDLChunkChangeObserver() {
if (ReflectionUtils.classExists("com.thevoxelbox.voxelmap.interfaces.AbstractVoxelMap")) {
com.thevoxelbox.voxelmap.interfaces.AbstractVoxelMap.getInstance().getNotifier().addObserver(this);
}
}
@Override
public void update(Observable o, Object arg) {
if (arg instanceof Chunk)
WDL.chunkChanged((Chunk)arg);
}
}
WDL.chunkChanged(Chunk) added the chunk to a set of changedChunks. When saveChunks() was called, the chunks in the set were saved in addition to any other chunks where isModified was true. Also in onChunkNoLongerNeeded, chunk was saved if isModified was true, or if changedChunks.remove(unneededChunk) was true.
Now ideally some third party would do the polling and notifying, and both WDL and Voxelmap (and Minecraft itself haha) could register as observers to know when to refresh/(mark to)save any changed chunks.
Barring that, WDL could register with the VoxelMap notifier if it exists (Pull request here), or WDL could implement a notifier and I could register with that, though the former makes more sense to me since VoxelMap refreshes frequently, while WDL only cares about isChanged when it saves and doesn't need to be constantly polling. Either way would require a lot of potentially difficult cooperation, since the mods are made by different people.
So without that, I'm left with checking WDL.downloading and WDL.saving and voluntarily giving up some of my functionality while either is true (though changing packages on me can obviously torpedo even that)
in the logs you just posted, there's the java.lang.NullPointerException at java.net.NetworkInterface.getInterfaceAddresses(Unknown Source) I mentioned in my first post on this page. Like I said, this is fixed in the latest version, which you can find for now at http://www.mediafire.com/download/hbakk9iuuf7t0h5/mod_voxelMap_1.2.2_for_1.7.10.litemod in which that bug really should be worked around. Please check it out and let me know if that is the case
I'm a bit tired of people mentioning VoxelMap as "oh, well, if there's nothing else maybe I'll grit my teeth and use that". I've taken it down
Clarification time. Both of those sentences are true, but they are not related like their proximity might suggest. I had taken the mod down before ever seeing this thread because I won't be on PMC anymore. I just haven't yet bothered figuring out where I'll host it in the future. The pique in the first sentence was real though, so I wasn't particularly bothered that my phrasing might lead people to think that 1 led directly to 2. It didn't though, and VoxelMap isn't going anywhere, and if I ever tire of it completely someone else will step in (hopefully someone who can tell what the heck the code does. It's inscrutable in parts I'm afraid)
Sorry to worry anyone, that wasn't super nice of me.
Doesn't look like you did anything wrong, that looks like a bug with VoxelMap.
Indeed, though the log doesn't show where it occurred. He'd get that if it failed to initialize for whatever reason. I'd need to see the whole log to know why that happened. Recently it happened to someone because of a bug in java itself in NetworkInterface.getInterfaceAddresses(), the possibility of which is now worked around.
I'm trying to do something in EntityRenderer.renderWorld() at this.mc.mcProfiler.endStartSection("hand");
I've found a couple ways to do this. in LiteloaderCallbackInjectionTransformer.addCallbacks(int type), I can add a line like
this.addCallback(type, Obf.EntityRenderer, Obf.renderWorld, "(FJ)V", new Callback(CallbackType.PROFILER_ENDSTARTSECTION, "postClouds", CloudThingObfuscationTable.cloudThing.ref, "hand", type));
Or create a class CloudThingInjectionTransformer extends CallbackInjectionTransformer and add that line in there, then in LiteLoaderCoreAPIClient edit requiredDownstreamTransformers to include "package.CloudThingInjectionTransformer"
Either of these works, but obviously require editing liteloader itself, which is not what I want to do. Am I missing an easier way to add a callback at a particular profiler section?
It's hardly a section a lot of people would use, but I'd like it so I can make sure clouds are transparent when the player is below them. This is stupid easy with a single class jarmod, but with an eventTransformer to make sure cloud drawing doesn't happen at the wrong time (before terrain) and the desired profiler callback to make sure cloud drawing does happen when it should (after terrain rendering) - in both cases ignoring player height - it could be done in a less invasive way.
Now, i think I could just do it at postRender (after cancelling the too early rendering, ie before terrain), but the above question remains out of curiosity. tl;dr is there a way to add a callback at a particular profiler section?
Q: What's name of the mod's author? A: MamiyaOtaru
Q: Is the mod available on more than just singleplayer? (Choose any that apply) A: SSP and SMP compatible (but purely clientside)
Q: Does the mod require Forge? If not, is it at least compatible with Forge? (Choose only one) A: Compatible (require Liteloader)
Q: Could you please provide a concise description of the mod? (Few sentences to a paragraph) A: VoxelMap is a minimap. Chatbubbles show what people say in bubbles above their head. Jukebox allows play of MP3s, OGG, FLACC, M4A, WAV in-game. MotionTracker alerts to presence of mobs
Yeah you can inject into constructors BUT be aware that injecting code into constructors can be very dangerous if you do it at the wrong point. I suggest if you're new to bytecode injection that you stick with a Return injection point or you may find that weird shit happens. This is because with injection (eg. MethodHead) you could actually inject code before the superclass constructor invokation, which could be pretty disastrous depending on the nature of the class. If you notice everywhere that LiteLoader injects into constructors it uses RETURN injections (look in LiteLoaderCallbackInjectionTransformer). There's also a "constructor" obf entry in LiteLoader's Obf class so you can reference that in your MethodInfos.
had overlooked the Obf.constructor field Warnings noted, have it working. Without having to use reflection to get the McoServer the code is greatly simplified, though I think I still prefer coming from RealmsMainScreen.play() instead of OnlineConnectTask.OnlineConnectTask(), feels more direct. Good to get a better handle on the transformers at anyrate, thanks
I was actually just looking at this for you and had pretty much come to the same conclusion. I assume you did the same as me and decompiled the realms binary to have an explore of how it gets the current EC2 server address?
The only other alternative I'd been exploring was that the screen which launched the connection is stored in the current NetworkManager instance, which is a pointer to the "realms proxy" screen which contains the real screen, which in turn could be queried to get the scroll pane containing the servers, and then THAT could be queried to get the index of the server and then the index of the server could be looked up against the current server list.... woo.... yeah the transformer is a billion times easier
It's a nuisance that it's so opaque, but I guess they wanted the dependency to be realms -> minecraft with no dependencies in the other direction (which makes perfect sense) so it's understandable that there's no member in the minecraft codebase which has the info on the current realm, but it would be much nicer if there was something in the handshake packet or login packet which signified the realm id or whatever, as it stands realms appear exactly like vanilla servers from the client's POV.
Yeah, I looked at the NetworkManager -> realms Proxy etc chain, but it started to make my head hurt. So transformer it is I opened up the realms .jar with jd-gui. Not the best decompiler, but good enough to see what was going on, especially since the realms jar isn't obfuscated (made creating the Obf entries really easy hah).
Which did lead me to one question: I tried hooking into OnlineConnectTask's constructor, since it gets passed the McoServer instance (containing name and owner etc), but seemed to be unable to do so. Is that possible somehow, or only regular methods? Ended up having to, as previously mentioned, hook into RealmsClient.play(), which only gets passed the server's ID. From there I used reflection to call the private RealmsClient.findServer(long) method to get the McoServer instance and the name (useful to give the .points file a recognizable name). It works fine (again, lack of obfuscation makes getting the findServer method easier than it could be), but I could have saved a step by getting it from OnlineConnectTask's constructor.
using your event transformers now to get VoxelMap to work with Realms.
The only part of Minecraft that has any knowledge of a realm's name and ID is the realms bit. You select on in the realms GUI, and minecraft gets passed the amazon address that it's currently at and has no idea of the name of the world that was just joined. Unfortunately the amazon address can and does change, so saving the .points file based on the IP connected to will not work.
Regular MP is similar, except the screen does pass serverData to Minecraft, so you can get the name and IP from there. Regular servers don't change their IP too often, but LAN ones might (the port portion of it specifically) so being able to get the name is nice. Realms, as mentioned, doesn't do this though.
So using event transformer, I can hook into the RealmsClient play() method and get the ID and from there the server data and name of the realms world being connected to. If there's a better way to do this I'd love to know about it, bot for now this works great VoxelMap 1.2.1 for 1.7.10 now handles this.
Also LOL at all the people who are posting stuff like "so are you saying Notch was lying?" Is that the limit of your imagination? You ca't picture someone (a retard) simply being mistaken about something? He goofed, that's all. Not malicious, just dumb.
0
this commit is my version of the litemod: https://github.com/MamiyaOtaru/WorldDownloader/commit/9d939722f7c8ecbcf70fc28a307176af453e998e
It's feature complete compared to the base class version. That is to say, the 3 classes added there can replace all the base class edits and do all the same things. If someone else is working on this, feel free to steal any of that, it's pretty much done.
*EDIT* looking at julialy's it looks like we've independently done pretty much the same exact thing haha
Anyway, if my pull request (the observer part) gets merged, this will work fine with VoxelMap forever with no loss of functionality for either. Otherwise, things will remain broken until I roll out a new VoxelMap compiled against WDL's new package (and which will as before have reduced map functionality as long as WDL is downloading)
0
This would be because WDL is in a different package now, and importing net.minecraft.wdl.WDL; does nothing, so Voxelmap can't read WDL.downloading and WDL.saving to know when not to mess with isChanged anymore
I can fix the import and hope no one is using a WDL in the old package location.
So: isChanged. VoxelMap and WDL are using it for much the same thing: to know when a chunk needs to be refreshed / saved (because it has changed). It's a bit hard for more than one mod to use that variable, since both change it to false once done with the refresh / save so as not to do it again.
A while back, I made a liteloader version of WDL (to see if I could - no changes to base classes meant it could run with or without Forge with no changes, either way Forge wouldn't know it was there). To work around both voxelmap and liteloader.WDL wanting to use isChanged, Voxelmap polled chunks' isModified, and if it was true, set it to false, and fired setChanged() and notifyObservers() in a notifier. liteloader.WDL registered as an observer of said notifier, and when it was notified thereby of a chunk change, it knew to save.
code for the observer:
public class WDLChunkChangeObserver implements Observer { public WDLChunkChangeObserver() { if (ReflectionUtils.classExists("com.thevoxelbox.voxelmap.interfaces.AbstractVoxelMap")) { com.thevoxelbox.voxelmap.interfaces.AbstractVoxelMap.getInstance().getNotifier().addObserver(this); } } @Override public void update(Observable o, Object arg) { if (arg instanceof Chunk) WDL.chunkChanged((Chunk)arg); } }WDL.chunkChanged(Chunk) added the chunk to a set of changedChunks. When saveChunks() was called, the chunks in the set were saved in addition to any other chunks where isModified was true. Also in onChunkNoLongerNeeded, chunk was saved if isModified was true, or if changedChunks.remove(unneededChunk) was true.
Now ideally some third party would do the polling and notifying, and both WDL and Voxelmap (and Minecraft itself haha) could register as observers to know when to refresh/(mark to)save any changed chunks.
Barring that, WDL could register with the VoxelMap notifier if it exists (Pull request here), or WDL could implement a notifier and I could register with that, though the former makes more sense to me since VoxelMap refreshes frequently, while WDL only cares about isChanged when it saves and doesn't need to be constantly polling. Either way would require a lot of potentially difficult cooperation, since the mods are made by different people.
So without that, I'm left with checking WDL.downloading and WDL.saving and voluntarily giving up some of my functionality while either is true (though changing packages on me can obviously torpedo even that)
3
10
Clarification time. Both of those sentences are true, but they are not related like their proximity might suggest. I had taken the mod down before ever seeing this thread because I won't be on PMC anymore. I just haven't yet bothered figuring out where I'll host it in the future. The pique in the first sentence was real though, so I wasn't particularly bothered that my phrasing might lead people to think that 1 led directly to 2. It didn't though, and VoxelMap isn't going anywhere, and if I ever tire of it completely someone else will step in (hopefully someone who can tell what the heck the code does. It's inscrutable in parts I'm afraid)
Sorry to worry anyone, that wasn't super nice of me.
*edit* that link Mumfrey mentioned is here: http://www.mediafire.com/download/hbakk9iuuf7t0h5/mod_voxelMap_1.2.2_for_1.7.10.litemod I wouldn't bookmark it; it will change as the version number advances, but pending some more permanent solution it will work for now
1
0
Indeed, though the log doesn't show where it occurred. He'd get that if it failed to initialize for whatever reason. I'd need to see the whole log to know why that happened. Recently it happened to someone because of a bug in java itself in NetworkInterface.getInterfaceAddresses(), the possibility of which is now worked around.
anyway yeah, would need to see the whole log
1
0
0
0
I've found a couple ways to do this. in LiteloaderCallbackInjectionTransformer.addCallbacks(int type), I can add a line like
this.addCallback(type, Obf.EntityRenderer, Obf.renderWorld, "(FJ)V", new Callback(CallbackType.PROFILER_ENDSTARTSECTION, "postClouds", CloudThingObfuscationTable.cloudThing.ref, "hand", type));
Or create a class CloudThingInjectionTransformer extends CallbackInjectionTransformer and add that line in there, then in LiteLoaderCoreAPIClient edit requiredDownstreamTransformers to include "package.CloudThingInjectionTransformer"
Either of these works, but obviously require editing liteloader itself, which is not what I want to do. Am I missing an easier way to add a callback at a particular profiler section?
It's hardly a section a lot of people would use, but I'd like it so I can make sure clouds are transparent when the player is below them. This is stupid easy with a single class jarmod, but with an eventTransformer to make sure cloud drawing doesn't happen at the wrong time (before terrain) and the desired profiler callback to make sure cloud drawing does happen when it should (after terrain rendering) - in both cases ignoring player height - it could be done in a less invasive way.
Now, i think I could just do it at postRender (after cancelling the too early rendering, ie before terrain), but the above question remains out of curiosity. tl;dr is there a way to add a callback at a particular profiler section?
*edit* here's the mod: http://www.planetminecraft.com/mod/better-clouds/ It'd be a bit simpler code wise if I could figure out an answer to that question, but it functions
0
0
*Q: What Minecraft version are you submitting this for? (Choose all that apply)*A: 1.7.10*Q: What is the name of the mod?*A: VoxelMap, ChatBubbles, Jukebox, Aliens MotionTracker*Q: What is the link (URL) to the mod?*A: http://www.planetminecraft.com/mod/zans-minimap/ , http://www.planetminecraft.com/mod/chat-bubbles/ , http://www.planetminecraft.com/mod/jukebox-1851130/ , http://www.planetminecraft.com/mod/aliens-motion-tracker-259246/Q: What's name of the mod's author?A: MamiyaOtaruQ: Is the mod available on more than just singleplayer? (Choose any that apply)A: SSP and SMP compatible (but purely clientside)Q: Does the mod require Forge? If not, is it at least compatible with Forge? (Choose only one)A: Compatible (require Liteloader)Q: Could you please provide a concise description of the mod? (Few sentences to a paragraph)A:VoxelMap is a minimap. Chatbubbles show what people say in bubbles above their head. Jukebox allows play of MP3s, OGG, FLACC, M4A, WAV in-game. MotionTracker alerts to presence of mobs0
had overlooked the Obf.constructor field
0
Yeah, I looked at the NetworkManager -> realms Proxy etc chain, but it started to make my head hurt. So transformer it is
Which did lead me to one question: I tried hooking into OnlineConnectTask's constructor, since it gets passed the McoServer instance (containing name and owner etc), but seemed to be unable to do so. Is that possible somehow, or only regular methods? Ended up having to, as previously mentioned, hook into RealmsClient.play(), which only gets passed the server's ID. From there I used reflection to call the private RealmsClient.findServer(long) method to get the McoServer instance and the name (useful to give the .points file a recognizable name). It works fine (again, lack of obfuscation makes getting the findServer method easier than it could be), but I could have saved a step by getting it from OnlineConnectTask's constructor.
0
The only part of Minecraft that has any knowledge of a realm's name and ID is the realms bit. You select on in the realms GUI, and minecraft gets passed the amazon address that it's currently at and has no idea of the name of the world that was just joined. Unfortunately the amazon address can and does change, so saving the .points file based on the IP connected to will not work.
Regular MP is similar, except the screen does pass serverData to Minecraft, so you can get the name and IP from there. Regular servers don't change their IP too often, but LAN ones might (the port portion of it specifically) so being able to get the name is nice. Realms, as mentioned, doesn't do this though.
So using event transformer, I can hook into the RealmsClient play() method and get the ID and from there the server data and name of the realms world being connected to. If there's a better way to do this I'd love to know about it, bot for now this works great