cckcckcc

I second the praise.  I love the recent updates you have been giving.  It really pumps up the excitement.

Glad it is working now.

Trust me, I have been there.  I was banging my head on the wall for hours on end when I was learning JAS because of the difficulty and lack of good documentation on it.  It's a very powerful mod though, so I stuck through.  My difficulties and respect for JAS inspired me to help others with learning it though.  What we really need is someone to continue CrudeDragos's development, so we can have all the mod's features completed.

22 hours ago, ciekma said:

Thank you for your kind reply. Of course I'm using these commands to remove mobs and observe if they respawn again. /jas canspawnhere com.ghastTFC return green light, but no Ghast are spawned, when Spawnflag force PosY>150 as in above example, or open sky, like here:

http://149.156.194.203/~mczapkie/Train/tmp/tt/download/mc/config/example.zip

Above configs are not changed a lot, I only added ghastTFC and removed bats and zombies from Ocean spawn list (by the way, do we need these bats flying under ocean bed? it is consuming computer resources, which is very busy with chunks generation during boat journey).

I'm fishy, that minecraft refuse to spawn ghasts without solid ground. What about CreatureType.cfg? Can EntityHandlers override creature type spawn tags?

I do not believe there is any way to override creaturetype spawn tags, which may be the source of your issues.  I would definitely test setting your ghastTFC to something other than the MONSTER type.  For testing purposes, try OPENSKY or another creature type you aren't using and delete all its spawn tags--that's how I do it.  If that works, you can create your own creaturetype category later with the necessary spawn tags or lack of them to accommodate the ghast spawning behavior you envision.  Also note that the creature type NONE will never spawn mobs regardless of its spawn tags or config settings.

Let me know if you are confused on how to change the creature type in the entity handler.

Generally its best to define most of your spawn conditions in the creature type config--JAS's creator CrudeDragos envisioned things this way, as it cuts down on a lot of config work by grouping mobs.  Use spawn tags in entity handlers or spawnlist entries when you want to add additional checks to the what is laid out in the creature type.  Entity handlers are the place to put despawn tags, instant despawn tags, and post spawn tags.  If you start inserting spawn tags in several different config files, and want all of them to apply cumulatively, you are going to find that you are stuck with vanilla spawn behavior as well.  That's a limitation of JAS for some reason.

51 minutes ago, ciekma said:

Basically yes, I was just confused because both vanilla and TFC biomes were listed in SpawnListEntries/com.cfg

IF talking about logic operands, I meant "Spawn Operand" field, not || && operands itself.

For example

    "com.ghastTFC": {
      "Type-Enabled": "MONSTER-true",
      "Spawn Operand": "OR",
      "Spawn Tag": "!(posY>150)",
      "Contents": [
        "com.ghastTFC"
      ]
    },

what mean "Spawn Operand": "OR" - probably it is "OR" between "Spawn Tag" and minecraft default tags, but wiki is not...

Basically, yes you are correct, but keep in mind that you can define spawn tags in more than one config file as well. "And" will maintain vanilla spawn requirements and add on to whatever you have in your other config files. If you use "or" it overrides vanilla spawn behaviour and I believe any other spawn tags used in config files that aren't spawnlist entries.

If you are testing, I would definitely use the "or" operand initially, as vanilla minecraft has some strange spawn requirements for mobs that aren't apparent until you start trying to spawn mobs outside their normal environments.

Also, familiarize yourself with the in-game commands, they are indespensable for testing. Do a /jas killall before observing spawns if you aren't already. /jas canspawnhere will tell you what meets all requirements to spawn at a certain biome. Upload the config you want me to take a look.

Quote

I prepared to show changes done to WorldSettings/BASIC/DEFAULT/SpawnListEntries/com.cfg and realised, that there are both vanilla and TFC biomes!
Instead of "Deep Ocean" biome, which doesn't exist in TFC, I should change "com.Deep Ocean". F3 information gives ambiguous information.

Let me know if that fixed your issue.  I figured it was probably something small like that or a syntax error.

Quote

If talking about JAS wiki, I didn't found any comprehensive information, how "Spawn Operand" works, what is a difference between OR/AND.

Good question.  The spawn operand isn't as robust a feature as it could be.  In almost every use of spawn tags, the OR operand ( || ) is going to be sufficient for your needs.  Spawn tags don't allow for some of the more complex statements a coder would expect due to limitations in JAS.

I'm not sure if you have coding experience, but think of the spawn tags as a long IF statements and the && (and) or || (or) operands as being a way to nest these IF statements.  Additionally, spawn tags have the somewhat strange behavior of being not statements.  Let's look at a basic spawn tag for an example:

"Spawn Tag":  "liquid({0,0,0},{0,0,0})||normal({0,0,0},{0,0,0})||normal({0,0,0},{0,1,0})||!opaque({0,0,0},{0,-1,0})"

In plain English, this would read as:  DO NOT spawn this mob if the block it would spawn in is liquid "liquid({0,0,0},{0,0,0})", or if the block it would spawn in is solid "normal({0,0,0},{0,0,0})", or if the block 1 unit above spawn is solid  "normal({0,0,0},{0,1,0})", or if the block it would spawn on is not opaque "!opaque({0,0,0},{0,-1,0})".

Basically this is vanilla mob spawn behavior.  Vanilla minecraft doesn't allow for most 2 unit tall mobs to spawn in solid blocks, water, or on top of opaque blocks.  So when are && operands useful?  Let's imagine if we wanted to create a more complex spawn behavior:

"Spawn Tag": "normal({0,0,0},{0,0,0})&&!opaque({0,0,0},{0,0,0})"

This would read as:  DO NOT spawn this mob if the block it would spawn in is solid and opaque.  If the block the mob would spawn in, though, is not opaque but is still solid (i.e. glass) the mob could still spawn.  This spawn tag would allow for a mob to spawn inside blocks like glass or ice, but not dirt or cobblestone.

There are limitations though.  JAS looks at each statement separated by an || (or) operand individually, and all statements linked by an && (and) operand together.  For instance: 

"Spawn Tag": "normal({0,0,0},{0,0,0})&&!opaque({0,0,0},{0,0,0})||liquid({0,0,0},{0,0,0})&&opaque({0,0,0},{0,0,0})"

This tag would not spawn a mob in blocks that are solid and opaque, or liquid and non-opaque as one would expect.  Rather, it would not spawn mobs in blocks that are solid, opaque , non-opaque, or in liquid, which would not make much sense because all blocks are either opaque or not opaque.  This spawn tag would effectively prevent a mob from spawning anywhere.

A bit long winded, but I hope that clears up some of your questions.  Let me know if you don't understand or if I didn't answer your question fully.

If you could upload your configs I would take a look.  Hard to say what is specifically wrong or whether it is some likely incompatibility without seeing the entirety of the configs.

Edit:  To clarify, only your creaturetype.cfg, biomegroups.cfg, and spawnlist config file for TFC (likely named something like TFC.cfg in your spawnlist folder) would probably be relevant.

Also, they have recently been updated/improving the JAS wiki located on their github at https://github.com/ProjectZulu/JustAnotherSpawner/wiki

I would definitely recommend checking that out if you are new to JAS.  There is lots of good info and examples there.

Yep, sorry didn't quote--I was being lazy.  Good to know it would be simple to code, as I don't know much about TFC's API.

It's a good point, I hadn't considered, that you don't actually need to look at the calendar date for seasonal spawns.  TFC temperatures should be sufficient for any ambient mob I can really think of.  Also, if you are still looking for ideas for winter spawns, I would throw out there that American Robins are one of the few birds that don't fly north during the winter (at least where I live in Midwest America where it gets pretty frigid), so you could at least spawn those in most winter temperatures, unless perhaps were talking the arctic cold.  

I think he has a good point about seasonal variations though.  It wouldn't make much sense for butterflies to spawn on a singular grass block, surrounded by snow, in the middle of winter.  Of course, if you were in an equatorial region, it would make sense to see butterflies in winter.  The difficulty would be in managing the complexity necessary to maintain such seasonal/climate relationships, but I don't think it would be impossible.  It may be of concern whether it could be coded in a resource non-intensive way though.

  Seasonal tracking would go a long way in integrating ambient mob spawning in a way that the various general mob spawning mods, like JAS, cannot do, so I hope you will consider it.

What are the hurdles to even implementing vanilla village generation, if I may inquire?  That may be an important question to ask, as I believe Millenaire uses vanilla mechanics to place its custom villages/villager mobs and then goes from there.

This looks awesome!  Glad to see so much progress already.

If I could make one suggestion during development, it would be to include modularity through a config file.  Since your addon would encompass a span of somewhat unrelated features, it would be nice to turn certain ones on and off if individuals do not desire one or the other.  Right now the categories look like, crafting table mechanics, volumetric crafting, mobs, and snow mechanics.

Well the wiki is probably right then, I guess I recalled incorrectly.  Let me know if you need any help with JAS configs though.  The MC forum thread for JAS is a good source for help, but the creator CrudeDragos is pretty inactive, except for looking at github bug reports occasionally, so you are unlikely to find definitive answers on some of the more complex spawning mechanics in my experience.  Literally almost every page of the thread has something interesting/useful to read.  Fair warning though, not all of JAS's complex spawn tags work perfectly.

JAS shouldn't affect any mob spawning as long as you don't specifically try to spawn those mobs with JAS.  For instance, I did some extensive config work on a modpack, but allowed Thaumcraft to completely handle its own spawns, which worked very well.

I have plans to work with JAS and TFC in the near future (once i get a decent rig) and I would be interested in any good configs you come up with.  It saves a lot of time to share work.  What I have currently is mostly tailored towards Mo'Creatures and Biomes O'Plenty, but I did some complex spawn tags related to weather, phases of the moon, and NBT values.  The ambient spawns of MoC in particular easily add a lot of depth and feel to the environment IMO without much legwork.  I'm also interested in Mob Properties setups.  A lot of testing is needed for configuring mob spawns, especially if you intend to balance them with TFC.  That's the biggest time sink in my experience.

I'm pretty sure I read somewhere TFC's passive mobs all have a chance of respawning and despawning already by vanilla TFC mechanics.  On my current world, before taming some cows, they would occassionally disappear out of a fenced in area and be located 1000s of blocks away in the area they originally spawned, which leads me to believe they are despawning and respawning.  Having any familiarity with the animal seems to prevent despawning.  Its probably just not very noticeable that passives despawn and respawn in part because there is a very low chance and because they seem to respawn in roughly the same spot every time.

I am pretty good with JAS, but I haven't used it with TFC yet.  You are going to be pretty limited on your spawning behavior if you are trying to do it by biome in TFC, and its not going to seem very TFC-like.  There is no way to check for temperature or precipitation values through JAS.  Your best bet would be to try some spawn tags that search for blocks located in only certain climates--trees perhaps.

The better boats mod does quite a bit to fix the desync issue.  Boat exploration is almost enjoyable with it, at least until you start getting chunk generation lag--just relog when you do.

The chisel will not be in TFC2 due to the limitations of Minecraft 1.8. In order to just add detailed mode, we would have to create 512! json files for the block models. That's factorial, not excitement. As in 512*511*510*509... etc, which results in a number that has 1,167 digits in it. The number one million only has 7 digits in it.

Sort of off topic, I know, but I'm curious how the new "chisel and bits" mod for 1.8 accomplishes this functionality then.  From your explanation it would be quite impossible to code, so they must have come at it from another angle.  If you haven't seen it, you should check it out.  Its very TFCesque in how it works.  On Direwolf20's server play season 8 series they even describe it as working "basically like TerraFirma Craft's chiseling".

I would be very dismayed if this awesome feature didn't make it into TFC2.  I always felt that it was a small but important feature missing from TFC and minecraft in general.  Enviromine's structural integrity system was okay, but I found it lacking and overly confusing in a lot of its features.  And it didn't work with TFC last i knew 

Hey there,

I'm working on a personal pack similarly integrating GT and TFC.  However, I'm using GT5 experimental instead of GT6 because of personal tastes.  I have encountered that my Terrafirmacraft coppers and irons are all unifying to tetrahedrite and magnetite after being mined.  I'm curious if you ran into the same issue with GT6 and if this is the "world unification" problem discussed.  I have inventory unification turned off and the various terrafirmacraft ores in unification.cfg set to "true".