Here is the modified code I’ve been using:
https://code.google.com/p/cubesmod/source/browse/modified+cubes+2.zip
Feel fry to use it for any purpose. I have only one stipulation: if you do end up using this, PLEASE tell me about any fixes/changes you perform so that I can also implement them.
The system is now multithreaded and significantly more stable than the last version. Because I have not yet implemented a mesher (had something bigger to make work, it should come in the next update or three) once the local area has been loaded, runs at around 150 fps. While loading new areas, typically runs at 10-40 fps, but remains more or less playable.
Here’s the function I use to set up the player: (my final variable worldScale is set at 2, I think)
[java]
/**
* sets up the player/camera
*/
public void setUpPlayer()
{
characterNode = new Node();
player = new BetterCharacterControl(.5f * worldScale - .1f, (2 * worldScale) - .2f, 81);
player.setJumpForce(player.getJumpForce().mult(worldScale * 1.5f));
//player.setJumpForce(player.getJumpForce().mult(worldScale * 20));
player.setGravity(player.getGravity().mult(worldScale * 6f));
//player.setGravity(new Vector3f(0, 0, 0));
characterNode.addControl(player);
Vector3f playerLoc = new Vector3f(90010, 90150, 90010).multLocal(worldScale);
//Vector3f playerLoc = new Vector3f(blockSettings.offset, blockSettings.offset, blockSettings.offset);
player.warp(playerLoc);
rootNode.attachChild(characterNode);
bulletAppState.getPhysicsSpace().add(player);
}
[/java]
@Eliwood said:
Yeah, I've done the hashmap of chunks - that was pretty clear to me that I'd need it. And I went and did a whole lot of testing compilation online (stuff like looping and printing different operations on integers, 1 - 32 and -1 to -32) but I couldn't nail down what I wanted to do.
If you’d share the code, I’d greatly appreciate it! The infinite terrain generation in positive directions works just fine, in mine, and I’ve managed to get purely negative coordinates within a block of where they’re supposed to be - I’m guessing I’m getting hangups on 0 and -0, maybe, or something like that. Not sure.
Currently, the way I do that is taking the position, and if any of the axis’ are negative, add the negative value (so subtract) from the size of the chunk, and also subtract 1 more to compensate for 0 - 15 index.
If I can’t figure out how to get negative indices working, then an offset may well be the only way to go about things.
@toolforger said:
It's better to fix those bugs, rather than fix the symptoms.
Partly because the next one to hack on the code might be bitten by them.
Mostly because they might cause less conspicuous behaviour that will be even harder to connect to the actual bug site.
pspeed’s advice is a good one to look for.
The other would be to set up some minimal example that shows undesired behaviour, find out what values in the data are erroneous, then find out what code generated the erroneous value. Work your way backwards until you find the actual culprit, then fix that.
This can take quite a while (a day or two, more if you’re unlucky), and it won’t give you any new features, but it does wonders for what people will later describe as stability or reliability, so it’s still worth it, just not marketable
I fought with tooth and nail to iron out that bug, but I think i’m not quite experienced enough… I agree, I’d much rather cure the bug than the symptom. I even narrowed down where it was occuring, but the whole thing was so odd that I couldn’t solve it.
I called setBlock from my terrain generator, and it worked fine. I called setBlock from my main class, and it tried to fix stuff at the correct coordinates, but either didn’t do anything or modified a completely erronious block. The whole thing was so bizarre that eventually using an offset became my only viable option.
If any of you happen to fix that problem (offset can be countered by modifying the following line in all of the noise generation functions), tell me how. I’d much rather not use an offset.
if((y + yOffset) <= ((noiseValue) + settings.offset))