Gameplay
Cubic Chunks: Reduced lag, infinite height, and more [The #1 Suggestion Thread of all time!][Updated! 6/14]
Poll: Which parts of this system do you like?
Ended May 15, 2014
Poll: Which parts of this system do you NOT like?
Ended May 15, 2014
Poll: Do you support this system's implementation overall? (If yes, if
Ended May 15, 2014
How are you making the mod? Straight from the obfuscated code (If you are, HOW?!?!) or with forge or forge gradel? If you use forge, can you not just apply a re-obfuscate and put that on github without any copyright issues?
Support!
I didn't think you were using Obfuscated code(That would be crazy). So which version of forge are you using, 1.6.4 or 1.7.2? The last time I checked 1.7.2 it never actually decompiled the minecraft code... And how stable do you think your version of the mod is? Are there any lag/lighting issues?
How do you even do what you need to do with Forge? Wouldn't it be far easier to just modify base classes? I once looked at how to use Forge to modify basic world generation stuff, but the complexity completely turned me off from ever using Forge to mod anything (e.g. how do I use my own MapGenCaves (which was also merged with MapGenRavine and MapGenBase) to replace the vanilla cave generator (as I asked before with no replies, so I assume nobody else knows)? Or replace Chunk and ChunkProviderGenerate for the changes required to get 3x terrain height, plus a whole bunch of other classes to adjust stuff for the change in height?). In fact, I even deal Forge a slap in the face by inserting my modified classes (a couple dozen) into my Forge-modded game (for some other mods) and forcing it to run the game (-Dfml.ignore...) despite its protests; my FML log is filled with spam like the following:
2014-02-10 18:43:30 [SEVERE] [ForgeModLoader] FML is going to ignore this error, note that the patch will not be applied, and there is likely to be a malfunctioning behaviour, including not running at all
I've never had any problems though despite the claims it makes; I know this is because none of the mods I use access the classes I modified but even a Forge version would still be incompatible with other world-gen mods (after all, can't have two mods with different ideas of what to do with cave generation). Really, though, Forge overreacts when you mod base classes.
Personally, I'd like a base-class modded version of Cubic Chunks so even if the source isn't available I can decompile it and mod my game (1.6.2) to use cubic chunks (I've already done this with other mods to find out how they worked; for example, in order to find out how to generate terrain to the world height limit (pre-1.7 terrain is limited to 128 blocks), I decompiled the Wedge mod, luckily not a Forge mod, and despite being for a very outdated version of the game the code was similar enough to easily apply the changes).
TheMasterCaver's First World - possibly the most caved-out world in Minecraft history - includes world download.
TheMasterCaver's World - my own version of Minecraft largely based on my views of how the game should have evolved since 1.6.4.
Why do I still play in 1.6.4?
Will it be compatible with any forge mod that doesn't edit the same base classes as the ones you modify? Do you plan on using ASM to make it cross compatible.(it might be hard. I have never used ASM, only heard about it)
Don't you think that you should have waited for 1.7.2 version of forge and MCP to fully update to make the mod? Because upgrading from 1.6.2 to 1.7.2 might be harder than actually writing it from scratch on 1.7.2.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumWhat you just said is completely unrelated to the sentence you quote me for.
I don't understand what assumptions you made to get there.
Deterministic ? Yes.
Logic ? No.
You are confusing those two. Computers perform operations and follow deterministic patterns, since they aren't "quantum" (=probabilistic) yet.
Exactly the same as Minecraft does it currently. We don't.
As you said, terrain generation is already done by a set of deterministic operations.
A dev simply has to choose which one by try, guess and luck.
By the way, "natural feal" is a rule you made in your own mind. Which is what I related to "logic" inducing "flat, boring terrain".
Try going to the Nether or the End, and applying your personal rule. There is nothing natural here.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumDeterministic behavior is not based on boolean logic nor any logical statement.
Boolean logic is a form of algebra only fitting the computer numerical system (binary) by design.
Yes, terrain generation is deterministic. (I already said that, didn't I)
I never said that terrain would need to be deduced from the light.
Generate light and terrain follows, I know that doesn't look like obvious human logic (not to be confused with boolean logic, please).
Try to think this way: instead of generating material blocks, generate air blocks with light inside in the first step.
As a Minecraft world only contains those two types of blocks, it is strictly equivalent.
I suppose you missed the part where cubic chunks are thought to be 16 blocks of height ?
Or the part where chunks are supposed to generate around a player, not 20000 blocks higher ?
Or Minecraft "Amplified" world generation, with huge floating lands ?
Or the obvious fact that no player could spot blocks further apart than the maximum view length ?
redistribution of any of mojang's code, modified or otherwise, infringes their copyright.
that's what "you may not redistribute" means in their EULA
emphasis added... should it be required
and legally, that doesn't mean you can share it privately either... it means distribution to anyone.
I hope we find a way to work this in. One more plus; megaprojects being turned up to eleven.
This is intended to be incorporated into Vanilla Minecraft.
i was just replying to the question posted above - which i'd quoted. i understand the concept of the project - no worries there
ONE SENTENCE after what you copied they explained what they meant: "By “distribute anything we‘ve made” what we mean is “give copies of the game away, make commercial use of, try to make money from, or let other people get access to our game and its parts in a way that is unfair or unreasonable”."
They say that mods are OK and even encouraged too.
From the using our game section: "If you've bought the Game, you may play around with it and modify it. We'd appreciate it if you didn't use this for griefing, though, and remember not to distribute the changed versions of our software. Basically, mods (or plugins, or tools) are cool (you can distribute those), hacked versions of the Game client or server are not (you can't distribute those)."
which is what the whole of the EULA part of that means... [and you have simply repeated what i was telling you]
edit - to clarify why i say that in context with what i was replying to, as i guess i'm rubbing you up the wrong way accidentally: you said that you were not sure if distributing something which was 99% their code was allowed... i was saying, erm... i doubt it... hence my trivial smiley face at the end... i wasn't trying to say "oooh, bad mod person" at all far from it... i was just trying to honestly answer what i thought was a legitimate question with what the EULA states about it... nothing "opinionated" [ i thought ]
I can see what you mean by that; I've noticed changes in the code myself when working with the Forge source compared to vanilla source, although in some cases Forge explicitly includes vanilla bugs; for example, in MapGenCaves they account for the fact that in vanilla caves only cut through stone, dirt, and grass (other features added afterwards), resulting in cave openings not appearing in deserts (when I modified it I just removed the code they added since the vanilla code is cleaner and I prevent most caves from cutting through dirt and grass anyway).
Also, as for it being illegal to distribute source code, people do that all the time; for example, here is the first result I found for "minecraft mapgencaves", and in any case it is easy enough to decompile the code (so what makes using MCP to decompile the game different from distributing the source?).
TheMasterCaver's First World - possibly the most caved-out world in Minecraft history - includes world download.
TheMasterCaver's World - my own version of Minecraft largely based on my views of how the game should have evolved since 1.6.4.
Why do I still play in 1.6.4?
-
View User Profile
-
View Posts
-
Send Message
Curse Premiumhttps://github.com/C...ight/tree/1.7.2
Forge does this, the MCP does this... (Albeit hard to read) It's fine.
Minecraft wants mods, so they won't discourage anything that will help their sales. Just don't hinder their sales in the process.
Their Eula has tried to make this painstakingly clear, although if you read the Eula too closely, you could potentially interpret the other meaning.
How on earth do you edit changes like this and publish this into a mod?
1.) Edit vanilla, recompile/reobf, and ask users to replace files inside their jar.
Easy to write, hard to release, and this is very hard to do with the latest mcp.
2.) Two ways in Forge: (but only one is recommended)
- Use Patches, or asm to completely replace classes. Clobber the default Minecraft class on startup, and substitute your own. This takes complete ownership of the class. You can change anything you want, and it will work as long as you coded correctly.
The issues arise when you modify something else that was already modified... you need to be careful how you blindly destroy and replace. (Especially if someone tried doing that even before you got to it.)
- It's recommended to use ASM to submit method replacements and try to subtly change methods. If a major change is required, then you can just ASM the method to call a separate static method in another external class (that you wrote) and pass the instance of this, along with it.
It's a lot of work...If done incorrectly, it turns into mods fighting over which classes to replace....
.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumYou seem to be under the delusion that I disagree with you on this. I don't. Except that rngs are deterministic too.
The difference is so great i thought it was obvious.
Night follows day. Can you deduce night from day ? (It doesn't even make sense in this case !)
For a Minecraft case, see terrain and biomes.
Player's taste isn't part of the procedural terrain generation equation.
If a player wants a specific terrain, there is the superflat type for it.
Terrain generator will set the difference between solid blocks and fully dark air. Light generator doesn't need to care.
Seamless world ? I am a player, and I don't expect that.
You are making up rules here. Rules that doesn't even apply to any default Minecraft terrain I have ever seen.
Yes, I count on multiple solutions being valid for most light cases. That is the whole point of me differenciating light generation and terrain generation in the suggestion. So that terrain generator can work independently after the light generator, bringing more variety into the whole generation, while keeping lighting accuracy. Hence me saying we don't deduce terrain from the light.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumAre RNG's deterministic.
Answer, Yes:
Look at how random registers function on a hardware level or in low level code?
This is a hardware register that holds 8 bits, and when you ask it for a number, they all move one bit to the right. The bit on the far left is created by the states of d-flops U6 through U0
This is simply a logic diagram that generates random numbers.
You "seed" this by giving it a number 0x0000 0000 through 0x1111 1111
Once it's seeded, it gives you a random number, and will continue to do so.
This is why RNG's are referred to as pseudo random. We know what the next number will be if we look close enough, but it's pretty much random. If you're super worried, you can complicate it further, but it's still deterministic at it's core.