That is not normal, unless you were in the middle of an ocean.
Pylons and repeaters have no need or benefit to being loaded.
Mod Feedback ChromatiCraft questions and suggestions
- Thread starter Reika
- Start date
-
The FTB Forum is now read-only, and is here as an archive. To participate in our community discussions, please join our Discord! https://ftb.team/discord
TBH, I installed it after the world was created, just remembered that :S
It would be cool if some could also spawn in caves!
But IMHO, I would not want them to pop up in worlds like TF, deep dark, aroma mining world or witchery dream world. I feel like they should be set to spawn only in the overworld (which is something with worldgen that annoys me a lot *kofkofHarvestcraftineverysinglepossibleworldkofkof*
They can only spawn if they can see the sky, ruling out places like caves and the deep dark.
The issue with Twilight Forest pylon gen is that they have a strong tendency to spawn in trees, which is awkward.
Really? I have seen a couple spawn in Natura redwoods, but that was in the overworld.
Just in the biome where my entrance portal spawned:
EDIT: Disregard that, here's a couple more nearby tree-pylons in a different biome:
Last edited:
Perhaps tossing a vanilla stone slab in front of a pylon and allowing the pylon to zap it would imbue it with Chromaticraft power. Placing the Chromatislab and right clicking it would open a magical documentation UI (though I'll admit I have little idea what that would look like). To unlock more information available via the Chromatislab (and possibly crafting recipies TC-style), the player will need to toss it at pylons of all different colors, ideally updating the Chromatislab graphically, with increasingly advanced information as the Chromatislab is imbued with more colors.
If you're going for tiered casting table setups, requiring the 16-color Chromatislab to be crafted with e.g. crystal shards in a casting table to unlock something like an Infused Chromatislab would be a way of introducing progression gating. Possibly more than once depending on precisely how tiered Chromaticraft progession is intended to be.
Just an idea.
Last edited:
I have a technical problem with ChromatiCraft that I would like to see if anyone has a solution to:
For those unfamiliar with the transmission mechanics of ChromatiCraft:
The pylons are the sources of energy, which can transmit it to receivers. Things like the Casting and Ritual tables, as well as some "powered" blocks, are examples of receivers. As both the pylons and the receivers have a limited range, and all connections must have a clear line of sight, repeaters (which have their own range limit) are almost always necessary to "relay" the energy.
For performance reasons, the location and status of all network tiles (sources, receivers, and repeaters) are cached.
From a more technical side, here is what happens when a request is made to the network:
The networker logs a request from a given location, with a specified color, range, and transmission amount. The network then scans over the cache of tiles, collecting only repeaters and sources, and only those within range, and capable of transmitting that color. It then checks each of them to see if there is a clean line of sight. If so, it moves to that location and repeats the process, hopefully eventually finding a source. If no source is found after exhausting all capable those collected repeaters, or there are no operational repeaters of that color within range, it "steps back" to the previous location and tries the next repeater on that level of the list.
If it finds a source, that path is cached for future requests of that color from the original receiver (thus ridding the need of a recalculation for that location unless the network changes) and returned for additional logic.
(More programming-minded users will note that this is a fairly standard recursive search algorithm, and those following my mods' code will notice that this is very similar to ElectriCraft network pathing logic.).
Here is the problem:
With very large (hundreds of repeaters) networks that nonetheless cannot transmit certain colors to the requesting location, any such requests to that network become computationally expensive, as the search tries to exhaust every routing possibility yet never being satisfied. This manifests itself as a significant lag spike that if repeated frequently can see a server time out all of its players.
Compounding this is that the "find nearby repeaters and sources" logic runs over the entire cache of tiles every step, because as far as I can tell it is not possible for the cache to be presorted for every request location.
Here is the network in question. Pylons are denoted with solid circles of their color, while connected ones also have a box around them. Dotted lines roughly represent repeater trails.
For those unfamiliar with the transmission mechanics of ChromatiCraft:
The pylons are the sources of energy, which can transmit it to receivers. Things like the Casting and Ritual tables, as well as some "powered" blocks, are examples of receivers. As both the pylons and the receivers have a limited range, and all connections must have a clear line of sight, repeaters (which have their own range limit) are almost always necessary to "relay" the energy.
For performance reasons, the location and status of all network tiles (sources, receivers, and repeaters) are cached.
From a more technical side, here is what happens when a request is made to the network:
The networker logs a request from a given location, with a specified color, range, and transmission amount. The network then scans over the cache of tiles, collecting only repeaters and sources, and only those within range, and capable of transmitting that color. It then checks each of them to see if there is a clean line of sight. If so, it moves to that location and repeats the process, hopefully eventually finding a source. If no source is found after exhausting all capable those collected repeaters, or there are no operational repeaters of that color within range, it "steps back" to the previous location and tries the next repeater on that level of the list.
If it finds a source, that path is cached for future requests of that color from the original receiver (thus ridding the need of a recalculation for that location unless the network changes) and returned for additional logic.
(More programming-minded users will note that this is a fairly standard recursive search algorithm, and those following my mods' code will notice that this is very similar to ElectriCraft network pathing logic.).
Here is the problem:
With very large (hundreds of repeaters) networks that nonetheless cannot transmit certain colors to the requesting location, any such requests to that network become computationally expensive, as the search tries to exhaust every routing possibility yet never being satisfied. This manifests itself as a significant lag spike that if repeated frequently can see a server time out all of its players.
Compounding this is that the "find nearby repeaters and sources" logic runs over the entire cache of tiles every step, because as far as I can tell it is not possible for the cache to be presorted for every request location.
Here is the network in question. Pylons are denoted with solid circles of their color, while connected ones also have a box around them. Dotted lines roughly represent repeater trails.
You said that you dont like the idea of a book, what about using a cheaper and simpler version of that player infusion thing that, instead of infusing powers into the player, simply displays info? Or maybe something similar to a multi-block projector structure?
This might require a block found in dungeons or crafted, acting as some kind of repository of knowledge similar to a Thaumnomicon. After a bit of teching, one would be able to make a mobile version that can be taken anywhere.
Or, there could be ruins with the above pre-made within them, and you'd have to find one to be able to gain access to its knowledge. You could then duplicate the structure elsewhere, which would ideally take all common blocks such as stones and the only special thing that you would need to take from the ruins is the projector itself.
Also, it would be cool if found projector blocks where "Broken" or merely a fragment of a larger repository of knowledge, encouraging the player to search the world for more ruins. This could follow a pre-set progression, where the knowledge unlocked by a projector is dependent on the player who activates it.
This might require a block found in dungeons or crafted, acting as some kind of repository of knowledge similar to a Thaumnomicon. After a bit of teching, one would be able to make a mobile version that can be taken anywhere.
Or, there could be ruins with the above pre-made within them, and you'd have to find one to be able to gain access to its knowledge. You could then duplicate the structure elsewhere, which would ideally take all common blocks such as stones and the only special thing that you would need to take from the ruins is the projector itself.
Also, it would be cool if found projector blocks where "Broken" or merely a fragment of a larger repository of knowledge, encouraging the player to search the world for more ruins. This could follow a pre-set progression, where the knowledge unlocked by a projector is dependent on the player who activates it.
So what if you generated different graphs for each color and just searched those for an appropriate match? Also you might be able to replace repeaters that have only 2 connections with straight connections and assign distance costs to each connection which will allow you to run some smarter algorithm on it. As far as i understand you're doing an exhaustive depht first search on an unpruned graph right now. But then I'm not a rocket scientist.
So if the Pylons are the sources of power, where do they replenish there power from when they get drained while crafting? I saw in the video that they kill mobs, is that their power source?
Also, is there a way to convert lumens into shaft power? Even if only for certain types. (Or maybe requiring a combination of all types?)
And what does the laser u showed in the video near the end actually do? The one were u could add lenses.
Reika, will you allow users to "store" energy accumulated? I had this thought whilst driving this morning that it would be a neat in-universe mechanism if your energy-storage were organically represented. I picture a crystal that you place as a "seed" and stores X amount of energy. But when you reach the limit potential of that crystal, it grows in a semi-random direction.
I love the idea of a gigantic crystal tree storing tons and tons of energy, towering over my base and glimmering with power.
As you consume the power, the "nodes" at the edges might turn black and then "crisp off" so that the entire thing shrinks back with usage.
I love the idea of a gigantic crystal tree storing tons and tons of energy, towering over my base and glimmering with power.
As you consume the power, the "nodes" at the edges might turn black and then "crisp off" so that the entire thing shrinks back with usage.
So as far as I'm understanding, you're trying to find a route from your consumer to a valid producer over the least number of relays or the smallest distance. Different relays can carry different colors, with multiaural ones carrying all and single color relays only carrying one color. That makes it a graph, doesn't it? So say we have a request for a white packed over the entire graph. So the way you're doing it right now, if I'm not misunderstanding thing is that once a request gets made, it recursively searches the graph till it finds a valid connection.
The first improvement efficiency wise would be pruning the graph so that only routes carrying whites get searched. This way you should have a way smaller number of nodes, since you don't even consider routes over say black relays or paths leading to purple producers. Relays that in the new graph only have 2 connections can be represented as a straight line due to the fact that there aren't any branching options, any path going through these relays will incurr the same path cost. Similarily, relays only having one connection can be pruned from the search space as well, since they don't lead to anything, and routes going over them are always inferior.
The second improvement would be assigning path costs and using a heuristic. The minimum distance you can cover is the euclidean distance from the consumer to the producer, so if you have to decide where to branch, you go down the route where the new minimum distance + the covered distance is smaller than all the other options. That way if you had a star shape of multiaural repeaters with a depht of 2, you end up picking the one that most directly points toward the destination producer. Regarding sudden obstructions in the path, you should be able to simply toss the path and back up again, and for new repeaters you'll simply need to add paths to directly connected repeaters with their associated path costs. The reason I suggested using A* was that it is an admissible search algorithm, which will given an admissible heuristic always return the optimal route, that it's relaxable depending on graph size, (relaxed A* will return suboptimal solutions but search a lot faster), and that it's not too hard to implement. So with graphs sorted by color and graph size dependent relaxation you should be able to do very large networks.
The first improvement efficiency wise would be pruning the graph so that only routes carrying whites get searched. This way you should have a way smaller number of nodes, since you don't even consider routes over say black relays or paths leading to purple producers. Relays that in the new graph only have 2 connections can be represented as a straight line due to the fact that there aren't any branching options, any path going through these relays will incurr the same path cost. Similarily, relays only having one connection can be pruned from the search space as well, since they don't lead to anything, and routes going over them are always inferior.
The second improvement would be assigning path costs and using a heuristic. The minimum distance you can cover is the euclidean distance from the consumer to the producer, so if you have to decide where to branch, you go down the route where the new minimum distance + the covered distance is smaller than all the other options. That way if you had a star shape of multiaural repeaters with a depht of 2, you end up picking the one that most directly points toward the destination producer. Regarding sudden obstructions in the path, you should be able to simply toss the path and back up again, and for new repeaters you'll simply need to add paths to directly connected repeaters with their associated path costs. The reason I suggested using A* was that it is an admissible search algorithm, which will given an admissible heuristic always return the optimal route, that it's relaxable depending on graph size, (relaxed A* will return suboptimal solutions but search a lot faster), and that it's not too hard to implement. So with graphs sorted by color and graph size dependent relaxation you should be able to do very large networks.
They recharge slowly on their own, but can be boosted with late-game "Power Crystals".
No.
It differs depending on the color. Orange melts things (not rock), and light blue (or was it green?) accelerates crop growth dramatically.
I have been planning a battery of sorts, and this is an interesting idea. How would it manage confined spaces?
I only do search paths capable of carrying the requested color, and the length of a path is irrelevant. I do not try to or care about finding the shortest path.
Good question. Placing "walls" around it would make it too easy for players to bonzai-shape their crystal into a boring cube.
Perhaps make nodes that are adjacent to confining blocks (non-air, non-crystal) operate less efficiently.