The only issue with mod compatibility I can forsee is if we happened to use the same block Id's. Which can be dealt with easily enough with a config file.
And maybe have alternate blocks for each structure that are ones already in standard minecraft.
So if a server owner doesn't want the new blocks, they can just easily set it to only generate using vanilla materials instead.
I was looking at the Mazered texture pack you made. I really like the Bricks, the retextured red jungle wood, those special columns, and especially the Mazeworld blocks.
I was looking at the Mazered texture pack you made. I really like the Bricks, the retextured red jungle wood, those special columns, and especially the Mazeworld blocks.
Thank you. You're talking about the red ones, right?
The red junglewood was supposed to be a proxy I took from my other pack (one I stopped to upload), but I found out I either come back to it or do something horrible.
Any ideas or suggestions?
...and that's why community-developed software is awesome.
It looks pretty awesome, though you seem to have some glitch with the leaves placing at places.
Also, is it me, or modules you're usig aren't 8 blocks high?
Awesome! I don't suppose you'd like to help out with the coding or structure design? I haven't managed to get a whole lot done since I made this thread, what with finals week being next week and everyone and their brother assigning a final project... regardless, I'll probably get back to it sometime next week.
I'm a little curious how you got that one three-module long building to work. Are they actually connected inside?
My guess would be "they just connect to the street modules that rarely, as opposed to room ones".
...there also don't seem to be any entrances in those buildings.
I bet he didn't deal with the staircases yet...
Hm. I never thought, how much of a problem the towers are...
Should they be handled as "extremely special staircases, that generated all the way from the ground and have some rooms attached to them"?
I bet he didn't deal with the staircases yet...
Hm. I never thought, how much of a problem the towers are...
Should they be handled as "extremely special staircases, that generated all the way from the ground and have some rooms attached to them"?
Staircases aren't that big of a deal, it's just a matter of having a module that tall with spiral stairs generating inside. Since towers would be on the top level, you don't even have to worry about dealing with other modules. Having walkways between towers would be really cool, though figuring out just how to do that is a whole different issue...
For the aqueducts I was thinking I could derive some function that creates a repeating grid arrangement, and use that to determine where to make the aqueducts. Since this function would be on a rather large scale, it would be hard to see it repeat itself. Maybe a similar type of function could be used for walkways?
Staircases aren't that big of a deal, it's just a matter of having a module that tall with spiral stairs generating inside. Since towers would be on the top level, you don't even have to worry about dealing with other modules. Having walkways between towers would be really cool, though figuring out just how to do that is a whole different issue...
For the aqueducts I was thinking I could derive some function that creates a repeating grid arrangement, and use that to determine where to make the aqueducts. Since this function would be on a rather large scale, it would be hard to see it repeat itself. Maybe a similar type of function could be used for walkways?
you could always go with walkways, that just go on until they hit another tower, lol.
Me still thinking that writing down pre-occupied chunks/modules in a file would be easiest, But, I guess, there's no way to keep that file from swelling up as the dimension is expanded and more of yet-to-be built structures are added there. Though, it would make it easy to just tell a function of, say, aqueduct "here's your chunks from this height to this, do whatever you want.
Although it would create a funny feeling of every big structure being built, facing the center.
Say, what range of numbers your pseudorandom function has? THough I doubt it'd be possible to roll out on it solely... I guess you need some way of reserving space anyway, unless you're willing to make such a grid for every big structure.
And remember, that refrigerator should be fast like a cheetah, flying like a butterfly and stinging like a wasp.
Well, I ment just "it looks like a house, because it has walls instead of arches outside".
Saving stuff would be good for big pre-determined structures, that should, say, take the top of 9 chunks for itself. You can't really hope to make a pseudo-random function, that will always make these 9 chunks to fit this exact building. So it would be easier to trigger chunk generation in a loop, that puts in all the places of such a building, or reserve the modules for this building. The aqueducts could be made this way randomly since it allows to forget about modules around (after a size check) and just say "I want to have an aqueduct from here and until monday", but it would require plenty of checks upon the 'big structure pieces' to see, what exits should be added in the modules around. Not to mention the amount of rw procedures.
staircases could be generated as a single spire, from which the building grows towards the sides. I guess you have to store rooms in the memory to prevent extra ladders, but that's tricky and would require to write the data to hdd.
Inaccessible buildings could be dialt with by adding a rule to always put an entrance first, but as I said, funny feeling of every building being built, facing you.
Hmm... If I were developing this mod, I would make three changes to your module format/generation.
1: I can't help thinking that generating multi-chunk buildings from the center would be a nightmare. I would go about it from the corners, but that would require rotating the module to fit (which would probably be a needed feature anyways)
2: I would make connection types case-insensitive strings, and allow a module to explicitly define supported types for each side. The default types (0-2) would translate to "wall", "hall", and "room" or similar. This would allow modules that are parts of larger buildings to define special connection types, like "tower-courtyard" or "garden-fence", and would make it easier to cross chunk borders without pre-generating modules.
EDIT: on second thought, this isn't a good way to get around pre-allocating modules, but I think it's a good way to describe different connections, like "3x4_hall" and "avenue", and good for connecting random modules within larger structures.
3: A couple changes to linking: make an option to _attempt_ to place a certain module where specified, but if it fails, just act as though it never tried to link, or optionally, default to a different module (note that this should take rarity or similar into account). Also, allow linking to a folder (randomly picks modules in the folder until one fits), and, if possible, wildcards. For example:
try link 1 0 0 aqueduct.txt 95% default aqueduct_end.txt
link 0 1 0 tower_parts\*
Also I'm a little concerned about the rarity system. If I understand correctly, if one module is particularly rare or hard to place, the next item in the list will be that much more common.
Do note that, while I have a little experience with minecraft modding, I have never once taken a sideways glance at the generation code, and have never worked with anything similar. So it's completely possible that these suggestions are all horrible. I'm just trying to help where I can with a great project
How does your structure generator determine what modules to use? do you actually generate more than a single chunk at a time?
Mine is based on a deterministic random function that generates arrays of module IDs based on the chunk coordinates... so I dont actually have to store anything, i just fetch the module IDs for every chunk i generate, fetch the IDs for the four chunks arround it, flag connections for every module in the chunk, and generate them based on configurable templates.
It is quite random and generates inaccessible rooms or buildings on occasion, but it runs with a decent speed, and has no need to save anything.
I'm now experimenting with perlin noise to get at least some control over building and path placement, but its practically impossible to create large continous structures like aqueducts or even proper streets this way.
If you want to test it, I got a version online (dl here) ... but i wouldn't really call it stable, it has a lot of glitches, and i totally cant grant that it will work xD
needs at least Forge 6.4.1.410...
greets, dref434
It's one chunk at a time, and I use a deterministic pseudo-random based on the seed, as well as the x and z coordinates, to decide how each 8x8x8 cube is going to try to connect to the next one over. That way I can just generate the connection values to check the way neighboring chunks are going to try to connect to the current one without actually generating everything in the next chunk over. This seems to be similar to what you're doing, though I think I'm checking the connections differently.
So, for the larger towers, you actually have more modules being placed overhead, and their connections being figured out? Interesting... I wonder if there's some way to integrate that and the floating walkway idea...
Using Perlin Noise for aqueduct placement... interesting. The trouble with that is it doesn't really produce straight lines; it makes blobs. Though a similar sort of system could probably work.
I'll try to take a look at your code when I get the chance, but I suspect I'll be needing to update everything. At which point, I may as well just copy over the useful code and start largely from scratch, since we seem to have changed what we want... I really should get to work drafting up a proper design document so we can lock that in place.
Hmm... If I were developing this mod, I would make three changes to your module format/generation.
1: I can't help thinking that generating multi-chunk buildings from the center would be a nightmare. I would go about it from the corners, but that would require rotating the module to fit (which would probably be a needed feature anyways)
2: I would make connection types case-insensitive strings, and allow a module to explicitly define supported types for each side. The default types (0-2) would translate to "wall", "hall", and "room" or similar. This would allow modules that are parts of larger buildings to define special connection types, like "tower-courtyard" or "garden-fence", and would make it easier to cross chunk borders without pre-generating modules.
EDIT: on second thought, this isn't a good way to get around pre-allocating modules, but I think it's a good way to describe different connections, like "3x4_hall" and "avenue", and good for connecting random modules within larger structures.
3: A couple changes to linking: make an option to _attempt_ to place a certain module where specified, but if it fails, just act as though it never tried to link, or optionally, default to a different module (note that this should take rarity or similar into account). Also, allow linking to a folder (randomly picks modules in the folder until one fits), and, if possible, wildcards. For example:
try link 1 0 0 aqueduct.txt 95% default aqueduct_end.txt
link 0 1 0 tower_parts\*
Also I'm a little concerned about the rarity system. If I understand correctly, if one module is particularly rare or hard to place, the next item in the list will be that much more common.
Do note that, while I have a little experience with minecraft modding, I have never once taken a sideways glance at the generation code, and have never worked with anything similar. So it's completely possible that these suggestions are all horrible. I'm just trying to help where I can with a great project
There is some rotation functionality built into the module class as it is. Granted, it's used to rotate walls and doors and such so I don't end up typing out four identical copies of the same connections (one for each way it could be facing), but I think it could be used for the whole module as well. But yeah, now that you mention it the math would be easier coming from the southwest (smallest x and z) corner.
I'm a little confused what you mean by pre-allocating modules. Do you mean figuring out what will be in the next chunk by "placing" modules there?
The link thing is a good idea. The wildcard might take a little figuring out on my end, but I think it could be done.
Yes, the rarity system does have that issue. Even more startling is that, depending on the order the modules are put into the array, their odds of being placed change drastically. Consider a long list that ends with two walkway modules:
It picks a random starting point and cycles through. The trouble with this is it will pretty much only try Walkway Module 2 if it lands on it initially, or Walkway Module 1 fails the rarity check. At some point I would like to fix this issue.
Well, actually, we're pretty much scrapping most of the generation code and writing our own. All you really need to know from Minecraft's built in generation is that it's made in chunks.
I'm a little confused what you mean by pre-allocating modules. Do you mean figuring out what will be in the next chunk by "placing" modules there?
Yeah, by that I meant letting the modules "claim" an area in a non-generated chunk, and actually generating them later, with the rest of the chunk. (So basically, as far as the module-placer is concerned, those modules are already there, but the terrain generator would still need to generate them later)
Rollback Post to RevisionRollBack
"Thatssss a nice hole you have there... It would be a sssshame if anything were to happen to it..."
- The Second Creeper
Does anyone actually read what I post? I keep on telling about that "pre-allocation", and that it would be a matter of having a text file (or some other very special way of storing data that, no doubt, someone can come up with) with lots of lines, looking like "chunk X Y height Z module (out of four possible) link to module of big structure". Or maybe rise your own little sql or nosql base just for that purpose, why not? And a generator, that can
A) check if ther are enough not generated yet chunks (last I checked there was some way to do that... gotta lurk more) to fit the pre-allocated stuff in as soon as pseudo-random generator says "put the big stuff here" (considering it can only do so for 1 module, the lazy bum).
check if that space isn't pre-occupied already
C) check if the chunk it is generating has any records like that.
D) allocate more modules if the one, placed, requires, but that leaves recusrsion on the consciousness of module-maker.
Simple and crystal clear. Making towers with guarantee to have randomely generated stairs on every floor is harder.
(I apologize it looks a bit like a runt)
(and okay, okay, back to my puny little tasteless drawings of walls)
Does anyone actually read what I post? I keep on telling about that "pre-allocation", and that it would be a matter of having a text file (or some other very special way of storing data that, no doubt, someone can come up with) with lots of lines, looking like "chunk X Y height Z module (out of four possible) link to module of big structure". Or maybe rise your own little sql or nosql base just for that purpose, why not? And a generator, that can
A) check if ther are enough not generated yet chunks (last I checked there was some way to do that... gotta lurk more) to fit the pre-allocated stuff in as soon as pseudo-random generator says "put the big stuff here" (considering it can only do so for 1 module, the lazy bum).
check if that space isn't pre-occupied already
C) check if the chunk it is generating has any records like that.
D) allocate more modules if the one, placed, requires, but that leaves recusrsion on the consciousness of module-maker.
Simple and crystal clear. Making towers with guarantee to have randomely generated stairs on every floor is harder.
(I apologize it looks a bit like a runt)
(and okay, okay, back to my puny little drawings of style-less walls)
Well, getting the stairs to show up in towers is easy. Getting a larger tower to have stair access from floor to ceiling... bit of a tougher task.
I've been reading what you post, though some of it is a little hard to understand.
Interesting thought I had - what if all the included modules had their own file(s), and users could add more modules by simply dropping module files in? It would involve the same kind of code as the wildcard linking, and could potentially mean that no two Mazeworlds are quite the same (and world generation is all done server-side, so server owners could have quite a bit of fun with this).
And, you still need to differentiate the biomes, so, I'd guess, adding a biome file with list of modules (or just having a unique biome number stated in them all) and a few settings like, say, rarity of the air gaps and the ranges for top-middle-bottom slices (and their vriation, maybe?) would be useful someday. Though maybe not.
It starts to look like a huge heap of text files already, heh. So very linux-like. Or bsd. Or whatever you prefer to dissect in vi/nano/emacs.
All I can think of for the towers, being connected from top to bottom is checking for stirs around and generating one if none found, but that's a tricky thing to make when you're not entirely sure if it's a tower or not. On the other side, would be safe to just leave some places unaccessible.
And maybe have alternate blocks for each structure that are ones already in standard minecraft.
So if a server owner doesn't want the new blocks, they can just easily set it to only generate using vanilla materials instead.
I am a representative of VudooHosting
Thank you. You're talking about the red ones, right?
The red junglewood was supposed to be a proxy I took from my other pack (one I stopped to upload), but I found out I either come back to it or do something horrible.
Any ideas or suggestions?
(terrain/mobs/armor)
It looks pretty awesome, though you seem to have some glitch with the leaves placing at places.
Also, is it me, or modules you're usig aren't 8 blocks high?
(terrain/mobs/armor)
I'm a little curious how you got that one three-module long building to work. Are they actually connected inside?
...there also don't seem to be any entrances in those buildings.
(terrain/mobs/armor)
Hm. I never thought, how much of a problem the towers are...
Should they be handled as "extremely special staircases, that generated all the way from the ground and have some rooms attached to them"?
(terrain/mobs/armor)
Staircases aren't that big of a deal, it's just a matter of having a module that tall with spiral stairs generating inside. Since towers would be on the top level, you don't even have to worry about dealing with other modules. Having walkways between towers would be really cool, though figuring out just how to do that is a whole different issue...
For the aqueducts I was thinking I could derive some function that creates a repeating grid arrangement, and use that to determine where to make the aqueducts. Since this function would be on a rather large scale, it would be hard to see it repeat itself. Maybe a similar type of function could be used for walkways?
you could always go with walkways, that just go on until they hit another tower, lol.
Me still thinking that writing down pre-occupied chunks/modules in a file would be easiest, But, I guess, there's no way to keep that file from swelling up as the dimension is expanded and more of yet-to-be built structures are added there. Though, it would make it easy to just tell a function of, say, aqueduct "here's your chunks from this height to this, do whatever you want.
Although it would create a funny feeling of every big structure being built, facing the center.
Say, what range of numbers your pseudorandom function has? THough I doubt it'd be possible to roll out on it solely... I guess you need some way of reserving space anyway, unless you're willing to make such a grid for every big structure.
And remember, that refrigerator should be fast like a cheetah, flying like a butterfly and stinging like a wasp.
(terrain/mobs/armor)
Saving stuff would be good for big pre-determined structures, that should, say, take the top of 9 chunks for itself. You can't really hope to make a pseudo-random function, that will always make these 9 chunks to fit this exact building. So it would be easier to trigger chunk generation in a loop, that puts in all the places of such a building, or reserve the modules for this building. The aqueducts could be made this way randomly since it allows to forget about modules around (after a size check) and just say "I want to have an aqueduct from here and until monday", but it would require plenty of checks upon the 'big structure pieces' to see, what exits should be added in the modules around. Not to mention the amount of rw procedures.
staircases could be generated as a single spire, from which the building grows towards the sides. I guess you have to store rooms in the memory to prevent extra ladders, but that's tricky and would require to write the data to hdd.
Inaccessible buildings could be dialt with by adding a rule to always put an entrance first, but as I said, funny feeling of every building being built, facing you.
(terrain/mobs/armor)
1: I can't help thinking that generating multi-chunk buildings from the center would be a nightmare. I would go about it from the corners, but that would require rotating the module to fit (which would probably be a needed feature anyways)
2: I would make connection types case-insensitive strings, and allow a module to explicitly define supported types for each side. The default types (0-2) would translate to "wall", "hall", and "room" or similar. This would allow modules that are parts of larger buildings to define special connection types, like "tower-courtyard" or "garden-fence", and would make it easier to cross chunk borders without pre-generating modules.
EDIT: on second thought, this isn't a good way to get around pre-allocating modules, but I think it's a good way to describe different connections, like "3x4_hall" and "avenue", and good for connecting random modules within larger structures.
3: A couple changes to linking: make an option to _attempt_ to place a certain module where specified, but if it fails, just act as though it never tried to link, or optionally, default to a different module (note that this should take rarity or similar into account). Also, allow linking to a folder (randomly picks modules in the folder until one fits), and, if possible, wildcards. For example:
try link 1 0 0 aqueduct.txt 95% default aqueduct_end.txt
link 0 1 0 tower_parts\*
Also I'm a little concerned about the rarity system. If I understand correctly, if one module is particularly rare or hard to place, the next item in the list will be that much more common.
Do note that, while I have a little experience with minecraft modding, I have never once taken a sideways glance at the generation code, and have never worked with anything similar. So it's completely possible that these suggestions are all horrible. I'm just trying to help where I can with a great project
- The Second Creeper
It's one chunk at a time, and I use a deterministic pseudo-random based on the seed, as well as the x and z coordinates, to decide how each 8x8x8 cube is going to try to connect to the next one over. That way I can just generate the connection values to check the way neighboring chunks are going to try to connect to the current one without actually generating everything in the next chunk over. This seems to be similar to what you're doing, though I think I'm checking the connections differently.
So, for the larger towers, you actually have more modules being placed overhead, and their connections being figured out? Interesting... I wonder if there's some way to integrate that and the floating walkway idea...
Using Perlin Noise for aqueduct placement... interesting. The trouble with that is it doesn't really produce straight lines; it makes blobs. Though a similar sort of system could probably work.
I'll try to take a look at your code when I get the chance, but I suspect I'll be needing to update everything. At which point, I may as well just copy over the useful code and start largely from scratch, since we seem to have changed what we want... I really should get to work drafting up a proper design document so we can lock that in place.
Edit:
There is some rotation functionality built into the module class as it is. Granted, it's used to rotate walls and doors and such so I don't end up typing out four identical copies of the same connections (one for each way it could be facing), but I think it could be used for the whole module as well. But yeah, now that you mention it the math would be easier coming from the southwest (smallest x and z) corner.
I'm a little confused what you mean by pre-allocating modules. Do you mean figuring out what will be in the next chunk by "placing" modules there?
The link thing is a good idea. The wildcard might take a little figuring out on my end, but I think it could be done.
Yes, the rarity system does have that issue. Even more startling is that, depending on the order the modules are put into the array, their odds of being placed change drastically. Consider a long list that ends with two walkway modules:
Module 1
Module 2
Module 3
Walkway Module 1
Walkway Module 2
It picks a random starting point and cycles through. The trouble with this is it will pretty much only try Walkway Module 2 if it lands on it initially, or Walkway Module 1 fails the rarity check. At some point I would like to fix this issue.
Well, actually, we're pretty much scrapping most of the generation code and writing our own. All you really need to know from Minecraft's built in generation is that it's made in chunks.
(terrain/mobs/armor)
Yeah, by that I meant letting the modules "claim" an area in a non-generated chunk, and actually generating them later, with the rest of the chunk. (So basically, as far as the module-placer is concerned, those modules are already there, but the terrain generator would still need to generate them later)
- The Second Creeper
A) check if ther are enough not generated yet chunks (last I checked there was some way to do that... gotta lurk more) to fit the pre-allocated stuff in as soon as pseudo-random generator says "put the big stuff here" (considering it can only do so for 1 module, the lazy bum).
check if that space isn't pre-occupied already
C) check if the chunk it is generating has any records like that.
D) allocate more modules if the one, placed, requires, but that leaves recusrsion on the consciousness of module-maker.
Simple and crystal clear. Making towers with guarantee to have randomely generated stairs on every floor is harder.
(I apologize it looks a bit like a runt)
(and okay, okay, back to my puny little tasteless drawings of walls)
(terrain/mobs/armor)
Well, getting the stairs to show up in towers is easy. Getting a larger tower to have stair access from floor to ceiling... bit of a tougher task.
I've been reading what you post, though some of it is a little hard to understand.
Interesting thought I had - what if all the included modules had their own file(s), and users could add more modules by simply dropping module files in? It would involve the same kind of code as the wildcard linking, and could potentially mean that no two Mazeworlds are quite the same (and world generation is all done server-side, so server owners could have quite a bit of fun with this).
And, you still need to differentiate the biomes, so, I'd guess, adding a biome file with list of modules (or just having a unique biome number stated in them all) and a few settings like, say, rarity of the air gaps and the ranges for top-middle-bottom slices (and their vriation, maybe?) would be useful someday. Though maybe not.
It starts to look like a huge heap of text files already, heh. So very linux-like. Or bsd. Or whatever you prefer to dissect in vi/nano/emacs.
All I can think of for the towers, being connected from top to bottom is checking for stirs around and generating one if none found, but that's a tricky thing to make when you're not entirely sure if it's a tower or not. On the other side, would be safe to just leave some places unaccessible.
(terrain/mobs/armor)