Maybe you could better integrate into MyTown for the next version? That way teams could be regulated on a per town basis. MyTown is a Forge mod and not a Bukkit plugin so it should be much easier to integrate. I already use MyTown with your mod. It's interesting because it currently doesn't block AW grief, which is great, since it allows us to use MyTown to protect against all block-breaking but the siege engines in Ancient Warfare. I can create grief-resistant raiding in combination with siege and army warfare.
If the two mods were better integrated, soldiers could fight for towns or nations in MyTown with per-player soldier control permissions that could be integrated directly through MyTown. MyTown itself supports granularity so players might even be able to have per-plot npcs so only plot owners could control those npcs. Since the per-plot NPCs would still be under the main town they could still be commanded by a higher ranked town official but the plot owner could keep his house-guards from getting jacked by a neighbor. The same applies to perhaps even nations, whereby the national leaders could have their own "royal army" of sorts. The national leader could command town soldiers, but town leaders could not command the soldiers of other towns in the nation. Royal army soldiers only listen to the national leader. This would allow towns to develop legitimate political intrigue, where towns may fear a growing national army or the armies of other towns within the nation or without. It would really add a lot of depth and allow servers to really utilize Ancient Warfare in a lot of different ways. The developer of MyTown has expressed a lot of interest in integration with your mod and with 1.7 being planned by the both of you, now would be a great time to start something
Either way, I have another suggestion for the concept of fortification in your mod. How about buttress entities that can be placed against walls and reinforce the block structure within a certain cuboid oriented based on the placement of the buttress. Any block-breaks that occur within this cuboid will instead damage the buttress and be prevented. Siege engines that would break blocks in this cuboid will instead deal extra damage to the buttress. This makes it so breaking the block directly with a pick will take much longer against a supported wall. Since the buttresses are entities on their own, they can be attacked directly if an enemy manages to get inside. Perhaps use a version of the drawbridge functionality For instance a simple level 1 buttress placed on the inside of a fortress wall will reinforce a 2 block thick, wall that is 9 blocks wide and 8 blocks high and have 1000HP. Any damage this wall takes from siege engines damages that buttress instead of breaking the wall as if the butress had be hit by the projectile itself. Each block damages the nearest buttress if multiples are lined against each other with their cuboids overlapping until there is no buttress standing in place. Supports could be a version of the buttress, essentially pillars that protect the blocks above them. This encourages players to build fortresses on strong materials like obsidian and bedrock and to also encourage the undermining of structures and the use of siege engines instead of simple block-breaking to pierce enemy defenses. What do you think?
= unprotected =protected = support
Building the buttresses could be done like the drawbridge selection method. The first point selected is the base and the second point represents the area protected.
This would only protect solid blocks. Any transparent blocks or tile-entities can be broken as normal. = Base = Supported
Keep in mind that if the base block as indicated by the raw pork chop is destroyed, the buttress or support breaks entirely, regardless of HP. The selection only works on a 2d plane, the cuboid must have at least one dimension be exactly 1 and the angle of the the buttress will support a wall thickness of 2 at 90 degree angle, a 1 thick wall at a 135 degree angle, and a 4 thick wall at 45 degree. The lower the degree a proportionally thicker section of wall can be protected at the expense of a higher wall. Buttresses and supports will use fence materials: wooden, cobblestone, and iron fence. The longer the buttress or support, the more material used.
Something like this could do a lot for player architectural engineering and create an immersive way to protect your blocks from enemies
Mohawky, I've noticed sometimes that when you move into an unloaded area with some world generation-altering mod installed, you'll get a different biome displayed. The source of this is unknown to me but it is something I notice once in a while. Maybe this has something to do with it? AW says to check the biome but the server hasn't loaded it and checks the vanilla seed biome instead, generating castles as if it were the unloaded biome instead. I've found castles that spawn sometimes in the River_sand biome (ocean, essentially) from Better World Gen. It's very rare but it might be related to these phantom biomes.
I had read an earlier comment about siege towers. Would there be a way to have them built after the player is close to the castle? Consider that on a server that people might build different castles types. We all know that castles are not one size fit all. You might have that one player who build his outer wall just a little to high.
The other suggestion is to make it so that villager count is a factor when recruiting soldiers. Not only that but to have age as a factor. After a certain amount of turns Soldiers recruited would become retired veterans. Besides minecraft I also play skyrim and mount and blade. I usually look for mods that make the game more realistic and not overpowered. For example I always skip mods that give infinite gold Hp or immortality. I like mods that allow me to recycle weapons and armour i may not be using, that increase mob generation, or include bandit raids.
Another suggestion I had was how about including the ability to create biological and chemical weaponry. I know this makes things much more advanced. For example if one could add recipes to make HCl, Sulfuric acid, or Hydroflouric acid. One could use these to create substances such as Sarin gas. One recipe for biological weaponry could be the ability to create wheat into oil. Then one could add oil to a potatoe and create botulism which one could infect water with. I think the game would be much more fun if they added a chemistry element.
I had read an earlier comment about siege towers. Would there be a way to have them built after the player is close to the castle? Consider that on a server that people might build different castles types. We all know that castles are not one size fit all. You might have that one player who build his outer wall just a little to high.
The other suggestion is to make it so that villager count is a factor when recruiting soldiers. Not only that but to have age as a factor. After a certain amount of turns Soldiers recruited would become retired veterans. Besides minecraft I also play skyrim and mount and blade. I usually look for mods that make the game more realistic and not overpowered. For example I always skip mods that give infinite gold Hp or immortality. I like mods that allow me to recycle weapons and armour i may not be using, that increase mob generation, or include bandit raids.
Another suggestion I had was how about including the ability to create biological and chemical weaponry. I know this makes things much more advanced. For example if one could add recipes to make HCl, Sulfuric acid, or Hydroflouric acid. One could use these to create substances such as Sarin gas. One recipe for biological weaponry could be the ability to create wheat into oil. Then one could add oil to a potatoe and create botulism which one could infect water with. I think the game would be much more fun if they added a chemistry element.
Another suggestion if it has not already been suggested is to add dead animals as ordinances for catapults. Remember that these would be used to now only demoralize the enemy during sieges but to also get them sick.
Ok, after a little more experimentation I have confirmed the following regarding structure gen. This applies to the 1.5.2 version, don't know if it applies to later versions.
1 Whenever a new structure is scanned and added to world gen, the config file is always rewritten. This results in the following lines being stripped out of the config:
config:
invalidDimensions=-1,1
structureGenMinDistance=5
structureGenMaxCheckRange=16
structureGenRandomChance=75
structureGenRandomRange=1000
structureGenMaxClusterValue=80
:endconfig
#example entry, remove all the # marks
#entry:
#name=villageGardenLarge
#weight=1
#value=1
#maxVerticalClear=2
#clearingBuffer=0
#maxLeveling=1
#levelingBuffer=0
#:endentry
and replaced with just:
config:
invalidDimensions=-1,1
:endconfig
It also deletes all lines that refer to FILL from every individual structure entry, but without FILL instructions, most structures will not spawn. So they all have to be put back manually.
In scanning, ticking the Unique box makes no entry in the structure template. The Unique function itself just does not work at all in 1.5.2
Note: Turning off ALL village generation in BOP and EBXL if you use those mods, almost doubles the number of spawning structures in AW (but I guess that depends on how many biomes you had originally set to spawn BOP & EBXL villages in)
The biomesONLYin function is really problematic - most of the time it works well, but then for no apparent reason it throws up a structure in a banned biome.
I have a question, and suspicion of what might be screwing the biomesNOTin function: Does Minecraft when its generating biomes, use small parts of other biomes to add variety to a biomes construction, such as a small patch of forest in a plain? And, do other biome mods also do this? If so, it might explain why some larger structures arrive in biomes they are banned from, having obliterated the small bit of additional biome they spawned on within the main biome?
Thanks for the report.
WorldGen config file being rewritten and missing stuff -- I was missing all of the newer features from export. Should be fixed in next release.
Unique flag not working -- the 1.5.2 code was missing a fix from the 1.6 branch. have merged the new code, and it appears to be working (aside from a concurrent generation thing i'm working on tracking down)(concurrent generation also seems to be a problem for structure intersection)(might take me awhile to track this one down, it doesn't make any sense unless MC does multi-threaded world-generation...which should crash in some spectacular ways).
unique flag not exporting -- linked to the world-gen config file not being rewritten properly. Have fixed in dev code, should be available for the next release. Note-- when adding to world gen from the scanner, it sets the unique flag for the world-gen entry, not necessarily in the template.
biomesnotin -- Will have to do more investigation, probably with other mods installed. In a vanilla install, it appears to be working. If I flag all structures for biomesnotin=plains, start a creative superflat world, I get no structures generating with the dubug output of 'failed for improper biome', telling me that they are properly excluding the biome.
You could be right with the biomes selection bit. I caught a few structures that looked to be misplaced, but upon closer examination they were straddling multiple biomes. It might be that there are small patches of one biome inside another causing issues. I will keep an eye on this and see if I can spot any other strange stuff going on.
Mohawky, I've noticed sometimes that when you move into an unloaded area with some world generation-altering mod installed, you'll get a different biome displayed. The source of this is unknown to me but it is something I notice once in a while. Maybe this has something to do with it? AW says to check the biome but the server hasn't loaded it and checks the vanilla seed biome instead, generating castles as if it were the unloaded biome instead. I've found castles that spawn sometimes in the River_sand biome (ocean, essentially) from Better World Gen. It's very rare but it might be related to these phantom biomes.
That could be part of the problem...I'll take note of it, and see if i can spot any irregularities when I put some mods in my dev setup. Thanks for the info.
Hi. I am having an issue with the couriers. I'm wanting a courier to pick up wheat from a farm, put it in an autocrafting table, pick up any bread it made, and put the bread into a town hall block, but the courier fails to pick up bread from the autocrafting table. He can take the wheat form the farm and put it into the table, but that's as far as he gets. Am I doing something wrong or is it a bug?
Hi. I am having an issue with the couriers. I'm wanting a courier to pick up wheat from a farm, put it in an autocrafting table, pick up any bread it made, and put the bread into a town hall block, but the courier fails to pick up bread from the autocrafting table. He can take the wheat form the farm and put it into the table, but that's as far as he gets. Am I doing something wrong or is it a bug?
Are you telling the courier to take it out of a side like north, east, west, or south. I believe it will not take finish product out of bottom or top.
Hi. I am having an issue with the couriers. I'm wanting a courier to pick up wheat from a farm, put it in an autocrafting table, pick up any bread it made, and put the bread into a town hall block, but the courier fails to pick up bread from the autocrafting table. He can take the wheat form the farm and put it into the table, but that's as far as he gets. Am I doing something wrong or is it a bug?
Crafting tables (and almost all inventories in AW) use the ISidedInventory interface. What this means (from a non-code persepective) is that for automation purposes only part of an inventory is accessible from any side.
It sounds like you do not have the sides configured properly. For crafting tables, the SIDES of the block are input, and the TOP/BOTTOM will access the 'result'/output slot. You should be able to edit the side-accessed directly from the routing slip -- it should have a button that says 'north'/'south' etc...switch this to the desired access direction.
Awesome. Gradually its getting through the bugs. I'm getting some particularly good maps at the moment, still tweaking weights and values and watching what spawns best and where. I'm up to about a hundred structures spawning at the moment. The greater the selection possibilities, the fewer replicates in the same place I'm seeing.
Sprang the new set up on my players tonight - they discovered an entire city stocked with bandits and loot etc. They couldn't believe it was just a random spawn.
Sounds like you are pushing the structure system harder than I had ever imagined Good stuff.
Glad you are getting some good looking results out of it so far...hopefully I can get most of the rest of the minor bugs and validation stuff sorted out during the port/1.7 update, as well as adding the necessary support for random TE and Entities.
Yes, that would be good. I think I'm at the limits of what I can do with it now though [...]
Well, if things go as planned, I should have the updated/rewritten structure stuff available before too long. Taking a much more modular approach this time around...meaning I can work on things more as self-contained parts. There is a bit more overhead in the coding process than directly linking, but it allows for more encapsulation, easier debugging, and a much easier time replacing/rewriting only portions of the code for future updating purposes. It will also allow me to release modules as they are done, instead of waiting for the entire project to be finished. I will even be using plugins between my own modules to support inter-module functionality such as between npcs and vehicles, or npcs and civics.
Currently I'm planning on releasing 5 modules --
Core/Framework (network handlers/gui framework/shared code),
Structures (structure/template/world gen),
Vehicles (uhh..vehicles!!),
NPCs (those little guys that swing axes and stuff),
and Automation (civics, machinery).
Each module should be loadable separately (aside from core..it is needed by all others)-- so for instance you could load the npc and vehicle modules but leave the automation out....or load JUST the automation module (would need to rely on BC power systems for workers at that point). If you wanted only the creative/survival mode structure stuff, you could load only the structure system.
So far the plugin system is looking like it will allow me more easily/cleanly develop support for more complex block and entity types -- and most importantly will allow _anyone_ to write a simple(?) plugin to add support for and handle mod added blocks and entities.
I'm aiming to have 100% vanilla support in the initial release, including all blocks and persistent types of entities. At the current rate, I may well have this available before 1.7/forge is out.
Unfortunately, the template format will be changing a bit. I'm already in the processes of writing a format converter though, so you should be able to migrate any existing templates without loss.
While I'm at a the fresh design-stage, now is the point I should inquire about wanted/needed/often used features.
I currently have about a million features in the block rules and validation -- (probably only about half of which are properly implemented and working). What of these features are the most used / want to be kept around? Which ones would not not mind seeing disappear?
(most of these are features that have to be manually edited into the template to take effect)
1). Preserve plants/lava/water/blocks -- anyone using this feature, is it needed in the future? I've never seen it used, nor used it myself, nor can I even come up with a good use case that couldn't be done better with block-randomization.
2.) Per-biome block swapping -- initially seemed like a good idea. Now I've found that there are some Forge events to handle dynamic block swapping of standard (cobble/etc) blocks for structure generation. I will likely be moving to this system to handle world-generation (with the option to disable if desired). I may allow structure-plugins to hook into the event handler to add more block swap types/etc.
3.) Ruins templates format spawner and chest handling -- You will probably only see these lines/features in your template if you converted an old Ruins template that had spawners/chests in it. The code was a hold-out from trying to maintain clean Ruins compatibility, and had to be manually edited in. In the future vanilla mob-spawners will be handled by the plugin/rule system. Chests as well will be handled by the plugin system.
4) Validation settings -- I will be completely redoing world-generation validation settings...as the current settings are *hard* to get an understanding of. Most of the current code was a fairly terrible re-implementation of the original Ruins code, and I will be going with a more clean setup in general. Considering enabling 'validation plugins' so that others could write plugins to change validation/selection/placement stuff. (see below for a preview of the validation settings as I currently have them envisioned)
5.) Not directly a feature, but I'm curious -- I'm trying to decide the best method to organize templates and world-generation settings. I currently have the following options:
Store validation settings in the template -- pretty much the same as it is currently. Would again require a separate link/config file to know what to load for world generation.
Sore validation settings in a separate file per-structure. Each structure would then have a template and a world-gen/validation file. World-generation would load and generate for all validation files found at load-time.
I'm kind of leaning towards the split in two files per template -- the template itself is a complete package which merely denotes what blocks go where. The validation settings are only used for world-generation and have no relation to the block-data/etc contained in the template. They really have no co-dependence, and do not need to be in the same file -- except for reasons of organization. I like the idea of separation, but I'm not sure if I want to keep track of two files per structure. The current system works fine, but the new per-structure entries would likely be much larger with the new validation settings. I'm also aiming to only store these validation settings in a single place (whereas before they were defined in the template but could be overridden in the world-gen config file...no clue why I did that...).
I guess the real question is -- is the current method for denoting world-generation structures sufficient (e.g. a single world-gen config file)? Any other suggestions on changes? Should the validation stuff be kept in the template, in the world-gen file, in a separate template, or some combination?
On the subject of structure validation, I will be changing the setup quite a bit to use the following:
(copied directly out of source...so bear with me )
/**
* given an area with a source point, how far above the source-point is the highest acceptable block located?
* e.g. a 'normal' setting would be the same height as the structures above-ground height which would allow
* generation of a structure with no blocks left 'hanging' above it, and minimal cut-in into a cliffside/etc
* e.g. a 'perfect' setting would be 0, meaning the ground must be flat and level prior to generation
*
* negative values imply to skip leveling checking
*/
int maxLeveling;
/**
* if true, will clear blocks in leveling bounds PRIOR to template construction. Set to false if you wish to
* preserve any existing blocks within the structure bounds.
*/
boolean doLeveling;
/**
* given an area with a source point, how far below the source point may 'holes' extend into the ground along the
* edges of the structure.
* e.g. a 'normal' setting would be 1-2 blocks, which would ensure that the chosen site was flat enough that it would
* generate with minimal under-fill.
* e.g. an 'extreme' setting to force-placement might be 4-8 blocks or more. Placement would often be ugly with only
* part of the structure resting on the original ground.
*
* negative values imply to skip edge-depth checking
*/
int maxMissingEdgeDepth;
/**
* if true, will fill _directly_ below the structure down to the specified number of blocks from maxMissingEdgeDepth
* filling will occur PRIOR to template construction.
*/
boolean doFillBelow;
/**
* the size of the border around the base structure BB to check for additional functions
* 0 or negative values denote no border.
*/
int borderSize;
/**
* same as with structure-leveling -- how much irregularity can there be above the chose ground level
* negative values imply to skip border leveling tests
*/
int borderMaxLeveling;
boolean doBorderLeveling;
/**
* how irregular can the border surrounding the structure be in the -Y direction?
* negative values imply to skip border depth tests
*/
int borderMissingEdgeDepth;
boolean biomeWhiteList;//should treat biome list as white or blacklist?
String[] biomeList;//list of biomes for white/black list. treated as white/black list from whitelist toggle
boolean dimensionWhiteList;//should treat dimension list as white or blacklist?
int[] acceptedDimensions;//list of accepted dimensions treated as white/black list from whitelist toggle
Block[] acceptedTargetBlocks;//list of accepted blocks which the structure may be built upon -- 100% of blocks directly below the structure must meet this list
Block[] acceptedClearBlocks;//list of blocks which may be cleared/removed during leveling and buffer operations. 100% of blocks to be removed must meet this list (this will ensure no-cut into other structures if they contain non-accepted blocks)
boolean isUnique;//should this structure generate only once?
/**
* world generation selection and clustering settings
*/
int selectionWeight;//the selection weight of the structure
int clusterValue;//the value placed into chunk-map for clustering purposes
int minDuplicateDistance;//minimum distance between to instances of this structure being generated
Ehh..thats probably a big enough wall-of-text for now...I'll get back to making code
I like the idea of a directory structure. Clever use of Find and replace in files in an editor like Notepad++ can allow a developer to mass modify structures in specific structures. Would you consider an option to give a weight modifier for the structure spawn based on the spawn points distance from the world spawn? That way AW can categorize the difficulty of structured spawns. The closer to the world spawn the more likely you are to encounter white flag npcs or another neutral team, for instance, but bandit camps or other unique spawns (dungeons with mob spawners with bonus damage/health attributes) are further away.
Implementing a distance factor like this could have interesting effects:
Imagine you have an adventure map:
You set a world border to be a perfect square and place the world spawn in one corner of that map. If you had unique structure spawns keyed to distance, you could make a rogue-like adventure map with special towns that are guaranteed to spawn at some distance from the world spawn.
The end-game would always spawn at the distance that occupied the opposite corner as the world spawn, since we can know for certain the only distance that this structure could spawn at. If you could somehow make Noppes NPCs to spawn with quest data intact that would be phenomenal. Imagine guaranteed structures based on distance from spawn that have quests linked to each other, a randomly placed desert themed catacomb, a lush jungle temple, a sunken ship, all holding items that are needed at the next neutral zone to access the next quest. Shops and neutral zones with invulnerable or respawnable npcs and customizable npc factions and guards.
Excuse me, can somebody tell me what the "actiontime" is in the config? Is that how fast an NPC works, or how long before they need to eat? Also, how do I alter the NPCs eating? Also, using the MCA (Minecraft comes alive) mod, the villagers are altered. Will this affect this mod due to the villagers no longer knowing how to farm?
The text lines for BiomesNotIN or BiomesOnlyIn in AW world gen config get very long and its almost impossible to get a clear and simple overview of what you've set to spawn where.
Once you get over a hundred structures in your list, (and looking at my planning and present stock list its probably going to hit 400) then the AW file list gets huge and cumbersome, and the possibility for replicated entries and mistakes becomes much bigger.
At a hundred structures, and 200+ biomes, frankly, I'm struggling to keep track, 400 is going to be a nightmare. Though, I'm not sure what the best solution is to this, but there really needs to be one, as the key, I think to successful world gen for AW is going to be a huge variety of possible spawns around a core group of regular spawns such as the AW castles etc.
Mods that try to control mob and creature spawns have been hitting this very same problem for a while now, and have tried various solutions - Grouping biomes into "like" groups - such as all forest, all mountain, all swamp etc and dealing with the group, rather than individual biomes. But that has flaws too. Is Highlands_wooded hills - a mountain biome or a forest biome? for example.
Perhaps the structures themselves could be categorised?
At the moment mine fall into these:
Major Civilised - Large towns and castles with out-buildings etc, populated.
Minor Civilised - Hamlets, isolated outposts, civilians structures (lumberjacks in forests for example)
Wonders - Exotic structures that may or may not hold enemies, loot and surprises.
Major mob encounters - large structures - surface and underground, tribal villages, old haunted ruins etc - such as Goblin villages, bandit castles etc.
Minor mob encounters - smaller structures - surface and underground - such as a spider spawner cave etc.
Scenics - structures that have no purpose, but look good.
(A lot of these are waiting on spawners or some method of mob population to finish, but other than that they are spawning fine through AW)
On the spoiler validation - like it - that looks great, especially min distance between instances of structure.
Thanks for the feedback.
Going to focus on one point in this post: biome selection.
Its a tricky problem to solve in an acceptable manner. The problem is mostly one of scale, and a little bit of layout/organization.
Current proposed options/ideas:
A.) Continue with the biome white/black list on a per-structure biome. each structure (or validation file/entry in world generation) tracks what biomes it may/may not spawn in. This easily approaches the level of cumbersome merely with the vanilla biomes, and probably more-so with 1.7 and its vastly increased biome count.
B.) Reverse the trend, and track structures per biome. World Generation file would have one entry per biome, listing the structures that can spawn in that biome. Would require you to manually add every structure to its spawnable biomes. I can see this becoming a chore quite quickly as well.
C.) Modified version of A), but allow the user to define biome 'groups'. E.g defined in the world-gen file such as 'groupA=plains, forest, meadow, swamp', 'groupB=forest, extreme_hills, taiga', 'groupC=plains, desert, forest' etc.... Using this method, you could specify any biome group with a single keyword (while still allowing finer control with individual biomes). The user could group biomes however they like (e.g. groupC would be the 'flat'/village canditate group). The structure could then be added to any selection of groups and/or individual biomes. Because the groups would be user-defined, ALL of this data would have to reside outside of the normal template...such as in an external world-gen config file.
D.) Modified version of B, but with biome-grouping. Would be tricky to setup and organize I think.
E.) Modified version of B, but with structure-grouping. Structures would be groupable much as biomes for C/D. User would define a name e.g. "group_ruins", would define what structures are in that group, and then could add that group to any/all applicable biomes.
F.) Combination of D & E. The downside I see to this one is the complexity of maintaining and tracking that much inter-linking information. Would be like tracking a many-to-many database in your head.
G.) Combination of C with structure grouping as well. Could cut down on the 'wordiness' of the config file, at the cost of logical complexity.
H.) Folders. Lots and lots of folders. One folder per-biome. Either duplicate structures, or their validation files. I really don't like this one (its ugly, and unnecessary data-duplication is...bad...)...but it is _an_ option.
??? hopefully I've missed something obvious, as none of the options I'm listing really solve the problem.
I'm thinking that C sounds like the most viable solution, or possibly G. C is pretty much the current layout, but with the addition for users to define biome groups. G merely adds the user-defined structure-groups. This should make it much easier to add structures when you normally add them to many biomes at the same time -- merely define a biome group, and add that one biome group to the structures accepted biomes list. However, as more and more structures are added, the world-gen config file would still fill-up fairly fast and become difficult to manage -- especially so if the entire validation settings for each structure were located there. (Honestly though...I don't think it matters what format...with 100's of structures..the world gen config file will be huge no matter the format/method I save the information in...).
Any other thoughts/ideas on how to organize the biome selection stuff?
The feature creep is getting very strong, even though the features are outstanding...
I am beginning to think you should indeed separate it into 2 different mods
Yep. To both statements
If only I could finalize a set of features to implement, it would make things easier....but evolution is cool as well.
Anyhow..yea, the mod is being split into multiple modules that you can load individually. Will help with both the coding side, and allow people to install only the features that they want.
Excuse me, can somebody tell me what the "actiontime" is in the config? Is that how fast an NPC works, or how long before they need to eat? Also, how do I alter the NPCs eating? Also, using the MCA (Minecraft comes alive) mod, the villagers are altered. Will this affect this mod due to the villagers no longer knowing how to farm?
actiontime = number of ticks it takes for an NPC to complete one 'work' cycle -- harvest a single block, plant a single block, clear a single block, move a stack of items (couriers), heal for their specified healing amount (medics and engineers), or time inbetween attacks (combat units).
Eating habits are apparently not currently configurable. I had thought that I had already opened up those config options, but I'm not seeing them in the config file currently. I might add this in for one of the next updates, but no guarantees. (I'm planning on reworking the NPCs to load from external definition files...so that any/all stats should be editable from those files in the future).
MCA should have no effect on the Ancient Warfare NPCs, as they are not villagers. They do not share any AI or nbt data structure, and are on completely different class-branches.
I like the idea of a directory structure. Clever use of Find and replace in files in an editor like Notepad++ can allow a developer to mass modify structures in specific structures. Would you consider an option to give a weight modifier for the structure spawn based on the spawn points distance from the world spawn? That way AW can categorize the difficulty of structured spawns. The closer to the world spawn the more likely you are to encounter white flag npcs or another neutral team, for instance, but bandit camps or other unique spawns (dungeons with mob spawners with bonus damage/health attributes) are further away.
Implementing a distance factor like this could have interesting effects:
Imagine you have an adventure map:
You set a world border to be a perfect square and place the world spawn in one corner of that map. If you had unique structure spawns keyed to distance, you could make a rogue-like adventure map with special towns that are guaranteed to spawn at some distance from the world spawn.
The end-game would always spawn at the distance that occupied the opposite corner as the world spawn, since we can know for certain the only distance that this structure could spawn at. If you could somehow make Noppes NPCs to spawn with quest data intact that would be phenomenal. Imagine guaranteed structures based on distance from spawn that have quests linked to each other, a randomly placed desert themed catacomb, a lush jungle temple, a sunken ship, all holding items that are needed at the next neutral zone to access the next quest. Shops and neutral zones with invulnerable or respawnable npcs and customizable npc factions and guards.
I've been trying to figure out a method to allow for and implement a difficulty scale into structures since the last rewrite....and using a distance from-spawn based algorithm was about as far as I got as well.... The only problem is, how do you scale it smoothly so that you aren't forced to go out to 25million x/z in order to find the hardest structures? I'm thinking a game-age based system might work...or some combination of the two probably.
This is ignoring the problem of how to actually scale the difficulty of the structures...you need either different structures for different difficulty levels, or a ton of special code/script to handle scaling up the difficulty on any scalable things (npcs/etc). You would also need some way to designate that the structure is scalable, and what elements in it scale...how fast they scale, what they scale to, etc.
I like the idea, but there are quite a few problems to figure out before I could think about implementing it. The easiest solution I can think of now would be have a 'difficulty' requirement that must be met before the structure can spawn, with unique non-scaling/static structures, with the difficulty calculated by a combination of distance from spawn and game-time passed. Still...lots more thought required on the idea.
One big problem with the scanner is water, or rather trying to scan anything that's set in water like a ship or an island structure. At the moment the only solution I have is to cut the thing in MCEdit, use the RUINS converter to make the MCEdit file into a .tml, and then convert using the AWS converter into AWS format, and then try and rejig it so it spawns properly. A bit convoluted to say the least
I'm not sure of the problem here -- is it that you can't click on water to target it with the scanner?
I know that it picks up water just fine, you just need solid blocks bounding the water to initiate the scan. If this is the problem, I could probably configure it to accept clicks on water easily enough (not sure if it would be full-time or only with a modifier key...I'll have to see how it feels once I begin working on it).
Yes. Don't get rid please. Along with "preserve blocks" Its used to sink structures into the landscape so that you get a natural look, without having to define a level. Its especially useful for things like ruins that you want to spawn in forests (I'm just completing a ruins pack now) and say, huts on stilts or piers that are set into the sea. (unless you have a better method that is?)
2.) Per-biome block swapping
Nope, haven't used this
3.) Ruins templates format spawner and chest handling
Have used the Ruins converter, but not the export to Ruins function. Chest handling I'd prefer to be handled within the AW mod in some way. Its great being able to scan specific contents, but there needs to be some randomisation option too, that draws items from other mods too if possible. MCDungeons has a good configurable chest item spawning system.
4) Validation settings
Entirely agree. Nothing about RUINS worked as it should. Replacing with your own code should give much better results - your validation on the old catapult mod was outstanding. It would be good to return to that, but its difficult with user generated structures.
[...]
Good to know about the preserve-blocks. I'm supposing that you are using the per-template settings rather than the per-block-rule settings? Per-template is easy enough to support, and already mostly in-place in the new validation setting (you would merely turn off the leveling clear option, but could leave level-testing enabled)(could still enable specific preserve-options for more granular control over what types). The per-block is more difficult to support, but could be included if needed.
Per-biome block swapping -- yah, I didn't figure too many people used this. In the future I will have a simple 'enableblockswap=true/false' in the validation settings, and will use the vanilla block-swap methods if it is enabled (the ones used to swap blocks for vanilla villages).
Spawners -- the new system is already scanning and duplicating spawners...should have full support for vanilla spawners in the future (keep in mind that vanilla spawners can register/use non-vanilla mobs too!). And I see what you mean by adding AW-accessible blocks to the creative menu to get at the spawners -- I had to use chat commands to give myself spawners just to test the stuff in the first place...because for some silly reason there are no spawner blocks in creative mode (unless you have NEI installed on both client+server).
Chests -- the new system will include both duplication and randomization abilities -- hopefully without having to edit the template. My current thoughts are this: when scanning a chest, peek at the inventory. If the first (and ONLY) item in the inventory is a gold ingot, diamond, or emerald, enable randomization for that chest with loot quality based on the item (gold=low, dia=mid, em=high). If the chest has more than one item in it (or the single item is not one of the triggers), the chest will be flagged as static loot target -- the items it contains will be scanned/exported as-is and duplicated when the template is built.
Validation settings -- I wish I could do the original catapult-mod style validation for structures as well. I hand-crafted that validation per-structure though, to fit..._perfectly_ (or as close to it as I could get ). Down to the point where I would check specific blocks for intersection or missing, rather than just all blocks in an area. I would even consider doing something similar, but it would require supporting an external scripting language so users could script their own validation....however I'm pretty sure that requiring users to learn a scripting language just to add a structure is not the best way to go.
Hopefully though, the new validation stuff will be much easier to understand and manipulate. The current stuff...while all of the settings -do- _something_...I could barely tell you what they do and how they all interact without tracing through the source--and would probably still give incorrect answers most of the time. Spaghetti code at its finest -- Best to do away with that stuff
I'm not sure what's going on. I recently updated Ancient Warfare but on this latest version it seems none of the structures are spawning at all on a new map generation. I didn't notice it until now as I've been working on a pre-generated map. Is anyone else experiencing anything like this? I'm using BetterDungeons, but after disabling it, I still cannot find any structures. Did the format on the files change that I should delete them or something?
EDIT: Moved back to .36 and generation works again. Odd.
EDIT: EDIT: Okay. I'm dumb. I realized I commented out some important stuff when I was experimenting. Sorry for the false report.
If the two mods were better integrated, soldiers could fight for towns or nations in MyTown with per-player soldier control permissions that could be integrated directly through MyTown. MyTown itself supports granularity so players might even be able to have per-plot npcs so only plot owners could control those npcs. Since the per-plot NPCs would still be under the main town they could still be commanded by a higher ranked town official but the plot owner could keep his house-guards from getting jacked by a neighbor. The same applies to perhaps even nations, whereby the national leaders could have their own "royal army" of sorts. The national leader could command town soldiers, but town leaders could not command the soldiers of other towns in the nation. Royal army soldiers only listen to the national leader. This would allow towns to develop legitimate political intrigue, where towns may fear a growing national army or the armies of other towns within the nation or without. It would really add a lot of depth and allow servers to really utilize Ancient Warfare in a lot of different ways. The developer of MyTown has expressed a lot of interest in integration with your mod and with 1.7 being planned by the both of you, now would be a great time to start something
Either way, I have another suggestion for the concept of fortification in your mod. How about buttress entities that can be placed against walls and reinforce the block structure within a certain cuboid oriented based on the placement of the buttress. Any block-breaks that occur within this cuboid will instead damage the buttress and be prevented. Siege engines that would break blocks in this cuboid will instead deal extra damage to the buttress. This makes it so breaking the block directly with a pick will take much longer against a supported wall. Since the buttresses are entities on their own, they can be attacked directly if an enemy manages to get inside. Perhaps use a version of the drawbridge functionality For instance a simple level 1 buttress placed on the inside of a fortress wall will reinforce a 2 block thick, wall that is 9 blocks wide and 8 blocks high and have 1000HP. Any damage this wall takes from siege engines damages that buttress instead of breaking the wall as if the butress had be hit by the projectile itself. Each block damages the nearest buttress if multiples are lined against each other with their cuboids overlapping until there is no buttress standing in place. Supports could be a version of the buttress, essentially pillars that protect the blocks above them. This encourages players to build fortresses on strong materials like obsidian and bedrock and to also encourage the undermining of structures and the use of siege engines instead of simple block-breaking to pierce enemy defenses. What do you think?
Building the buttresses could be done like the drawbridge selection method. The first point selected is the base and the second point represents the area protected.
This would only protect solid blocks. Any transparent blocks or tile-entities can be broken as normal.
Keep in mind that if the base block as indicated by the raw pork chop is destroyed, the buttress or support breaks entirely, regardless of HP. The selection only works on a 2d plane, the cuboid must have at least one dimension be exactly 1 and the angle of the the buttress will support a wall thickness of 2 at 90 degree angle, a 1 thick wall at a 135 degree angle, and a 4 thick wall at 45 degree. The lower the degree a proportionally thicker section of wall can be protected at the expense of a higher wall. Buttresses and supports will use fence materials: wooden, cobblestone, and iron fence. The longer the buttress or support, the more material used.
Something like this could do a lot for player architectural engineering and create an immersive way to protect your blocks from enemies
The other suggestion is to make it so that villager count is a factor when recruiting soldiers. Not only that but to have age as a factor. After a certain amount of turns Soldiers recruited would become retired veterans. Besides minecraft I also play skyrim and mount and blade. I usually look for mods that make the game more realistic and not overpowered. For example I always skip mods that give infinite gold Hp or immortality. I like mods that allow me to recycle weapons and armour i may not be using, that increase mob generation, or include bandit raids.
Another suggestion I had was how about including the ability to create biological and chemical weaponry. I know this makes things much more advanced. For example if one could add recipes to make HCl, Sulfuric acid, or Hydroflouric acid. One could use these to create substances such as Sarin gas. One recipe for biological weaponry could be the ability to create wheat into oil. Then one could add oil to a potatoe and create botulism which one could infect water with. I think the game would be much more fun if they added a chemistry element.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumThanks for the report.
WorldGen config file being rewritten and missing stuff -- I was missing all of the newer features from export. Should be fixed in next release.
Unique flag not working -- the 1.5.2 code was missing a fix from the 1.6 branch. have merged the new code, and it appears to be working (aside from a concurrent generation thing i'm working on tracking down)(concurrent generation also seems to be a problem for structure intersection)(might take me awhile to track this one down, it doesn't make any sense unless MC does multi-threaded world-generation...which should crash in some spectacular ways).
unique flag not exporting -- linked to the world-gen config file not being rewritten properly. Have fixed in dev code, should be available for the next release. Note-- when adding to world gen from the scanner, it sets the unique flag for the world-gen entry, not necessarily in the template.
biomesnotin -- Will have to do more investigation, probably with other mods installed. In a vanilla install, it appears to be working. If I flag all structures for biomesnotin=plains, start a creative superflat world, I get no structures generating with the dubug output of 'failed for improper biome', telling me that they are properly excluding the biome.
You could be right with the biomes selection bit. I caught a few structures that looked to be misplaced, but upon closer examination they were straddling multiple biomes. It might be that there are small patches of one biome inside another causing issues. I will keep an eye on this and see if I can spot any other strange stuff going on.
That could be part of the problem...I'll take note of it, and see if i can spot any irregularities when I put some mods in my dev setup. Thanks for the info.
Are you telling the courier to take it out of a side like north, east, west, or south. I believe it will not take finish product out of bottom or top.
No, he fails to take bread out of the side, as well.
Don't you need a craftsman to actually craft the wheat into bread? The couriers only move stuff.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumCrafting tables (and almost all inventories in AW) use the ISidedInventory interface. What this means (from a non-code persepective) is that for automation purposes only part of an inventory is accessible from any side.
It sounds like you do not have the sides configured properly. For crafting tables, the SIDES of the block are input, and the TOP/BOTTOM will access the 'result'/output slot. You should be able to edit the side-accessed directly from the routing slip -- it should have a button that says 'north'/'south' etc...switch this to the desired access direction.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumSounds like you are pushing the structure system harder than I had ever imagined
Glad you are getting some good looking results out of it so far...hopefully I can get most of the rest of the minor bugs and validation stuff sorted out during the port/1.7 update, as well as adding the necessary support for random TE and Entities.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumWell, if things go as planned, I should have the updated/rewritten structure stuff available before too long. Taking a much more modular approach this time around...meaning I can work on things more as self-contained parts. There is a bit more overhead in the coding process than directly linking, but it allows for more encapsulation, easier debugging, and a much easier time replacing/rewriting only portions of the code for future updating purposes. It will also allow me to release modules as they are done, instead of waiting for the entire project to be finished. I will even be using plugins between my own modules to support inter-module functionality such as between npcs and vehicles, or npcs and civics.
Currently I'm planning on releasing 5 modules --
Core/Framework (network handlers/gui framework/shared code),
Structures (structure/template/world gen),
Vehicles (uhh..vehicles!!),
NPCs (those little guys that swing axes and stuff),
and Automation (civics, machinery).
Each module should be loadable separately (aside from core..it is needed by all others)-- so for instance you could load the npc and vehicle modules but leave the automation out....or load JUST the automation module (would need to rely on BC power systems for workers at that point). If you wanted only the creative/survival mode structure stuff, you could load only the structure system.
So far the plugin system is looking like it will allow me more easily/cleanly develop support for more complex block and entity types -- and most importantly will allow _anyone_ to write a simple(?) plugin to add support for and handle mod added blocks and entities.
I'm aiming to have 100% vanilla support in the initial release, including all blocks and persistent types of entities. At the current rate, I may well have this available before 1.7/forge is out.
Unfortunately, the template format will be changing a bit. I'm already in the processes of writing a format converter though, so you should be able to migrate any existing templates without loss.
While I'm at a the fresh design-stage, now is the point I should inquire about wanted/needed/often used features.
I currently have about a million features in the block rules and validation -- (probably only about half of which are properly implemented and working). What of these features are the most used / want to be kept around? Which ones would not not mind seeing disappear?
(most of these are features that have to be manually edited into the template to take effect)
1). Preserve plants/lava/water/blocks -- anyone using this feature, is it needed in the future? I've never seen it used, nor used it myself, nor can I even come up with a good use case that couldn't be done better with block-randomization.
2.) Per-biome block swapping -- initially seemed like a good idea. Now I've found that there are some Forge events to handle dynamic block swapping of standard (cobble/etc) blocks for structure generation. I will likely be moving to this system to handle world-generation (with the option to disable if desired). I may allow structure-plugins to hook into the event handler to add more block swap types/etc.
3.) Ruins templates format spawner and chest handling -- You will probably only see these lines/features in your template if you converted an old Ruins template that had spawners/chests in it. The code was a hold-out from trying to maintain clean Ruins compatibility, and had to be manually edited in. In the future vanilla mob-spawners will be handled by the plugin/rule system. Chests as well will be handled by the plugin system.
4) Validation settings -- I will be completely redoing world-generation validation settings...as the current settings are *hard* to get an understanding of. Most of the current code was a fairly terrible re-implementation of the original Ruins code, and I will be going with a more clean setup in general. Considering enabling 'validation plugins' so that others could write plugins to change validation/selection/placement stuff. (see below for a preview of the validation settings as I currently have them envisioned)
5.) Not directly a feature, but I'm curious -- I'm trying to decide the best method to organize templates and world-generation settings. I currently have the following options:
I'm kind of leaning towards the split in two files per template -- the template itself is a complete package which merely denotes what blocks go where. The validation settings are only used for world-generation and have no relation to the block-data/etc contained in the template. They really have no co-dependence, and do not need to be in the same file -- except for reasons of organization. I like the idea of separation, but I'm not sure if I want to keep track of two files per structure. The current system works fine, but the new per-structure entries would likely be much larger with the new validation settings. I'm also aiming to only store these validation settings in a single place (whereas before they were defined in the template but could be overridden in the world-gen config file...no clue why I did that...).
I guess the real question is -- is the current method for denoting world-generation structures sufficient (e.g. a single world-gen config file)? Any other suggestions on changes? Should the validation stuff be kept in the template, in the world-gen file, in a separate template, or some combination?
On the subject of structure validation, I will be changing the setup quite a bit to use the following:
(copied directly out of source...so bear with me
/**
* given an area with a source point, how far above the source-point is the highest acceptable block located?
* e.g. a 'normal' setting would be the same height as the structures above-ground height which would allow
* generation of a structure with no blocks left 'hanging' above it, and minimal cut-in into a cliffside/etc
* e.g. a 'perfect' setting would be 0, meaning the ground must be flat and level prior to generation
*
* negative values imply to skip leveling checking
*/
int maxLeveling;
/**
* if true, will clear blocks in leveling bounds PRIOR to template construction. Set to false if you wish to
* preserve any existing blocks within the structure bounds.
*/
boolean doLeveling;
/**
* given an area with a source point, how far below the source point may 'holes' extend into the ground along the
* edges of the structure.
* e.g. a 'normal' setting would be 1-2 blocks, which would ensure that the chosen site was flat enough that it would
* generate with minimal under-fill.
* e.g. an 'extreme' setting to force-placement might be 4-8 blocks or more. Placement would often be ugly with only
* part of the structure resting on the original ground.
*
* negative values imply to skip edge-depth checking
*/
int maxMissingEdgeDepth;
/**
* if true, will fill _directly_ below the structure down to the specified number of blocks from maxMissingEdgeDepth
* filling will occur PRIOR to template construction.
*/
boolean doFillBelow;
/**
* the size of the border around the base structure BB to check for additional functions
* 0 or negative values denote no border.
*/
int borderSize;
/**
* same as with structure-leveling -- how much irregularity can there be above the chose ground level
* negative values imply to skip border leveling tests
*/
int borderMaxLeveling;
boolean doBorderLeveling;
/**
* how irregular can the border surrounding the structure be in the -Y direction?
* negative values imply to skip border depth tests
*/
int borderMissingEdgeDepth;
boolean biomeWhiteList;//should treat biome list as white or blacklist?
String[] biomeList;//list of biomes for white/black list. treated as white/black list from whitelist toggle
boolean dimensionWhiteList;//should treat dimension list as white or blacklist?
int[] acceptedDimensions;//list of accepted dimensions treated as white/black list from whitelist toggle
Block[] acceptedTargetBlocks;//list of accepted blocks which the structure may be built upon -- 100% of blocks directly below the structure must meet this list
Block[] acceptedClearBlocks;//list of blocks which may be cleared/removed during leveling and buffer operations. 100% of blocks to be removed must meet this list (this will ensure no-cut into other structures if they contain non-accepted blocks)
boolean isUnique;//should this structure generate only once?
/**
* world generation selection and clustering settings
*/
int selectionWeight;//the selection weight of the structure
int clusterValue;//the value placed into chunk-map for clustering purposes
int minDuplicateDistance;//minimum distance between to instances of this structure being generated
Ehh..thats probably a big enough wall-of-text for now...I'll get back to making code
Implementing a distance factor like this could have interesting effects:
Imagine you have an adventure map:
You set a world border to be a perfect square and place the world spawn in one corner of that map. If you had unique structure spawns keyed to distance, you could make a rogue-like adventure map with special towns that are guaranteed to spawn at some distance from the world spawn.
The end-game would always spawn at the distance that occupied the opposite corner as the world spawn, since we can know for certain the only distance that this structure could spawn at. If you could somehow make Noppes NPCs to spawn with quest data intact that would be phenomenal. Imagine guaranteed structures based on distance from spawn that have quests linked to each other, a randomly placed desert themed catacomb, a lush jungle temple, a sunken ship, all holding items that are needed at the next neutral zone to access the next quest. Shops and neutral zones with invulnerable or respawnable npcs and customizable npc factions and guards.
I am beginning to think you should indeed separate it into 2 different mods
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumThanks for the feedback.
Going to focus on one point in this post: biome selection.
Its a tricky problem to solve in an acceptable manner. The problem is mostly one of scale, and a little bit of layout/organization.
Current proposed options/ideas:
I'm thinking that C sounds like the most viable solution, or possibly G. C is pretty much the current layout, but with the addition for users to define biome groups. G merely adds the user-defined structure-groups. This should make it much easier to add structures when you normally add them to many biomes at the same time -- merely define a biome group, and add that one biome group to the structures accepted biomes list. However, as more and more structures are added, the world-gen config file would still fill-up fairly fast and become difficult to manage -- especially so if the entire validation settings for each structure were located there. (Honestly though...I don't think it matters what format...with 100's of structures..the world gen config file will be huge no matter the format/method I save the information in...).
Any other thoughts/ideas on how to organize the biome selection stuff?
Yep. To both statements
If only I could finalize a set of features to implement, it would make things easier....but evolution is cool as well.
Anyhow..yea, the mod is being split into multiple modules that you can load individually. Will help with both the coding side, and allow people to install only the features that they want.
-
View User Profile
-
View Posts
-
Send Message
Curse Premiumactiontime = number of ticks it takes for an NPC to complete one 'work' cycle -- harvest a single block, plant a single block, clear a single block, move a stack of items (couriers), heal for their specified healing amount (medics and engineers), or time inbetween attacks (combat units).
Eating habits are apparently not currently configurable. I had thought that I had already opened up those config options, but I'm not seeing them in the config file currently. I might add this in for one of the next updates, but no guarantees. (I'm planning on reworking the NPCs to load from external definition files...so that any/all stats should be editable from those files in the future).
MCA should have no effect on the Ancient Warfare NPCs, as they are not villagers. They do not share any AI or nbt data structure, and are on completely different class-branches.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumI've been trying to figure out a method to allow for and implement a difficulty scale into structures since the last rewrite....and using a distance from-spawn based algorithm was about as far as I got as well.... The only problem is, how do you scale it smoothly so that you aren't forced to go out to 25million x/z in order to find the hardest structures? I'm thinking a game-age based system might work...or some combination of the two probably.
This is ignoring the problem of how to actually scale the difficulty of the structures...you need either different structures for different difficulty levels, or a ton of special code/script to handle scaling up the difficulty on any scalable things (npcs/etc). You would also need some way to designate that the structure is scalable, and what elements in it scale...how fast they scale, what they scale to, etc.
I like the idea, but there are quite a few problems to figure out before I could think about implementing it. The easiest solution I can think of now would be have a 'difficulty' requirement that must be met before the structure can spawn, with unique non-scaling/static structures, with the difficulty calculated by a combination of distance from spawn and game-time passed. Still...lots more thought required on the idea.
I'm not sure of the problem here -- is it that you can't click on water to target it with the scanner?
I know that it picks up water just fine, you just need solid blocks bounding the water to initiate the scan. If this is the problem, I could probably configure it to accept clicks on water easily enough (not sure if it would be full-time or only with a modifier key...I'll have to see how it feels once I begin working on it).
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumGood to know about the preserve-blocks. I'm supposing that you are using the per-template settings rather than the per-block-rule settings? Per-template is easy enough to support, and already mostly in-place in the new validation setting (you would merely turn off the leveling clear option, but could leave level-testing enabled)(could still enable specific preserve-options for more granular control over what types). The per-block is more difficult to support, but could be included if needed.
Per-biome block swapping -- yah, I didn't figure too many people used this. In the future I will have a simple 'enableblockswap=true/false' in the validation settings, and will use the vanilla block-swap methods if it is enabled (the ones used to swap blocks for vanilla villages).
Spawners -- the new system is already scanning and duplicating spawners...should have full support for vanilla spawners in the future (keep in mind that vanilla spawners can register/use non-vanilla mobs too!). And I see what you mean by adding AW-accessible blocks to the creative menu to get at the spawners -- I had to use chat commands to give myself spawners just to test the stuff in the first place...because for some silly reason there are no spawner blocks in creative mode (unless you have NEI installed on both client+server).
Chests -- the new system will include both duplication and randomization abilities -- hopefully without having to edit the template. My current thoughts are this: when scanning a chest, peek at the inventory. If the first (and ONLY) item in the inventory is a gold ingot, diamond, or emerald, enable randomization for that chest with loot quality based on the item (gold=low, dia=mid, em=high). If the chest has more than one item in it (or the single item is not one of the triggers), the chest will be flagged as static loot target -- the items it contains will be scanned/exported as-is and duplicated when the template is built.
Validation settings -- I wish I could do the original catapult-mod style validation for structures as well. I hand-crafted that validation per-structure though, to fit..._perfectly_ (or as close to it as I could get
Hopefully though, the new validation stuff will be much easier to understand and manipulate. The current stuff...while all of the settings -do- _something_...I could barely tell you what they do and how they all interact without tracing through the source--and would probably still give incorrect answers most of the time. Spaghetti code at its finest -- Best to do away with that stuff
EDIT: Moved back to .36 and generation works again. Odd.
EDIT: EDIT: Okay. I'm dumb. I realized I commented out some important stuff when I was experimenting. Sorry for the false report.