delvr

On 5/22/2018 at 2:14 PM, vladthemad said:

Well, here's to hoping you still come and check this thread...I appear locked out of my minecraft forum account for some reason! With your latest version (and possibly others?) of 3.3 and Farkseek 2.0.1 I'm running into a really weird issue. I've tested this with just TFC and those two mods, oh and it looks like codechickenlib now that I check my mod folder. Basically what's happening is any blocks that fall through TFC physics like dirt and gravel that then land on TFC tall grass, don't crush the grass. They just jump back up and fall down, repeating forever.

Alright, just released v0.3.4 which should fix this (along with a minor 2-year old issue because why not). Let me know if it works for you!

On 5/24/2018 at 2:36 AM, drkoaeg said:

My version (0.3.1) does not have any config file. Did you create one?

It's to enable shaders for Streams blocks. Check the top post FAQ "How do I make shaders work with the river blocks?" for details.

7 hours ago, vladthemad said:

Well, here's to hoping you still come and check this thread...I appear locked out of my minecraft forum account for some reason! With your latest version (and possibly others?) of 3.3 and Farkseek 2.0.1 I'm running into a really weird issue. I've tested this with just TFC and those two mods, oh and it looks like codechickenlib now that I check my mod folder. Basically what's happening is any blocks that fall through TFC physics like dirt and gravel that then land on TFC tall grass, don't crush the grass. They just jump back up and fall down, repeating forever.

Don't worry, I still get notifications for this thread. I see someone - I assume you with a different handle - made an issue on GitHub so I'll update that with my findings: https://github.com/delvr/Streams/issues/63

Hello again,

there were some issues with TFC in the recent 0.3 release so I just uploaded v0.3.1 with TFC-specific fixes, notably for the soil types near streams as well as general performance. Note however that due to cave-related optimizations, streams may appear in different spots compared to 0.3 so please generate new worlds when using this version.

Cheers,

-delvr.

Hi players,

I've released Streams 1.7.10-0.3 for Farseek 1.7.10-2.0 which backports some of the fixes made in recent versions for vanilla, and adds some experimental performance improvements for TFC. Please give it a try and let me know if runs better for you. There's also a new, configurable version of Repose which you can find here.

Cheers!

-delvr.

On 8/2/2016 at 6:13 PM, vladthemad said:

Any place I can find the older version for 1.7.10 that doesn't use the tunnels? I like the mod a lot, but the newer tunnel mechanism seems to leave a lot of floating rock and dirt in random places. If there's a config file to control this, I'm not finding it anywhere.

Hi vladthemad, there's no config file but I just made the pre-tunnels 1.7.10 version available at https://minecraft.curseforge.com/projects/streams/files/2261828.

Nope, i dont see a streams config folder and there is no config for the water wheel.

Edit: Never mind i had to put it up wierdly it works

Glad you made it work! Some water-related mods only work with "flat" river blocks and others only with "slanted" blocks. See my explanation here.

Hey, this is a *lovely* mod.  I've noticed one odd bug which may be a part of terrrafirmacraft itself, not sure.  Trees off to the side of streams sometimes have one log on the ground, and then several blocks up the rest of the tree simply floats in place, like so: 

View post on imgur.com

One of the best mods I've ever seen.  For TFC or vanilla Minecraft.  I can't wait to update this on our server.  Thank you. 

 

So the incremental build will not replace the current rivers, but only affect newly generated terrain?

While it's true that updating Streams in an existing world should not affect current rivers, there's no guarantee that partially-generated river zones won't get messed up this way. The incremental upgrade should place rivers in the same spots for a given seed, but the elevations might change which could lead to weirdness between old and new chunks. So if you still want to try upgrading an existing world, be sure to make a backup!

Thanks - I think what you're saying is "RTFM"

(...)

In my console log I see the following:

"edit your shader's gbuffers_wqater.wsh file"

 

I don't have that file - I only have a file 'gbuffers_water.vsh'  which contains the line mentioned

I guess we both, in our own unique way, had to RTFM :-)

• How do I make shaders work with the river blocks? You need to specify the block IDs in your shader configuration. Enable the game log (as explained in the answer above) and look for a message starting with "Shader configuration". There you will find a pre-formatted configuration line to put in the specified config file. The block IDs will also include TFC water blocks, but will change with every combination of mods so make sure you re-check it when adding/removing mods.

Erm...  There is no "answer above" - can you elucidate on this, please?

Hi guys, I've just released Streams version 0.2. This new version replaces the unpopular river canyons in mountains with spooky underground tunnels for you to explore.

This is an incremental update of the current generator, that preserves existing river layouts while swapping caves for canyons (and changing the elevations a bit). So if you've been saving a cool mountain seed that was disfigured by river canyons, you can generate a new world with that same seed and see if the rivers look nicer now.

A new sample seed and coordinates is provided in the top post for those wanting to give the new tunnels a quick try. (The sample 0.1.x seed will also has some now.) Have fun rafting and spelunking, and let me know of any issues.

p.s. I've also released a patch to the Farseek API (1.0.11) that attemps to fix a worldgen crash with certain mods. Updating is not necessary to use the latest Streams, but is recommended.

The gold plan is simply looking for blocks of Material.water, with a damage value/metadata greater than 0 and that the player is right-clicking on the top side of the block underneath it. In theory, any mod liquid should already be extending Material.water, so the only compatibility issue I could think of would be if their flowing water doesn't use metadata to track flowing and all the liquid blocks have a damage value of 0.

So generally if you're using an item that expects flowing water (metadata >0) such as a gold pan, it will work only on the portions of streams that are less than a full block in height, such as gently sloping surfaces. If you're using an item that expects source water (metadata = 0), it will work only on full-block, flat river sections. Items that only care about the block's Material being water will work everywhere. Items that look for specific water block IDs are evil and should be changed to something more mod-friendly.

For any modders here interested in the internals of Streams: I just released v0.1.6. It's only a Forge version upgrade but more importantly, it's the first version of Streams to go open-source on GitHub: https://github.com/delvr/Streams . If I may quote a warning from my post on the main Minecraft Forums:

I originally planned to wait until the ongoing river rewrite is complete to open-source the code, partly because the code as it stands is a big mess and very little of it will remain intact in 0.2. But since the new version is taking longer than anticipated, I want to give the modding community a chance to tweak the current version and perhaps improve compatibility with their own mods. That said, please keep in mind that in addition to being Scala (not Java), this is ALPHA code and it's very light on comments compared to the Farseek API. The fixed-flow river blocks will remain relatively stable in the next version, but the complex river components (based on hand-drawn flow plans that get translated, rotated, mirrored and stretched) will be completely gone and replaced with curves drawn across the boundaries of a drainage basin grid. So while suggestions for tweaks are welcome, I can't recommend anyone trying to make major changes within the old river component framework at this point.

Meanwhile I'll still be working on 0.2 whenever I can, and posting both the WIP source and pictures once they're stable enough.
 

I just uploaded a new version of the Farseek API (1.0.9) that makes Streams compatible with TFC 0.79.23+. You don't need to update Streams itself, only Farseek.

I see this thread is marked [solved] so this might not be needed, but I'd like to share some information from my investigation of a similar problem with Streams (http://terrafirmacraft.com/f/topic/7850-tfc-07917-streams-real-flowing-rivers/?p=110832).Some TFC generators are not using the standard +8 x/z block offset when populating chunks with objects such as trees. This means that instead of generating in a 16x16 zone centered on the intersection of the 4 chunks being populated, they generate in the Northwest chunk without the benefit of a full 8-block buffer around them. So a branch radiating out of a tree trunk at position (0, 0) may well reach out into a neighboring chunk to the North or West, causing recursive generation of new chunks. The fact that the "tendrils" are all headed Northwest is surely no coincidence here. That said, if this happens mostly in oceans it's not likely to be caused by trees but it could be a variety of other things such as (making up an example) a piece of seaweed checking its neighbors during generation for some reason.For the tree-gen case see https://github.com/Deadrik/TFCraft/blob/Build79/src/Common/com/bioxx/tfc/WorldGen/Generators/WorldGenForests.java ; you'll see that generateJungle uses the offset (lines 220-221) but not generateForest (lines 60-61). I may have overlooked something like the offset being applied later, but the inconsistency here is worth investigating.

I think you mean 3000 blocks not 30000 blocks. Try throwing journeymap in the SSP world you replicated this in. Do the automapping. I would guess that you will see long stretches of generated chunks stretching out from your map. This is the issue that AnodeCathode reported earlier today. We've been testing it and it happens in Vanilla TFC. I think that streams, either tips the balance to crashes or just appears in the stack trace due to its role in worldgen.

I looked into this and as Bunsan suggests, it doesn't seem that Streams is directly causing the excessive chunk-gen recursion seen here. It might be causing it to happen more often since it generates chunks at a further distance from the player than most other structures.Not sure about the root issue, but looking at the TFC tree gen code (seen in the crash log) I notice that not all generators are using the standard +8 offset within the 4-chunk group being populated (i.e. they spawn in the North-West chunk instead of at the intersection of all 4 chunks). This means that the trunks don't have a full 8-block buffer around themselves and can cause recursive generation in their neighbors. Bunsan - perhaps the devs could take a look at this?The code I'm referring to is in https://github.com/Deadrik/TFCraft/blob/Build79/src/Common/com/bioxx/tfc/WorldGen/Generators/WorldGenForests.java; you'll see that generateJungle uses the offset (lines 220-221) but not generateForest (lines 60-61). And it doesn't seem like the individual tree generators are doing it either, unless there's something I overlooked.

Edit: I added this information to the related thread at http://terrafirmacraft.com/f/topic/8470-solved7920-tfc-generating-chunks-off-into-the-ocean-performance-craters/?p=110835

I have been testing this mod out on my server, and I am starting to get multiple crashes due to "Exception getting block type in world" has anyone else seen this issue?

 

Here is the server crash log (long) http://pastebin.com/2hG0yEmi

Thanks for reporting this Red3Tango, I will take a look.

There's a problem with this mod with both leather water sac and smart moving, when using water sac, i can't gather water from streams that have a low water level/flowing, unlike with clay jugs and buckets, and with smartmoving mod it's the same, i can't drink from streams that have a low water level, everything's alright with still water or flowing water that has a "high" level (like more than half a block) though, i don't mind directly drinking from it, because i can gather water with a jug, but the leather water sac issue is sort of annoying.

I'll take a look and see if I can change this, it depends on how these mods check for valid water to use with their items or actions.

Also Streams should indeed be compatible with the latest TFC (thanks Kitty for answering) so if you find a regression bug please let me know.

In other news I'm still working on the next major update, sorry I haven't posted much but I'll start providing screenshots as soon as the big infrastructure rewrite is done. Thanks everyone for their patience.

Out of curiosity - how does one fix classloader verifier exception? By changing the load order?

Good question! Answering takes a bit of technical explanation. Most of this stuff I've learned fairly recently so I might be wrong on some details.

I assume the error you refer to is "Expecting a stackmap frame" as seen here: http://pastebin.com/aU0yc5LF

Missing stackmap frame errors are caused by ASM method patches not recomputing frames in the methods they visit. Stackmap frames are a snapshot of the expected state of local and stack variables at various points in the function, and are mandatory in modern (JDK7+) classes. They can be ignored by using the FailOverToOldVerifier VM option, but not everyone uses or even knows about it and support for it is not garanteed in the future. So what many mods do is using the COMPUTE_FRAMES flag in their ASM ClassWriters to recompute all frames manually, but the implementation of that flag causes extra classes to be recursively loaded during transformation through the classloader's getCommonSuperClass(), which can cause major problems in Forge for reasons I don't yet fully understand. I hear that some modders are using a classloader with a custom implementation of getCommonSuperclass; in my case I chose to visit the stack frames manually (with MethodVisitor.visitFrame()) instead of using COMPUTE_FRAMES since I have a small amount of generic ASM code in my method patching API. You can see my implementation (in Scala) here: https://github.com/delvr/Farseek/blob/master/src/main/scala/farseek/core/MethodReplacer.scalaSo it's a difficult problem; even the Forge devs are having trouble with it. See the comments on this recent Forge commit: https://github.com/MinecraftForge/MinecraftForge/commit/06398fa25990b458ee3183e0cf9066a3a75f221e 

Some Pictures of the Base: http://imgur.com/a/L4wTT

Just want to say this mod continues to be great; I love everything about it. My servermates and I are currently digging an extensive tunnel and bridge system in and around a river canyon and it is amazingly beautiful. I love it. I'll be checking out Repose soon too.

I released patch 1.0.5 for the Farseek API that fixes a crash with Immibis mods and Mekanism. There are no feature changes so you only need to update if you want to play with those mods.

Thank you.I gave Repose a try in my pack and it crashed. It looks like there is an issue with Immibis's Multipart, which I assume is part of ImmibisCore maybe radiologic. Sorry I don't have time to chase this down atm, but here is the crash report http://pastebin.com/aU0yc5LFOh and now Mek. http://pastebin.com/CP8ervMX Mek is so integrated in my pack I can't remove it to test further.

Delvr, thank you for creating this as it truly brings my modpack to life! Nothing beats walking through a forest and finding a river spawned and waiting. I have found quite a few gems of rivers with nice extensive watersheds as a matter of fact! Very rarely the river spawns in a strange way like doubling back onitself to tightly to make sense but rivers like that are exceptionally rare anyway.

Hey delvr you need to edit the original post to say 0.79.17.BTW Thank you very much for this update.