Still waiting for a password reset email from Mojang. I did this some time before finding this thread, so it has likely been a week since I requested my password reset. Not entirely sure when I contacted Mojang with the email questioning the reason and access to my account again, but nothing has come from that.
I know the email isn't being put into spam, I've checked (at least) three times. And, unless the Mojang system is stupid, it should be being sent to my email-instead of anyone who may have attempted to hijack the account-as it still recognizes my email... I just receive nothing when trying to contact them or reset my password.
I imagine that more people than those who are voicing their concerns on these forums are experiencing this issue, which might explain why response time is slow... And to those getting annoyed that we are continuing with what you may see as a farce... it is important that others who experience the same or similar issues have a place to see that they are not alone in these issues. While it is certainly true that there are those who do not know how to do the 'automatic' steps to get their accounts back-even if due to user error-more than enough do know, or are smart enough/willing to look up instructions. This is, or should be, for the rest of us who have already tried the simple steps that are routinely repeated to people with 'lost accounts' complaints...
(If I misinterpreted your comments, then I do apologize, but, while I certainly recognize that this is a 'fan-base maintained unofficial' forum, it is still necessary for those of us who are experiencing 'different' account issues to know that we are not, necessarily, alone or unique. Regardless of whether anyone on this site can actually do anything about it or not, the sharing and pooling of information alone helps.)
Yeah... That doesn't explain why I suddenly cannot login to Minecraft... I know the password is correct, I know the 'name' is correct... but it simply will not allow me to login (or get my password reset).
Firstly, I have attempted to contact Mojang to complain about my loss of account, secondly, while I received a different email (mine was to verify my email address-which is odd as I have been playing Minecraft longer than I have been on this site--see profile for details[?]). I did basically the same thing as the person who wrote the original post, and I cannot even access https://account.mojang.com/login.
Frankly, I do not feel the need to go into my anti-virus and firewall (not to mention anti-malware, anti-spyware, etc), when I can simply say I am majoring in Computer Science in college and I went through the 'basics' of maintenance and repair in High School... If this were 'my fault' then a lot more than Minecraft would have been compromised.
So, no, it isn't just them... as you can clearly see there are more people here saying that they have had similar happen to them.
It is a part of the dungeon template, if you open the configuration file for each dungeon room (you can even make your own rooms), there is an option that specufies dungeon type, they can be "open" or "closed".
I think only "open" types have spawn monoliths.
Unfortunately this config is seperate for each possible room, so you will have to change a lot of files.
Yeah, I knew it was separate for each room... but at least this will give me the option to remove the monoliths until/unless stevenrs11 decides to allow us to via config.
Honestly, I don't 'really like' cheating... but I hate "You are where you should not be" instances even more. To quote a television show (which is probably quoting something else), "if they really didn't want [people] getting into it, they should have built it better." Far less applicable to this mod (for reasons I have asserted before), and more so to World Of Warcraft. (If I'm going to spend ~> 30min jumping in one location trying to 'catch' on that 'sweet spot' to get a few inches up a hill to get to an area they thought had been blocked off, I kind of deserve to be able to explore the completely and utterly empty area I just managed to get to... Honestly, what harm is there in exploring a zone with literally nothing in it? (Developer island? I can understand blocking us from that - sort of, but Mount Hyjal, not so much.) Also, I haven't played since Wrath, so, yeah, I know all of these places are 'open' now.
Anyway, I'll backup the files and modify them, until/unless the dev decides to grant us the option within the mod. (I just noticed that Morph has the ability to set when players can fly with morphs that can fly. The ONLY reason I noticed this was because something else set it differently--I had thought it was a bug...)
Also, there are some dungeons that players cannot get past with bat morphs. There is one where, as soon as you enter it, a series of pistons begin bringing the walls closer into you, with lava falling behind them. Under the floor in certain places there are loot chests. Surrounding the dungeon is bedrock. -- For this dungeon I have a suggestion: replace the bedrock with the block that teleports players back to the real world (the red block that is at the bottom of limbo) so that players with fire resistance cannot simply walk on/next to the bedrock. Personally I think this block being added to dungeons is a better choice than Monoliths as they can be avoided but they also give the feeling of falling into a void. If, perhaps, a similar block were created that literally 'sucks' you into it like a black hole (think the holes in Fez) these could be put around dungeons in addition to monoliths (and then you could give us the option to disable monoliths). The idea is that surrounding the dungeon is 'empty space' and if you fall into the Vanilla void you enter limbo... well, why not 'fall' more than just down?
EDIT: Also, I keep forgetting to ask this, could you please add a list of the commands available from this mod to the first post? I have searched this thread for them, but all of the ones I have found do not work... (like the cleanup command-which clears dimensions not connected to other dimensions-, for example)
First off, I am very for compatibility with other mods. Not just functional compatibility (ie, not crashing), but game-play compatibility. Quite a bit of my mod was designed from the ground up to play well with other mods. For dungeons, I could very easily remove the players inventory temporarily, set him to adventure mode, intercept and disable any player events aside from movement, just about anything. But I don't, because using a bat to fly over traps is in my opinion, a rather cool solution. Now, the next set of dungeons I release may have several dedicated bat traps, but that's because difficulty is fun, if done right. Codebracker0 has the right idea, and those are some great dungeon ideas, btw.
It would be silly for me to look at things that other mods add, and then try to remove these abilities from players in my dimensions. After all, they installed these things. Instead, I look at the added abilities that mods give and design challenges around them that take advantage of these abilities.
I don't see how this mod compatibility thing relates to monoliths in dungeons, though. I am not trying to micromanage player movement or anything like I mentioned earlier, monoliths serve to restrict vanilla players far more that modded players.
Granted. And I was merely bringing this up because, in the event you felt as though it was a requirement for you (as it appeared with EE2/3), I wanted to assure you that the concept is entirely optional. I am glad you want to extend compatibility.
Secondly, as stated before, some dungeons do not have monoliths, some do... I am wondering if you would be willing to share where this data is stored. If I can 'screw up' my game files without doing so for anyone else, that would be the ideal situation (well, really, you giving us the option would be the best ideal, but I can understand why you choose not to).
And its funny that you bring up a 'w' axis, octrees, and the like. Sadly, its not really possible for a mod to change how chunks are stored and indexed while remaining compatible with other mods. Right now, chunks are composed of arrays of blocks, and that array is hard coded to support only the amount of data required to store blocks with 3 coordinates, along with ID and metadata. To be done right, it needs to be done by mojang. I do see what you are saying, though. The reason I think its funny is that the dimension ID is literally your w axis. It may not be as streamlined as we would like, but given minecrafts architecture, its the only way right now.
CubicChunks (http://www.minecraftforum.net/topic/1707097-cubic-chunks-reduced-lag-infinite-height-and-more-nearly-three-thousand-supportersupdated-feb-3rd/) is what I was referring to. Here, of course, I am assuming something is actually happening with this mod, and it isn't just a theory/fantasy thread.... (without downloads it is kind of hard to tell...)
But, inevitably, for stability, you are correct that for this to be done in the best manner possible, it needs to be done my Mojang... which is sad because they have given plenty of evidence that they do not really know the correct way of coding with Java... A lot of issues that modders have come across, and Minecraft itself should have been resolvable with 'proper' usage of Java (i.e. Deprecation, API, etc).
However, you are inaccurate in one regard. While it is true that Save Game files are written, created, and stored in a specific way you yourself have proven that this is not the only way. Beyond storing structure in separate files, mods that create 'bags' and similar link external files to the bag's inventory. This is exampled not only in the fact that 'logging in' anonymously (i.e. not being able to log in and playing Minecraft anyway) will clear out the bags inventory, but also in the fact that you can access these files-whose data would normally be stored in the save file(s).
Similar could, in theory, be done with block placement. Archimedes ships (http://www.minecraftforum.net/topic/1857899-164-152forge-archimedes-ships-v14-passenger-seats/) is exampling this by converting the blocks into (connected) entities and back. (now, it is certainly true that compatibility with other mods has been an issue with this mod as things like pipes seem to reinsert themselves improperly, but that is an issue that could be resolved 'fairly' easily...)
Finally, with regards to the game I referenced (Prey: http://www.3drealms.com/prey/) took a game engine and did with it what the game engine was not designed to do (similar with Portal). id's Doom3 engine was not designed to store model and level data in the same location, without transitioning by removing and replacing, and yet this is exactly what Prey did. Prey added the ability to store two sets of information in the same location at the same time and simply transition between the two when moving through a specific space in a specific way.
Similarly the same should be possible with Minecraft-while certainly difficult to implement.
Let's say, for example, that you continued storing the dungeon information in a separate dimension (which would be the easiest way to do it right now). Well, we already know, via 'world leaks' that these other dimensions can be loaded at the same time as some other one. Now, all we would have to do is figure out a way to super-impose these chunks (or, to be more accurate, simple block data) over the data that is currently in the world. Because Dimension (A) and Dimension (B) can be loaded at the same time, and therefore the data is readily available (i.e. you don't have to go through a 'loading dimension' screen) super-imposing the information from one location in RAM should be fairly simple. In fact, there are mods that do something-like this already. QCraft (http://www.minecraftforum.net/topic/2035719-164forgesspsmp-qcraft-quantum-physics-meets-minecraft-updated-with-inter-server-teleportation/), Carpenter's Blocks (http://www.minecraftforum.net/topic/1790919-1516forge-carpenters-blocks-v202-slopes-stairs-and-more/), among others are mods that add a 'similar' ability (that being having multiple blocks data within one block's location).
Realistically, the hard part would be telling the game how and when to show a specific set of data as opposed to another specific set of data without transferring the player to an alternative dimension. I believe that using similar coding as QCraft would allow for this (by specifying a cubic region as 'in this location' and a 'doorway' that transitions from 'location' to 'location'... then having the visible blocks in that 'location' be the ones stored in the alternative dimension (again, until there is a better/alternative method of storing block data).
I guess it would go like this: Player is in overworld (block data is stored normally), player sees doorway and walks through-as the player passes through doorway the system is told that the visible and intractable blocks are now from a different specified set (from another dimension, for simplicity sake). When the player leaves by the same door, or by a new door the system is told to render (and interact with) blocks from the overworld/a different location.
I'm sure you are wondering how this would be beneficial rather than loading a new dimension each time (which is certainly easier). Assuming you could eventually change the data from dimensional saves to simple text-file saves (which is basically the same thing) the amount of data loaded would be vastly smaller. It would also allow you to store all dungeon information in one location (i.e. a single dimension) rather than creating a new one for each dungeon-while still preventing players from simply breaking the walls and walking into another dungeon. The 'load time' would also be smaller as players would not have to sit through a loading screen to go from one dungeon to another.
Finally, I certainly understand if you are not willing to do this. If I were 'capable' of coding it myself I would (and then give/lend you the code), but, well, various 'disabilities' make coding extremely difficult for me (even though I spent four+ years learning Java/C++)... I just, get lost, and figure it better to 'start over' too frequently. (I tried learning Japanese, for various reasons, and while, what is typically the hard part for most western language users-the sentence structure-was child's play for me, the vocabulary still is nearly impossible [i.e. I can read Japanese given a dictionary, but even with a dictionary I cannot produce Japanese...])
Hmm, you have a point there, because most traps are about "dropping" the player, so they can easily be countered by flying.
I on the other hand just suggest to just create more traps, that are dangerous in some other way.
Even though Morph is preatty overpowered, players who choose to use it should still be chalenged.
On the line of diferent gravity dungeons, I have no idea how Starminer does it, but I would love to see something like that in a dungeon.
Possibly even in a dungeon that you can flip upside down with a switch (which is sideways), so you can explore it two ways.
Or a dungeon that has multiple entrances and the gravity flips as soon as you enter, so it's perpendicular to the door you enterd trough.
Though the doors would still be right side up, I wish there was a way to add doors that could be placed sideways.
My comment about that mod was less about the gravity aspect and more about the camera movements. There have been many a mod for various games that have tried to do things 'upside down' but have failed to change the camera angle when changing the character model orientation. This mod shows that it is possible within Minecraft to change the camera orientation--and apparently fairly easily.
The primary reason I brought this up was because Dimensional Doors is about pocket dimensions and the long lines of dimensional dungeons. Would it not be more convenient if, instead of creating a new 'dimension' (world, really) each time, we could simply place the pocket dimensions/dungeons in a different W axis from the others?
In other words: Instead of loading a new world each time, if there were a simple shift in orientation of blocks-such that a block on W axis (1) did not interfere with block on W axis (2)-then it would be possible to have, at the very least, pocket dimensions in the same 'world' as the 'overworld'.
Unfortunately, while I know it is possible, I am not entirely sure how to go about doing it. Again, I brought up CubicChunks last time because that mod (if ever finished) will allow this to be done much more easily as it modifies how chunks are created and loaded... But I do know that it has to do with Octrees (http://en.wikipedia.org/wiki/Octree). Simply adding a ninth node would allow for a W axis. ... Again, I haven't a clue how to go about doing this in Minecraft, and I am sure this goes WAY beyond the scope of this mod... but I think it could certainly benefit from something along these lines.
A final note: With Morph, among other mods, realistically Monoliths are literally the only way to prevent players from breaking the concepts of this mod. Lava, fire, even explosions (if you carry around a bucket of water, or two, with you) can be avoided. My point is that there is really no point, given the expansiveness of the Minecraft modding community to try and come up with an answer to every possibility. I would much prefer if mod developers focus on making their own mods work, work well, and interesting, than attempting to 'fix' compatibility (which isn't broken in the first place) with other mods. The exception (of course) is when mod A depends on mod B, or is derived from... Mods that are meant or designed to work together should be, well, designed to work together... mods that are not explicitly created together shouldn't have to be completely aware of one another...
(Like the case with Morph. The developer has been working to incorporate mobs from other mods, and the abilities those mobs should have. This is all well and good, and nice... but simply adding an API through which other mod developers could give their own mobs said abilities within Morph 'would' be enough, in my opinion. True, this would make it up to other mod developers to incorporate their mobs into Morph, which means that some mods wouldn't have compatibility-as some people clearly think Morph is overpowered-but it would be solely under these circumstances that the dev of Morph would really 'need' to add compatibility-and he could be yelled at for doing so then, anyway...)
Love the puzzles/traps (even the ones that predated monoliths). Hate the f******g Monoliths. Saying you're using Monoliths to keep people from stripping down the redstone puzzles vs other methods is one thing. But then you talk about "counterplay" wherein, basically, you tell me to build a wall and strip down the puzzles anyway... I completely understand your (possible) frustration that some people would choose to strip the resources out of the pocket dimensions, instead of playing through them the way you intended. I also understand the amount of effort that goes into mods like this. I started playing this mod back in 1.4, and it was already a damn good mod. It's only gotten better since then. But... From one developer to another, make peace with the fact that we all play our own way, and while, yes, we're asking for one more toggle in the config file, bear in mind that 95% of the people playing this mod won't be touching the cfg with a "10 foot pole". tl; dr; It's a damn good mod, but let me turn off the damn monoliths... please?
Counterplay means you could uterly demolish the dungeon for resources, but they shure as heck won't make it easy for you. I mean it's not really worth it, but the option is there. Also it's not just against dungeon strippers, but also dungeon bypassers.
While I believe it is obvious that I agree with XombyCraft, I would like to make this standpoint evident as well. I was one of the people who fought for Equivalent Exchange to remain the way it was (in EE2) and that it wasn't overpowered... by which I mean the addition of other mods did not make it overpowered, and it was not the responsibility of the developer(s) of EE2/3 to 'fix' what other people saw as imbalance.
In all realism when process A creates some amount of a resource, and someone comes by and makes process B which produces more of that resource... process B is not an imbalance (by nature) nor overpowered (by nature). Grinders, saws, power generators, etc, these things produce less waist when processing one resource into another and therefore produce more of the resource than the first one did...
By extension this made the backwards conversion of secondary resource into primary resource imbalanced because you could take half an iron ore (the ingot produced by maceration) and produce a new iron ore... But that was neither the 'fault' of EE nor of the other mod. Minecraft itself has no sense of weight, and therefore no sense of waist (yeah, there are things that go beyond conservation of mass, but it is the easiest to implement 1 ten lb. ore block to 1 nine lb. ingot, obviously there is something missing, right?)
Anyway, the reason I bring this up is because of what XombyCraft said. In Minecraft a game you didn't code, design, or produce-but which you are modding-has code you do not controll-you are modding it after all. I use the Morph mod. I always get a bat morph as quickly as I can... I can simply fly over traps.
Does this mean you should find a way to disable morph mod in your dimensions? No, not really. YOU should not be held responsible for 'maintaining' interactions between your mod and others... unless those interactions are critical game-breaking crash-to-desktop bugs... and these are not. If you try to maintain all interactions then you are invariably saying that you know better, and are better than not only the other mod developers but your users as well (sure, in some -if not many- cases this may be true, but people don't like to hear it...). This is an issue that GregoriousT (of GregTech) has run into and one of the primary reasons people don't like him or his mod. It's a pity because his mod adds a lot to Minecraft, but it also removes a lot from other mods (and Minecraft). Example: To make some of his machines useful he doesn't take the 'normal' approach of "mechanical process -> more resource" but the abnormal process of "original process -> less resources". This is wrong. This is overextending the bounds of mod development in an open environment meant to interact with other mods. If it were a total conversion (see TerraFirma Craft), then it would be different, but GregTech is a IndustrialCraft addon and IndustrialCraft is meant to play nicely with other mods...
How does this relate to you? Merely by example: you needn't worry about how other mods play with yours on a fine level. True, if your mod starts 'leaking' into someone else's world, or the other way around, that is a problem... but trying to control every iota of movement within your mod's domain is a needle-in-eye process. It's painful and best left to those who are doing it professionally (i.e. if you want this level of control graduate to making your own games. You'll feel better and have the level of control you desire-period, no ifs, ands or buts. Your game, your rule. This is not the case in a mod, nor, really, should it be.)
Do I think you should stop making this mod? Certainly not. Making your own game would be awesome, I could certainly see a full length game with this concept (does it exist or did you draw inspiration from elsewhere?) But the mod itself is also very interesting.
All I am saying is to not expect (or demand) the level of control you appear to be forcing upon yourself. That's right, not upon us, but upon yourself. We the users can and will find a way-sometimes unintentionally, other times intentionally, to get around what you do be it via other mods or our own code/behavior... but that isn't your fault or your failing... it is the beauty of Minecraft (as a 'open' mod game).
Summary: If you believe it is your responsibility to 'fix' player movements to 'debug' your mod. I think you are going about this wrong... at least within the 'development environment' that is Minecraft mod making.
If, on the other hand, you enjoy finding solutions to players breaking your boundaries, feel free to continue looking.
One final thing: I knew there was a way to change perspective in Minecraft (i.e. turn the camera at a different angle) and I've been proven correct with the 'StarMiner' mod (look up the YogsCast video on it). I also know there is a way to use a, let's-call-it, 'w' axis in Minecraft to change the location of objects placed over one another. I'm sure 'eventually' I will be proven correct for this as well (at the very least it will be easier if CubicChunks is ever finished). You would benefit greatly from this, as it ties in directly to what you are doing.
If you have ever played 'Prey' you will know what I mean. Portal does something similar, but Prey's usage of 'W' axis is mind blowing.
You are right. I probably have a lack of knowledge of their mechanics. It is also probable that you have since changed their mechanics as, before the current version I had walked back into dimensions and been instantly teleported away--if this has changed I am very appreciative. It is also true that I do not know the challenges you went through to find a way of controlling players movements. You did send me a message about this although if you are willing to give more information I would love to hear it.
All in all, I really shouldn't complain about a possibly updated feature that may have been fixed/changed since I only recently updated the mod... Still, they are the (current) most annoying part about the mod...
Really, the thing I was coming here to talk about was dimension generation as if the data becomes corrupt it can crash the game. (i.e. if the file[s] are lost entering that dimension will crash your game). I've seen the content of the files and I think a way of fixing this would be to force generate the dimension again if the file is missing. The information about what is connected is still there (in the other files), but the content of that single dimension is gone... (and adding a title to the dimension as well as coordinates for the doors would allow the mod to know exactly what type was there before).
Obviously what you do with this information is up to you. Simple way to replicate this 'bug' is to enter a dimension, leave, quit the game, delete the dimension, and try to reenter the dimension.
Lastly on the new recipes. I think they are ok... I understand why you would move away from ender pearls/eyes... but having a way of, perhaps, crafting a rift to get the string (but decimate the terrain around it) would be useful for those who either have yet to find one or would have to travel tens or hundreds of chunks to get to the closest one. This is, of course, unless you made them more frequent--but that would still require regenerating a world.
Personally I like the addition of the monoliths. I remember when limbo was just a big empty... almost nothing. Although when I first ran into them I was surprised they didn't try to kill you. If your looking to move them around for some reason I suggest installing either mine factory reloaded and use a safari net or open blocks and use the golden lasso. I haven't tested either method, so don't complain if if destroys your limbo / world.
(Note, started replying to the next person in after this quote... ouips...)
I am fine with people liking Monoliths. I have no problem with them in the Mod, as an OPTION. In Limbo they are optional, why cannot they be elsewhere. If we want to walk around 'empty' worlds, why not give us the option to do so.
Besides, you cannot use Safari Nets or Lasos on Monoliths unless you can sneak up on them, and if I were willing to do that much work I could just quarantine them. It is also possible to use Turtles to decimate the dimensions, but that requires returning to that dimension to retrieve the turtle, at which point you'll be teleported out. --(note: however, that it is true that I only recently installed the version from their, what is it, GetHub? so they may have changed the delay in teleportation and the fact that if the monolith eyes are already open they will insta teleport you when you enter the dimension... which happened to me far too often when trying to edge around them...)
This is not THE way minecraft was meant to be played, it's ONE (perfectly valid) way of playing. But not everyone has the same playing style as you, and no mod can cater to every playstyle. If your primary interest in dimentional travel is to strip every dimention you find of resources, there are other mods that will fit your style much better than this one will: that's not what Dimentional Doors is about.
'The' way to play Minecraft is an open ended sandbox world. It is the way the game was designed, it is the way the game that Minecraft was designed from was designed (at least up till the point it was abandoned, who knows what it was really meant to be) and it is the way it has continued to be maintained. Adventure mode exemplifies this as an entirely different mode was added for those people trying to add things to the game the engine was not designed for. A simple mod isn't going to change that... not one the size of Dimensional Doors (it isn't a total conversion), and no, it isn't designed as you say because we aren't forced into Adventure mode with unbreakable blocks around us.
There are better ways to get around players breaking through your carefully crafted dungeons, and placing a insta-teleporter in is by far not the best option. A post further down is vastly superior to this concept because the way it is tricks us into thinking that we 'can' get past the monoliths. And, sure, if we really want to put forth the nonsensical effort, it is possible to quarantiene the monoliths, or capture them and bring them to the overworld (where they automatically die), but since we have the 'option' to turn them off in Limbo, why not allow us to turn them off completely. If the dungeons are really not meant to be stripped for resources why use redstone and stone brick, why not use something unminable, or purely decorative?
Now, don't get me wrong. I'm not saying anyone else's way of adding to the functionality of Minecraft is wrong. But you cannot honestly say that Minecraft is a first person shooter, or first person adventure game. The engine simply doesn't support that belief... unless HEAVILY modified (which it can be by the grace of Notch, as he has decided not to sue anyone for blatantly violating his copyright claim or terms of use).
If this mod is meant to be a 'first person Adventure' game mod, then force us into that. Don't try to force the engine to do something is is blatantly not designed to do.
While Minecraft is a lot like Garry's Mod of Half Life 2, it is also far superior in the way people can modify the code for Minecraft far more (and far more easily) than they can for Half Life 2 (and certainly Garry's Mod, which uses a Scripting Language to add functionality) While I won't get into the specifics of this it has to do with the accessability to Java over C++ and the fact that decompiling Java, modifying it, adding to it, etc, is much more readily done than C++...
Besides, if we really are not meant to be able to tear down the walls of the pocket dimensions then why not use command blocks to stop us? Adding that functionality to the doors should be fairly simple and would allow the developer to force us into adventure mode when entering and out of adventure mode when leaving their content... They could go further and add code to kill or teleport anyone not explicitly in adventure mode so using commands to go into survival would not work...
So, while you are correct in "it's ONE (perfectly valid) way of playing" and 'technically' correct in speculating "This is not THE way minecraft was meant to be played" you are also technically wrong when looking at the evidence of the Minecraft engine and how it was designed. Minecraft is a sandbox survival/creative game. That is the way it was created, that is the way it has always been. Adventure mode was only tacked on later when the developer (Notch, or Jeb) noticed people were attempting to use the engine for 'adventure games'. This is not what the game was intended as, so he 'tacked on' an ability for map makers to add 'special' content to the game... in the form of 'maps'. Yes, this can be done in the normal survival/creative game as well, and would be better utilized than the current method.
Finally, I am not requesting the removal of Monoliths, merely the ability to do so. We can remove them from Limbo, why not from elsewhere? (or are you going to tell me, quite contrary to your own conviction, that 'your' way of playing is the only correct way? That's what you'd be advocating if the mod absolutely most follow one direction, one path...)
Ir's not about not being able to steal stuff from someone, but if you ravage his house too much you can expect to get kicked out. I was suggesting replacing the stone bricks with special ones that randomly reappear when mined (don't drop), and have red eye particles when broken, would you prefer that?
Honestly? Yes. If these pocket dimensions are only meant to be pathways between one another with small sparse loot within them, then I would rather them be limited to such. But, especially if they are meant to solely be merely pathways between doorways with sparse loot within them then they really do not need a separate dimension for each dungeon... (for a pocket dimension, sure, we can modify those and are obviously meant to do so, but not for the--as you are all suggesting--unmodifiable dungeons.)
If we truely are not meant to break the walls and collect anything within them that we want then there are vastly superior ways of doing this than Monoliths. Monoliths are a great idea, they are terrifying and look cool, they have interesting effects... but if we are supposed to be able to modify the terrain within the dimensions their abilities are overpowered (a word/term I loath to use), and if we are NOT meant to be able to modify the terrain, then, again, there are vastly superior-coding wise and time wise-ways of preventing us from doing so... and I would prefer those ways to holding onto the belief that I can do anything other than run from point A to point B in the pocket dungeons...
I am NOT asking for Monoliths to be removed completely... not even partly, I simply wish to be given the option to disable them from my game and my world.
If that isn't an option then perhaps a competitor is required for this type of mod. (Obviously not a rip off, but something of similar nature: See GregTech vs FuturologyMod (http://forum.industrial-craft.net/index.php?page=Thread&threadID=10209). I honestly hope the developer is more openminded than Gregorious (almost anyone would be given past issues...) and I really hope the community here is more open minded than those who killed Equivalent Exchange. (It may still be kicking and sputtering, but it is nothing like its predecessors, and will not be for months/years to come...-which I don't blame the dev, he got married... but it is still the community that killed it).
Here, I should say one final thing: how many of you play the games you buy only on the hardest setting (available, some require you to finish easier settings to 'unlock' harder ones)... Ok, how many of you only play one 'game mode' in the games you buy (obviously of those with multiple game modes)? Ok, how many of you limit yourselves to a direct line path from beginning of game to end--i.e. speed-running--before playing anything else of the game first-or later?
I'm not suggesting we limit our playability of games, I am suggesting that people who expect one thing, and only that one thing are keeping their minds narrow and their experiences narrower. Minecraft is open-world and sandbox. It is the definition of what I am suggesting (true, we haven't been given a menu option to disable creepers yet, but we can very easily go into a single player world, open it to lan to TEMPORARIALLY enable cheats, /gamerule mobGriefing false, and be done with creepers destroying hours of work, my point is we have been give the options to enable what we like and disable what we don't. THAT is what Minecraft IS about. Anything else is a single person's attempt to force their view on us--by which I mean mods without options to enable/disable things at least in a config file... even Gregorious [GregTech] gave us numerous options within a few config files... [I use him because most people complain about the difficulty of his mod and how it changes other mods as well... which it does, beyond IndustrialCraft, regardless of his claims otherwise:: preventing Tin Buckets also prevents Metallurgy Buckets... if you no like tin -> Iron conversion rename the damn bucket...)
Firstly, I need to apologies about the formatting of my post. For some reason MCForums have not liked me much. It removed all end-lines from my post, making it one congealed block. I only noticed this for the 'edits'...
As of 1.6.4 it shouldn't get out of controll, but you can always use a rift remover one one of them and it should delete the whole thing. For now this seems to be the only renewable source of world thread, I wish there was another way to start dimensional doors besides finding a wild rift scar or making one. PS: I was thinking about rifts and I had an idea: A world rift If the game would detect a high concentration of rifts in a certain area interacting (10 or more), they would have a chance to colapse. Actually it would find a rift that is touching the most rifts and turn it into a "world rift". When this would happen it would absorb all nearby rifts (maybe drop stabile fabrics or something as it does?). The world rift would look like a dark crack going about 15 blocks above and below, at the center a red eye could be seen. If the crack was left alone for a while (2 minecraft days?), it would turn 3x3 chunks around it (just dirt or deeper?) into unraveled fabric, and turning into a normal rift leading to limbo. It would be even better if it could lead to any dimension, but I don't know if it would be possible for the game to know how (could the game use the terain generation from the respective dimension?).
It isn't about making a 'home' in them. It is about wanting to utilize Minecraft the way Minecraft is designed. If a space exists you can destroy and utilize it. All the stone bricks, etc, and especially redstone in those worlds is basically wasted.
Not only that but sometimes the monoliths spawn in dimensions that are not completely enclosed, so walking around becomes impossible without extreme care of blocking up your sides as you move--possible, if barely.
I just believe that there are better ways of utilizing the structures in Minecraft than making an 'unbeatable' entity that simply 'teleports you away' when you 'break the rules'...
Also, the links themselves were not missing. The text file describing the dungeon in the dimension-as well as the terrain for the dimension itself-was missing. File corruption happens, although in this case it was my fault, but it does happen. If a person is using pathways through dimensions, when a branch is lost that person is screwed...
These things should be reasonably rebuild-able given the text files describing the dimension before and after the given lost dimension, even if the exact layout is not.
Finally, with regards to Monoliths, anything else in the game I can eventually get past. Ender Dragon too difficult, get better armor and enchantments... Can't mine a specific ore, get a better pickax... Machine too costly to build, go mining for a few hours... But the Monoliths are specifically designed to be impossible. Honestly, it would make more sense to force the player into Adventure mode and have a check to kill them if they change mode while in a dungeon dimension. That's basically what the Monolith is.
The door slams if there is something wrong on the other side, no idea what though.
But the shimmering portal shouldn't dissappear no matter what, weird.
I've experienced this as well. A door slams shut as I try to enter it, preventing me from going through. Eventually I am able to pass through, but I am unsure of the cause.
Because of some lag I was experiencing I lost a dimension due to explosives (I was attempting to get the bucket of water into my hotbar to prevent the TNT from breaking blocks, but the game crashed and apparently had already blown up the ground when I got back in...) To 'fix' this I decided to do the 'smart' thing and simply delete the dimension so it would regenerate (hey at least I could continue further down and deeper in, right?) Well, not so much, and now I have myself stuck in a nonexistent space between spaces that constantly crashes my game. I am trying to 'trick' it into generating (ANY) dimension so I can tpx myself out of the mess (at which point I'll simply wipe out the entire lot of 'em and start fresh...) but this doesn't seem to work either.One last try and I'll have to edit my player.dat to forcibly move myself back to 'reality' (but I love exploring fiction...).Suggestion: Regenerate removed dimensions that have links to them, but that are missing. I believe I noticed that there are txt files that store information about these that are generated before the actual terrain data-I didn't really look into it too much. I understand the thought about people 'cheating' by regenerating dimensions to get more or more favorable loot, but they can find a way to do that anyway if they put more effort into it than "Oh I just -ed myself." Please, for the sake of those of us who are not always in 'perfect working condition' allow our computers to fix things. (thank you).Also, is there ANY way to get rid of those annoying monoliths other than ripping apart Minecraft to install Single Player commands and killall(ing) them? I've been looking into mods that kill (specific) mobs, or (which actually exists) prevents them from spawning at all, and nothing has worked. I would rather you use a command block and force us into Adventure mode each time we walk through a door and have blocks that directly kill us than have something unkillable and unmovable (except within very extreme specific conditions.I will find a way, 'tis only a matter of time... but I would vastly rather it be an 'official' way than a 'hacked in' way...Finally, seeing if my attempt to restore physical terrain has worked.
EDIT: And... crash... Ok, looking up that url now.
Edit: Final clarification: This problem I have is in no way your fault. It is due to my own stupidity and ineptitude (I should have had the bucket out and 'working' before I entered another dimenion, period...) I was just hoping to notify you of how I broke Minecraft and see if you wanted to put precautions into place to prevent others from trying the same.
Master_Aricitic: Watching your tool snap is a bit like breaking your arm. It will heal in time, but to do it properly you will need a splint. If the tool does get up to 100% durability it will function again but not before.
Auto-repair is not meant to replace repair mechanics. It's meant to make them take a bit longer to get to.
I didn't know that. Thank you. That it removes the 'broken' at 100% makes my request moot.
I am bringing this to your attention again. I know it has been talked about before but I feel it 'is' a bug and 'needs' to be fixed.
The auto-repair feature from moss is broken. Sure it will repair tools before they reach 0/<some number> but if they become 'broken' they will still regain durability but remain 'broken'. This is a bug. Please either make it so that when they reach 0 durability they no longer repair (which is stupid) or allow them to become un-'broken' when they repair that '1' durability.
Note: The reason I say it is 'stupid' to prevent 'broken' tools from repairing is if you have any other mods that modify the usage of durability of tools or weapons (like treecapitator) as they will often bring your tool/weapon down to 0 in unexpected ways or at unexpected times. Then, if you are like me, and wait for the tool to 'repair' itself... you will end up wasting materials in the end to remove the 'broken' modifier from it.
So, please allow tools that increase durability to un'broken' themselves.
The interaction I referred to at the beginning where people discussed this is as follows:
thats not what im saying, what im saying it that the durability is going up but its still broken, unusable. it should either be that the durability doesnt go up from the moss or that the tool becomes unbroken
A bit late, but better late than never, mojang is completely redoing the system so that instead of numbers for IDs it would use something like calvaria:MFFS:feild_generator so that unless another mod maker is deliberately trying to fudge things up for you than you should be good. Default items will be like minecraft:stone and so on.
I was just reading today that they are doing away with IDs in 1.7 and instead making some type of item arrays. If Java arrays are like arrays we use in web-development then that would mean that A. we can have as many items as we like and B. it will take a bit more work for mods to update to 1.7 but after that it should be a little bit easier for programmers.
EDIT: Oops like Zack said.
It's about damn time. I've been suggesting this since 1.2.somthing... Some idiot said that it would make the files too big, but, realistically if you preface the map saves with these numbers and then set them to numerical digits (to make the file size smaller) on a per map basis, it would have the same size consequences while reducing the screw-ups we get with IDs....
I wasn't sure if I should, it not being an official build, but I guess it doesn't hurt any.
---- Minecraft Crash Report ----
// Quite honestly, I wouldn't worry myself about that.
Time: 01/09/13 07:10
Description: There was a severe problem during mod loading that has caused the game to fail
cpw.mods.fml.common.LoaderException: java.lang.AbstractMethodError
at cpw.mods.fml.common.LoadController.transition(LoadController.java:149)
at cpw.mods.fml.common.Loader.initializeMods(Loader.java:702)
at cpw.mods.fml.client.FMLClientHandler.finishMinecraftLoading(FMLClientHandler.java:231)
at net.minecraft.client.Minecraft.func_71384_a(Minecraft.java:506)
at net.minecraft.client.Minecraft.func_99999_d(Minecraft.java:796)
at net.minecraft.client.main.Main.main(SourceFile:101)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at net.minecraft.launchwrapper.Launch.launch(Launch.java:57)
at net.minecraft.launchwrapper.Launch.main(Launch.java:18)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at magic.launcher.Launcher.main(Unknown Source)
Caused by: java.lang.AbstractMethodError
at com.pahimar.ee3.core.util.RecipeHelper.populateWildCards(RecipeHelper.java:42)
at com.pahimar.ee3.item.crafting.RecipeRegistry.<init>(RecipeRegistry.java:32)
at com.pahimar.ee3.item.crafting.RecipeRegistry.getInstance(RecipeRegistry.java:40)
at com.pahimar.ee3.core.handlers.InterModCommsHandler.processAddRecipeMessage(InterModCommsHandler.java:53)
at com.pahimar.ee3.core.handlers.InterModCommsHandler.processIMCMessages(InterModCommsHandler.java:27)
at com.pahimar.ee3.EquivalentExchange3.handleIMCMessages(EquivalentExchange3.java:199)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at cpw.mods.fml.common.FMLModContainer.handleModStateEvent(FMLModContainer.java:540)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at com.google.common.eventbus.EventHandler.handleEvent(EventHandler.java:74)
at com.google.common.eventbus.SynchronizedEventHandler.handleEvent(SynchronizedEventHandler.java:45)
at com.google.common.eventbus.EventBus.dispatch(EventBus.java:313)
at com.google.common.eventbus.EventBus.dispatchQueuedEvents(EventBus.java:296)
at com.google.common.eventbus.EventBus.post(EventBus.java:267)
at cpw.mods.fml.common.LoadController.sendEventToModContainer(LoadController.java:194)
at cpw.mods.fml.common.LoadController.propogateStateMessage(LoadController.java:174)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at com.google.common.eventbus.EventHandler.handleEvent(EventHandler.java:74)
at com.google.common.eventbus.SynchronizedEventHandler.handleEvent(SynchronizedEventHandler.java:45)
at com.google.common.eventbus.EventBus.dispatch(EventBus.java:313)
at com.google.common.eventbus.EventBus.dispatchQueuedEvents(EventBus.java:296)
at com.google.common.eventbus.EventBus.post(EventBus.java:267)
at cpw.mods.fml.common.LoadController.distributeStateMessage(LoadController.java:266)
at cpw.mods.fml.common.Loader.initializeMods(Loader.java:700)
... 15 more
A detailed walkthrough of the error, its code path and all known details is as follows:
---------------------------------------------------------------------------------------
-- System Details --
Details:
Minecraft Version: 1.6.2
Operating System: Windows 7 (amd64) version 6.1
Java Version: 1.7.0_09, Oracle Corporation
Java VM Version: Java HotSpot™ 64-Bit Server VM (mixed mode), Oracle Corporation
Memory: 338186032 bytes (322 MB) / 491847680 bytes (469 MB) up to 491847680 bytes (469 MB)
JVM Flags: 2 total; -Xms512m -Xmx512m
AABB Pool Size: 0 (0 bytes; 0 MB) allocated, 0 (0 bytes; 0 MB) used
Suspicious classes: FML and Forge are installed
IntCache: cache: 0, tcache: 0, allocated: 0, tallocated: 0
FML: MCP v8.04 FML v6.2.57.845 Minecraft Forge 9.10.0.845 4 mods loaded, 4 mods active
mcp{8.04} [Minecraft Coder Pack] (minecraft.jar) Unloaded->Constructed->Pre-initialized->Initialized->Post-initialized
FML{6.2.57.845} [Forge Mod Loader] (minecraftforge-9.10.0.845.jar) Unloaded->Constructed->Pre-initialized->Initialized->Post-initialized
Forge{9.10.0.845} [Minecraft Forge] (minecraftforge-9.10.0.845.jar) Unloaded->Constructed->Pre-initialized->Initialized->Post-initialized
EE3{@VERSION@ (build @BUILD_NUMBER@)} [Equivalent Exchange 3] ([1.6.2]ee3-universal-preh-1.6.jar) Unloaded->Constructed->Pre-initialized->Initialized->Errored
I was half tempted to clone the source and try to track it down myself, but I figure that's probably not the best introduction to minecraft modding...
Same problem here. IDK why the problem happens, because it's fine in my dev environment. I got the same error when I used my own compiled EE3 version in my custom mod pack.
AbstractMethodError, as defined by Java:
Thrown when an application tries to call an abstract method. Normally, this error is caught by the compiler; this error can only occur at run time if the definition of some class has incompatibly changed since the currently executing method was last compiled.
Basically some code is trying to call a method or class that is abstract (meaning it is designed to be 'extended' with actual code and has 'none' within the actual method, i.e.:
at com.pahimar.ee3.core.util.RecipeHelper.populateWildCards(RecipeHelper.java:42)
as defined after the 'caused by'.
I suspect what is happening is that LoadController.trasnition(LoadController) is expecting some code from RecipeHelper.populateWildCards(RecipeHelper), but the latter does not contain actual code... but, I have not looked at the code so I cannot say with any certainty. (realistically, one would have to look through the code to see what method was: "public/private abstract (some return class) <methodName>(<someInput>);" to determine where the error is coming from.)
0
I know the email isn't being put into spam, I've checked (at least) three times. And, unless the Mojang system is stupid, it should be being sent to my email-instead of anyone who may have attempted to hijack the account-as it still recognizes my email... I just receive nothing when trying to contact them or reset my password.
I imagine that more people than those who are voicing their concerns on these forums are experiencing this issue, which might explain why response time is slow... And to those getting annoyed that we are continuing with what you may see as a farce... it is important that others who experience the same or similar issues have a place to see that they are not alone in these issues. While it is certainly true that there are those who do not know how to do the 'automatic' steps to get their accounts back-even if due to user error-more than enough do know, or are smart enough/willing to look up instructions. This is, or should be, for the rest of us who have already tried the simple steps that are routinely repeated to people with 'lost accounts' complaints...
(If I misinterpreted your comments, then I do apologize, but, while I certainly recognize that this is a 'fan-base maintained unofficial' forum, it is still necessary for those of us who are experiencing 'different' account issues to know that we are not, necessarily, alone or unique. Regardless of whether anyone on this site can actually do anything about it or not, the sharing and pooling of information alone helps.)
0
0
Frankly, I do not feel the need to go into my anti-virus and firewall (not to mention anti-malware, anti-spyware, etc), when I can simply say I am majoring in Computer Science in college and I went through the 'basics' of maintenance and repair in High School... If this were 'my fault' then a lot more than Minecraft would have been compromised.
So, no, it isn't just them... as you can clearly see there are more people here saying that they have had similar happen to them.
0
Yeah, I knew it was separate for each room... but at least this will give me the option to remove the monoliths until/unless stevenrs11 decides to allow us to via config.
Honestly, I don't 'really like' cheating... but I hate "You are where you should not be" instances even more. To quote a television show (which is probably quoting something else), "if they really didn't want [people] getting into it, they should have built it better." Far less applicable to this mod (for reasons I have asserted before), and more so to World Of Warcraft. (If I'm going to spend ~> 30min jumping in one location trying to 'catch' on that 'sweet spot' to get a few inches up a hill to get to an area they thought had been blocked off, I kind of deserve to be able to explore the completely and utterly empty area I just managed to get to... Honestly, what harm is there in exploring a zone with literally nothing in it? (Developer island? I can understand blocking us from that - sort of, but Mount Hyjal, not so much.) Also, I haven't played since Wrath, so, yeah, I know all of these places are 'open' now.
Anyway, I'll backup the files and modify them, until/unless the dev decides to grant us the option within the mod. (I just noticed that Morph has the ability to set when players can fly with morphs that can fly. The ONLY reason I noticed this was because something else set it differently--I had thought it was a bug...)
Also, there are some dungeons that players cannot get past with bat morphs. There is one where, as soon as you enter it, a series of pistons begin bringing the walls closer into you, with lava falling behind them. Under the floor in certain places there are loot chests. Surrounding the dungeon is bedrock. -- For this dungeon I have a suggestion: replace the bedrock with the block that teleports players back to the real world (the red block that is at the bottom of limbo) so that players with fire resistance cannot simply walk on/next to the bedrock. Personally I think this block being added to dungeons is a better choice than Monoliths as they can be avoided but they also give the feeling of falling into a void. If, perhaps, a similar block were created that literally 'sucks' you into it like a black hole (think the holes in Fez) these could be put around dungeons in addition to monoliths (and then you could give us the option to disable monoliths). The idea is that surrounding the dungeon is 'empty space' and if you fall into the Vanilla void you enter limbo... well, why not 'fall' more than just down?
EDIT: Also, I keep forgetting to ask this, could you please add a list of the commands available from this mod to the first post? I have searched this thread for them, but all of the ones I have found do not work... (like the cleanup command-which clears dimensions not connected to other dimensions-, for example)
0
Granted. And I was merely bringing this up because, in the event you felt as though it was a requirement for you (as it appeared with EE2/3), I wanted to assure you that the concept is entirely optional. I am glad you want to extend compatibility.
Secondly, as stated before, some dungeons do not have monoliths, some do... I am wondering if you would be willing to share where this data is stored. If I can 'screw up' my game files without doing so for anyone else, that would be the ideal situation (well, really, you giving us the option would be the best ideal, but I can understand why you choose not to).
CubicChunks (http://www.minecraftforum.net/topic/1707097-cubic-chunks-reduced-lag-infinite-height-and-more-nearly-three-thousand-supportersupdated-feb-3rd/) is what I was referring to. Here, of course, I am assuming something is actually happening with this mod, and it isn't just a theory/fantasy thread.... (without downloads it is kind of hard to tell...)
But, inevitably, for stability, you are correct that for this to be done in the best manner possible, it needs to be done my Mojang... which is sad because they have given plenty of evidence that they do not really know the correct way of coding with Java... A lot of issues that modders have come across, and Minecraft itself should have been resolvable with 'proper' usage of Java (i.e. Deprecation, API, etc).
However, you are inaccurate in one regard. While it is true that Save Game files are written, created, and stored in a specific way you yourself have proven that this is not the only way. Beyond storing structure in separate files, mods that create 'bags' and similar link external files to the bag's inventory. This is exampled not only in the fact that 'logging in' anonymously (i.e. not being able to log in and playing Minecraft anyway) will clear out the bags inventory, but also in the fact that you can access these files-whose data would normally be stored in the save file(s).
Similar could, in theory, be done with block placement. Archimedes ships (http://www.minecraftforum.net/topic/1857899-164-152forge-archimedes-ships-v14-passenger-seats/) is exampling this by converting the blocks into (connected) entities and back. (now, it is certainly true that compatibility with other mods has been an issue with this mod as things like pipes seem to reinsert themselves improperly, but that is an issue that could be resolved 'fairly' easily...)
Finally, with regards to the game I referenced (Prey: http://www.3drealms.com/prey/) took a game engine and did with it what the game engine was not designed to do (similar with Portal). id's Doom3 engine was not designed to store model and level data in the same location, without transitioning by removing and replacing, and yet this is exactly what Prey did. Prey added the ability to store two sets of information in the same location at the same time and simply transition between the two when moving through a specific space in a specific way.
Similarly the same should be possible with Minecraft-while certainly difficult to implement.
Let's say, for example, that you continued storing the dungeon information in a separate dimension (which would be the easiest way to do it right now). Well, we already know, via 'world leaks' that these other dimensions can be loaded at the same time as some other one. Now, all we would have to do is figure out a way to super-impose these chunks (or, to be more accurate, simple block data) over the data that is currently in the world. Because Dimension (A) and Dimension (B) can be loaded at the same time, and therefore the data is readily available (i.e. you don't have to go through a 'loading dimension' screen) super-imposing the information from one location in RAM should be fairly simple. In fact, there are mods that do something-like this already. QCraft (http://www.minecraftforum.net/topic/2035719-164forgesspsmp-qcraft-quantum-physics-meets-minecraft-updated-with-inter-server-teleportation/), Carpenter's Blocks (http://www.minecraftforum.net/topic/1790919-1516forge-carpenters-blocks-v202-slopes-stairs-and-more/), among others are mods that add a 'similar' ability (that being having multiple blocks data within one block's location).
Realistically, the hard part would be telling the game how and when to show a specific set of data as opposed to another specific set of data without transferring the player to an alternative dimension. I believe that using similar coding as QCraft would allow for this (by specifying a cubic region as 'in this location' and a 'doorway' that transitions from 'location' to 'location'... then having the visible blocks in that 'location' be the ones stored in the alternative dimension (again, until there is a better/alternative method of storing block data).
I guess it would go like this: Player is in overworld (block data is stored normally), player sees doorway and walks through-as the player passes through doorway the system is told that the visible and intractable blocks are now from a different specified set (from another dimension, for simplicity sake). When the player leaves by the same door, or by a new door the system is told to render (and interact with) blocks from the overworld/a different location.
I'm sure you are wondering how this would be beneficial rather than loading a new dimension each time (which is certainly easier). Assuming you could eventually change the data from dimensional saves to simple text-file saves (which is basically the same thing) the amount of data loaded would be vastly smaller. It would also allow you to store all dungeon information in one location (i.e. a single dimension) rather than creating a new one for each dungeon-while still preventing players from simply breaking the walls and walking into another dungeon. The 'load time' would also be smaller as players would not have to sit through a loading screen to go from one dungeon to another.
Finally, I certainly understand if you are not willing to do this. If I were 'capable' of coding it myself I would (and then give/lend you the code), but, well, various 'disabilities' make coding extremely difficult for me (even though I spent four+ years learning Java/C++)... I just, get lost, and figure it better to 'start over' too frequently. (I tried learning Japanese, for various reasons, and while, what is typically the hard part for most western language users-the sentence structure-was child's play for me, the vocabulary still is nearly impossible [i.e. I can read Japanese given a dictionary, but even with a dictionary I cannot produce Japanese...])
0
My comment about that mod was less about the gravity aspect and more about the camera movements. There have been many a mod for various games that have tried to do things 'upside down' but have failed to change the camera angle when changing the character model orientation. This mod shows that it is possible within Minecraft to change the camera orientation--and apparently fairly easily.
The primary reason I brought this up was because Dimensional Doors is about pocket dimensions and the long lines of dimensional dungeons. Would it not be more convenient if, instead of creating a new 'dimension' (world, really) each time, we could simply place the pocket dimensions/dungeons in a different W axis from the others?
In other words: Instead of loading a new world each time, if there were a simple shift in orientation of blocks-such that a block on W axis (1) did not interfere with block on W axis (2)-then it would be possible to have, at the very least, pocket dimensions in the same 'world' as the 'overworld'.
Unfortunately, while I know it is possible, I am not entirely sure how to go about doing it. Again, I brought up CubicChunks last time because that mod (if ever finished) will allow this to be done much more easily as it modifies how chunks are created and loaded... But I do know that it has to do with Octrees (http://en.wikipedia.org/wiki/Octree). Simply adding a ninth node would allow for a W axis. ... Again, I haven't a clue how to go about doing this in Minecraft, and I am sure this goes WAY beyond the scope of this mod... but I think it could certainly benefit from something along these lines.
A final note: With Morph, among other mods, realistically Monoliths are literally the only way to prevent players from breaking the concepts of this mod. Lava, fire, even explosions (if you carry around a bucket of water, or two, with you) can be avoided. My point is that there is really no point, given the expansiveness of the Minecraft modding community to try and come up with an answer to every possibility. I would much prefer if mod developers focus on making their own mods work, work well, and interesting, than attempting to 'fix' compatibility (which isn't broken in the first place) with other mods. The exception (of course) is when mod A depends on mod B, or is derived from... Mods that are meant or designed to work together should be, well, designed to work together... mods that are not explicitly created together shouldn't have to be completely aware of one another...
(Like the case with Morph. The developer has been working to incorporate mobs from other mods, and the abilities those mobs should have. This is all well and good, and nice... but simply adding an API through which other mod developers could give their own mobs said abilities within Morph 'would' be enough, in my opinion. True, this would make it up to other mod developers to incorporate their mobs into Morph, which means that some mods wouldn't have compatibility-as some people clearly think Morph is overpowered-but it would be solely under these circumstances that the dev of Morph would really 'need' to add compatibility-and he could be yelled at for doing so then, anyway...)
0
and
While I believe it is obvious that I agree with XombyCraft, I would like to make this standpoint evident as well. I was one of the people who fought for Equivalent Exchange to remain the way it was (in EE2) and that it wasn't overpowered... by which I mean the addition of other mods did not make it overpowered, and it was not the responsibility of the developer(s) of EE2/3 to 'fix' what other people saw as imbalance.
In all realism when process A creates some amount of a resource, and someone comes by and makes process B which produces more of that resource... process B is not an imbalance (by nature) nor overpowered (by nature). Grinders, saws, power generators, etc, these things produce less waist when processing one resource into another and therefore produce more of the resource than the first one did...
By extension this made the backwards conversion of secondary resource into primary resource imbalanced because you could take half an iron ore (the ingot produced by maceration) and produce a new iron ore... But that was neither the 'fault' of EE nor of the other mod. Minecraft itself has no sense of weight, and therefore no sense of waist (yeah, there are things that go beyond conservation of mass, but it is the easiest to implement
Anyway, the reason I bring this up is because of what XombyCraft said. In Minecraft a game you didn't code, design, or produce-but which you are modding-has code you do not controll-you are modding it after all. I use the Morph mod. I always get a bat morph as quickly as I can... I can simply fly over traps.
Does this mean you should find a way to disable morph mod in your dimensions? No, not really. YOU should not be held responsible for 'maintaining' interactions between your mod and others... unless those interactions are critical game-breaking crash-to-desktop bugs... and these are not. If you try to maintain all interactions then you are invariably saying that you know better, and are better than not only the other mod developers but your users as well (sure, in some -if not many- cases this may be true, but people don't like to hear it...). This is an issue that GregoriousT (of GregTech) has run into and one of the primary reasons people don't like him or his mod. It's a pity because his mod adds a lot to Minecraft, but it also removes a lot from other mods (and Minecraft). Example: To make some of his machines useful he doesn't take the 'normal' approach of "mechanical process -> more resource" but the abnormal process of "original process -> less resources". This is wrong. This is overextending the bounds of mod development in an open environment meant to interact with other mods. If it were a total conversion (see TerraFirma Craft), then it would be different, but GregTech is a IndustrialCraft addon and IndustrialCraft is meant to play nicely with other mods...
How does this relate to you? Merely by example: you needn't worry about how other mods play with yours on a fine level. True, if your mod starts 'leaking' into someone else's world, or the other way around, that is a problem... but trying to control every iota of movement within your mod's domain is a needle-in-eye process. It's painful and best left to those who are doing it professionally (i.e. if you want this level of control graduate to making your own games. You'll feel better and have the level of control you desire-period, no ifs, ands or buts. Your game, your rule. This is not the case in a mod, nor, really, should it be.)
Do I think you should stop making this mod? Certainly not. Making your own game would be awesome, I could certainly see a full length game with this concept (does it exist or did you draw inspiration from elsewhere?) But the mod itself is also very interesting.
All I am saying is to not expect (or demand) the level of control you appear to be forcing upon yourself. That's right, not upon us, but upon yourself. We the users can and will find a way-sometimes unintentionally, other times intentionally, to get around what you do be it via other mods or our own code/behavior... but that isn't your fault or your failing... it is the beauty of Minecraft (as a 'open' mod game).
Summary: If you believe it is your responsibility to 'fix' player movements to 'debug' your mod. I think you are going about this wrong... at least within the 'development environment' that is Minecraft mod making.
If, on the other hand, you enjoy finding solutions to players breaking your boundaries, feel free to continue looking.
One final thing: I knew there was a way to change perspective in Minecraft (i.e. turn the camera at a different angle) and I've been proven correct with the 'StarMiner' mod (look up the YogsCast video on it). I also know there is a way to use a, let's-call-it, 'w' axis in Minecraft to change the location of objects placed over one another. I'm sure 'eventually' I will be proven correct for this as well (at the very least it will be easier if CubicChunks is ever finished). You would benefit greatly from this, as it ties in directly to what you are doing.
If you have ever played 'Prey' you will know what I mean. Portal does something similar, but Prey's usage of 'W' axis is mind blowing.
0
You are right. I probably have a lack of knowledge of their mechanics. It is also probable that you have since changed their mechanics as, before the current version I had walked back into dimensions and been instantly teleported away--if this has changed I am very appreciative. It is also true that I do not know the challenges you went through to find a way of controlling players movements. You did send me a message about this although if you are willing to give more information I would love to hear it.
All in all, I really shouldn't complain about a possibly updated feature that may have been fixed/changed since I only recently updated the mod... Still, they are the (current) most annoying part about the mod...
Really, the thing I was coming here to talk about was dimension generation as if the data becomes corrupt it can crash the game. (i.e. if the file[s] are lost entering that dimension will crash your game). I've seen the content of the files and I think a way of fixing this would be to force generate the dimension again if the file is missing. The information about what is connected is still there (in the other files), but the content of that single dimension is gone... (and adding a title to the dimension as well as coordinates for the doors would allow the mod to know exactly what type was there before).
Obviously what you do with this information is up to you. Simple way to replicate this 'bug' is to enter a dimension, leave, quit the game, delete the dimension, and try to reenter the dimension.
Lastly on the new recipes. I think they are ok... I understand why you would move away from ender pearls/eyes... but having a way of, perhaps, crafting a rift to get the string (but decimate the terrain around it) would be useful for those who either have yet to find one or would have to travel tens or hundreds of chunks to get to the closest one. This is, of course, unless you made them more frequent--but that would still require regenerating a world.
0
(Note, started replying to the next person in after this quote... ouips...)
I am fine with people liking Monoliths. I have no problem with them in the Mod, as an OPTION. In Limbo they are optional, why cannot they be elsewhere. If we want to walk around 'empty' worlds, why not give us the option to do so.
Besides, you cannot use Safari Nets or Lasos on Monoliths unless you can sneak up on them, and if I were willing to do that much work I could just quarantine them. It is also possible to use Turtles to decimate the dimensions, but that requires returning to that dimension to retrieve the turtle, at which point you'll be teleported out. --(note: however, that it is true that I only recently installed the version from their, what is it, GetHub? so they may have changed the delay in teleportation and the fact that if the monolith eyes are already open they will insta teleport you when you enter the dimension... which happened to me far too often when trying to edge around them...)
'The' way to play Minecraft is an open ended sandbox world. It is the way the game was designed, it is the way the game that Minecraft was designed from was designed (at least up till the point it was abandoned, who knows what it was really meant to be) and it is the way it has continued to be maintained. Adventure mode exemplifies this as an entirely different mode was added for those people trying to add things to the game the engine was not designed for. A simple mod isn't going to change that... not one the size of Dimensional Doors (it isn't a total conversion), and no, it isn't designed as you say because we aren't forced into Adventure mode with unbreakable blocks around us.
There are better ways to get around players breaking through your carefully crafted dungeons, and placing a insta-teleporter in is by far not the best option. A post further down is vastly superior to this concept because the way it is tricks us into thinking that we 'can' get past the monoliths. And, sure, if we really want to put forth the nonsensical effort, it is possible to quarantiene the monoliths, or capture them and bring them to the overworld (where they automatically die), but since we have the 'option' to turn them off in Limbo, why not allow us to turn them off completely. If the dungeons are really not meant to be stripped for resources why use redstone and stone brick, why not use something unminable, or purely decorative?
Now, don't get me wrong. I'm not saying anyone else's way of adding to the functionality of Minecraft is wrong. But you cannot honestly say that Minecraft is a first person shooter, or first person adventure game. The engine simply doesn't support that belief... unless HEAVILY modified (which it can be by the grace of Notch, as he has decided not to sue anyone for blatantly violating his copyright claim or terms of use).
If this mod is meant to be a 'first person Adventure' game mod, then force us into that. Don't try to force the engine to do something is is blatantly not designed to do.
While Minecraft is a lot like Garry's Mod of Half Life 2, it is also far superior in the way people can modify the code for Minecraft far more (and far more easily) than they can for Half Life 2 (and certainly Garry's Mod, which uses a Scripting Language to add functionality) While I won't get into the specifics of this it has to do with the accessability to Java over C++ and the fact that decompiling Java, modifying it, adding to it, etc, is much more readily done than C++...
Besides, if we really are not meant to be able to tear down the walls of the pocket dimensions then why not use command blocks to stop us? Adding that functionality to the doors should be fairly simple and would allow the developer to force us into adventure mode when entering and out of adventure mode when leaving their content... They could go further and add code to kill or teleport anyone not explicitly in adventure mode so using commands to go into survival would not work...
So, while you are correct in "it's ONE (perfectly valid) way of playing" and 'technically' correct in speculating "This is not THE way minecraft was meant to be played" you are also technically wrong when looking at the evidence of the Minecraft engine and how it was designed. Minecraft is a sandbox survival/creative game. That is the way it was created, that is the way it has always been. Adventure mode was only tacked on later when the developer (Notch, or Jeb) noticed people were attempting to use the engine for 'adventure games'. This is not what the game was intended as, so he 'tacked on' an ability for map makers to add 'special' content to the game... in the form of 'maps'. Yes, this can be done in the normal survival/creative game as well, and would be better utilized than the current method.
Finally, I am not requesting the removal of Monoliths, merely the ability to do so. We can remove them from Limbo, why not from elsewhere? (or are you going to tell me, quite contrary to your own conviction, that 'your' way of playing is the only correct way? That's what you'd be advocating if the mod absolutely most follow one direction, one path...)
Honestly? Yes. If these pocket dimensions are only meant to be pathways between one another with small sparse loot within them, then I would rather them be limited to such. But, especially if they are meant to solely be merely pathways between doorways with sparse loot within them then they really do not need a separate dimension for each dungeon... (for a pocket dimension, sure, we can modify those and are obviously meant to do so, but not for the--as you are all suggesting--unmodifiable dungeons.)
If we truely are not meant to break the walls and collect anything within them that we want then there are vastly superior ways of doing this than Monoliths. Monoliths are a great idea, they are terrifying and look cool, they have interesting effects... but if we are supposed to be able to modify the terrain within the dimensions their abilities are overpowered (a word/term I loath to use), and if we are NOT meant to be able to modify the terrain, then, again, there are vastly superior-coding wise and time wise-ways of preventing us from doing so... and I would prefer those ways to holding onto the belief that I can do anything other than run from point A to point B in the pocket dungeons...
I am NOT asking for Monoliths to be removed completely... not even partly, I simply wish to be given the option to disable them from my game and my world.
If that isn't an option then perhaps a competitor is required for this type of mod. (Obviously not a rip off, but something of similar nature: See GregTech vs FuturologyMod (http://forum.industrial-craft.net/index.php?page=Thread&threadID=10209). I honestly hope the developer is more openminded than Gregorious (almost anyone would be given past issues...) and I really hope the community here is more open minded than those who killed Equivalent Exchange. (It may still be kicking and sputtering, but it is nothing like its predecessors, and will not be for months/years to come...-which I don't blame the dev, he got married... but it is still the community that killed it).
Here, I should say one final thing: how many of you play the games you buy only on the hardest setting (available, some require you to finish easier settings to 'unlock' harder ones)... Ok, how many of you only play one 'game mode' in the games you buy (obviously of those with multiple game modes)? Ok, how many of you limit yourselves to a direct line path from beginning of game to end--i.e. speed-running--before playing anything else of the game first-or later?
I'm not suggesting we limit our playability of games, I am suggesting that people who expect one thing, and only that one thing are keeping their minds narrow and their experiences narrower. Minecraft is open-world and sandbox. It is the definition of what I am suggesting (true, we haven't been given a menu option to disable creepers yet, but we can very easily go into a single player world, open it to lan to TEMPORARIALLY enable cheats, /gamerule mobGriefing false, and be done with creepers destroying hours of work, my point is we have been give the options to enable what we like and disable what we don't. THAT is what Minecraft IS about. Anything else is a single person's attempt to force their view on us--by which I mean mods without options to enable/disable things at least in a config file... even Gregorious [GregTech] gave us numerous options within a few config files... [I use him because most people complain about the difficulty of his mod and how it changes other mods as well... which it does, beyond IndustrialCraft, regardless of his claims otherwise:: preventing Tin Buckets also prevents Metallurgy Buckets... if you no like tin -> Iron conversion rename the damn bucket...)
0
It isn't about making a 'home' in them. It is about wanting to utilize Minecraft the way Minecraft is designed. If a space exists you can destroy and utilize it. All the stone bricks, etc, and especially redstone in those worlds is basically wasted.
Not only that but sometimes the monoliths spawn in dimensions that are not completely enclosed, so walking around becomes impossible without extreme care of blocking up your sides as you move--possible, if barely.
I just believe that there are better ways of utilizing the structures in Minecraft than making an 'unbeatable' entity that simply 'teleports you away' when you 'break the rules'...
Also, the links themselves were not missing. The text file describing the dungeon in the dimension-as well as the terrain for the dimension itself-was missing. File corruption happens, although in this case it was my fault, but it does happen. If a person is using pathways through dimensions, when a branch is lost that person is screwed...
These things should be reasonably rebuild-able given the text files describing the dimension before and after the given lost dimension, even if the exact layout is not.
Finally, with regards to Monoliths, anything else in the game I can eventually get past. Ender Dragon too difficult, get better armor and enchantments... Can't mine a specific ore, get a better pickax... Machine too costly to build, go mining for a few hours... But the Monoliths are specifically designed to be impossible. Honestly, it would make more sense to force the player into Adventure mode and have a check to kill them if they change mode while in a dungeon dimension. That's basically what the Monolith is.
I've experienced this as well. A door slams shut as I try to enter it, preventing me from going through. Eventually I am able to pass through, but I am unsure of the cause.
0
EDIT: And... crash... Ok, looking up that url now.
Edit: Final clarification: This problem I have is in no way your fault. It is due to my own stupidity and ineptitude (I should have had the bucket out and 'working' before I entered another dimenion, period...) I was just hoping to notify you of how I broke Minecraft and see if you wanted to put precautions into place to prevent others from trying the same.
0
I didn't know that. Thank you. That it removes the 'broken' at 100% makes my request moot.
0
The auto-repair feature from moss is broken. Sure it will repair tools before they reach 0/<some number> but if they become 'broken' they will still regain durability but remain 'broken'. This is a bug. Please either make it so that when they reach 0 durability they no longer repair (which is stupid) or allow them to become un-'broken' when they repair that '1' durability.
Note: The reason I say it is 'stupid' to prevent 'broken' tools from repairing is if you have any other mods that modify the usage of durability of tools or weapons (like treecapitator) as they will often bring your tool/weapon down to 0 in unexpected ways or at unexpected times. Then, if you are like me, and wait for the tool to 'repair' itself... you will end up wasting materials in the end to remove the 'broken' modifier from it.
So, please allow tools that increase durability to un'broken' themselves.
The interaction I referred to at the beginning where people discussed this is as follows:
0
It's about damn time. I've been suggesting this since 1.2.somthing... Some idiot said that it would make the files too big, but, realistically if you preface the map saves with these numbers and then set them to numerical digits (to make the file size smaller) on a per map basis, it would have the same size consequences while reducing the screw-ups we get with IDs....
0
AbstractMethodError, as defined by Java:
See: http://docs.oracle.com/javase/6/docs/api/java/lang/AbstractMethodError.html
Basically some code is trying to call a method or class that is abstract (meaning it is designed to be 'extended' with actual code and has 'none' within the actual method, i.e.: ).
The two methods causing this issue are:
as defined in the first line, and:
as defined after the 'caused by'.
I suspect what is happening is that LoadController.trasnition(LoadController) is expecting some code from RecipeHelper.populateWildCards(RecipeHelper), but the latter does not contain actual code... but, I have not looked at the code so I cannot say with any certainty. (realistically, one would have to look through the code to see what method was: "public/private abstract (some return class) <methodName>(<someInput>);" to determine where the error is coming from.)