[MOD 0.16-0.17] Ribbon Maze 0.7.0

[mrvn]

What happens to the walls if someone uses cliff explosives ?

Currently? The wall dissapears but the black region remains uncrossable.

My thinking though would be that cliff explosives should blast a tunnel and new cliffs would be added around the blast site. So you could make a break in the wall and create extra loops but not get onto the wall itself. Haven't looked into how to catch cliff explosives being used in LUA or if you reasonably can at all. Worst case cliff explosives need to be removed from the game. Maybe have a tunnel borer entity instead that bore a tunnel through a wall over time. Similar to the terraformer entity now.

[mrvn]

Since I had problems of finding any Crotinium or Jivolite in the mazes I've looked some more into the resource setup.

Resources have an autoplace table that has some entries the RibbonMaze should consider. The exact maths is described in the wiki so here just some remarks. First the coverage field gives the fraction of tiles in the map that should have that resource. That pretty much directly translates into a probability for each resource. It also holds the amount of the ore that should be present in the starting area. The existence of that field could be used to include resources in the mixed fields and to make sure the maze has them in the starting area. The amount could be used to set probabilities for the mixed fields and then the richness could be scaled to get the listed amounts.

Would you be opposed to ripping out the existing resource handling and replacing it with one based on the autoplace settings the resource provides? That way it would simply work with any mod in the proportions the mod author intended.

[H8UL]

Interesting stuff with the new maze styles, glad to see this has provoked discussion.

Since I had problems of finding any Crotinium or Jivolite in the mazes I've looked some more into the resource setup.

Resources have an autoplace table that has some entries the RibbonMaze should consider. The exact maths is described in the wiki so here just some remarks. First the coverage field gives the fraction of tiles in the map that should have that resource. That pretty much directly translates into a probability for each resource. It also holds the amount of the ore that should be present in the starting area. The existence of that field could be used to include resources in the mixed fields and to make sure the maze has them in the starting area. The amount could be used to set probabilities for the mixed fields and then the richness could be scaled to get the listed amounts.

Would you be opposed to ripping out the existing resource handling and replacing it with one based on the autoplace settings the resource provides? That way it would simply work with any mod in the proportions the mod author intended.

Trust me, I've already tried that route, unfortunately most of that information isn't available at the control stage. Here's my mod interface request relating to it: viewtopic.php?f=28&t=63786

I already do take into account what should and shouldn't be in the starting area using a bit of trickery:

Code: Select all

local function guessAvoidStartingArea(resource)
    local prototype = game.entity_prototypes[resource]
    if prototype and prototype.autoplace_specification and prototype.autoplace_specification.peaks then
        -- look for a peak that reduces the influence in the starting area (as done with uranium, and certain angel's ores):
        for _,v in ipairs(prototype.autoplace_specification.peaks) do
            if v.influence and v.starting_area_weight_optimal and v.influence <= -1 and v.starting_area_weight_optimal == 1 then
                return true
            end
        end
    end
    return false
end

To reiterate what I said in my previous reply, to balance Crotinium and Jivolite, I will make it available at shorter corridor lengths (minimum 4, instead of 6). Hopefully won't be too long before a new release.

[mrvn]

Interesting stuff with the new maze styles, glad to see this has provoked discussion.

Since I had problems of finding any Crotinium or Jivolite in the mazes I've looked some more into the resource setup.

Resources have an autoplace table that has some entries the RibbonMaze should consider. The exact maths is described in the wiki so here just some remarks. First the coverage field gives the fraction of tiles in the map that should have that resource. That pretty much directly translates into a probability for each resource. It also holds the amount of the ore that should be present in the starting area. The existence of that field could be used to include resources in the mixed fields and to make sure the maze has them in the starting area. The amount could be used to set probabilities for the mixed fields and then the richness could be scaled to get the listed amounts.

Would you be opposed to ripping out the existing resource handling and replacing it with one based on the autoplace settings the resource provides? That way it would simply work with any mod in the proportions the mod author intended.

Trust me, I've already tried that route, unfortunately most of that information isn't available at the control stage. Here's my mod interface request relating to it: viewtopic.php?f=28&t=63786

I already do take into account what should and shouldn't be in the starting area using a bit of trickery:

Code: Select all

local function guessAvoidStartingArea(resource)
    local prototype = game.entity_prototypes[resource]
    if prototype and prototype.autoplace_specification and prototype.autoplace_specification.peaks then
        -- look for a peak that reduces the influence in the starting area (as done with uranium, and certain angel's ores):
        for _,v in ipairs(prototype.autoplace_specification.peaks) do
            if v.influence and v.starting_area_weight_optimal and v.influence <= -1 and v.starting_area_weight_optimal == 1 then
                return true
            end
        end
    end
    return false
end

To reiterate what I said in my previous reply, to balance Crotinium and Jivolite, I will make it available at shorter corridor lengths (minimum 4, instead of 6). Hopefully won't be too long before a new release.

I noticed that when I tried disabling the resource generation in the first place. Because why autoplace resources if the mod then removed them. There seems to be a hack being used to stuff the information into floating text prototypes into the order field and extract them again in control.lua. That works nicely to preserve the data while setting it to nil in the real prototype. With that I have all the data later on.

As for the peaks they seem to only disable, as in make it so unlikely they never appear there, resources while the amount is a definite indicator that the resource MUST be in the starting area and how much of it. I want to use that to set the richness of the first few ore fields to give that amount.

[mrvn]

Ok, last post about my maze here. I had too change too much of it for what I wanted so I decided to make a fresh mod out of it. First alpha is now up under the name Hexagonal Maze (hexmaze). Any comments about it please start a new thread.

Just three more screenshots to wet your appetides and then I'm gone:

clifs as walls

thumbnail.png (1.41 MiB) Viewed 4070 times

cliff closeup

thumbnail2.png (412.33 KiB) Viewed 4070 times

overview of the maze

thumbnail3.png (367.69 KiB) Viewed 4070 times

I think the cliffs look nice with the green water lower down acting as walls. Gives it a more natural look and the map still has enough contrast to see the paths.

[H8UL]

Looks very nice! Life has been busy but I will definitely check out your mod!

[mrvn]

I started a map with width 1000 and look where the "nearest" oil ended up:

wide-maze.png (17.14 KiB) Viewed 4029 times

Maybe the first oil patch should check both X and Y distance. Just being in the first few rows isn't helping as much as one might think.

[torne]

Many thanks for creating this mod - I've found the challenge of building a factory in a default-settings (1 chunk wide) ribbon maze really interesting, forcing me to rethink how to design everything. One part I've found especially tricky in a positive way is that any "module" of factory I design that takes up more than a couple of chunks is unlikely to fit into many different places in the maze, and so it's necessary to either break stuff down into very small parts that can be connected around corners, or to build a lot of unique parts - as an example my current 104spm research station is roughly F-shaped and so if I want to just blueprint it and slap down another one I have to find another part of the maze the same shape

I'll be posting pics once I get to the end

[H8UL]

I started a map with width 1000 and look where the "nearest" oil ended up:

wide-maze.png

Maybe the first oil patch should check both X and Y distance. Just being in the first few rows isn't helping as much as one might think.

A very low priority to be honest. The mod isn't balanced for very wide mazes in any regard. Resources increase as you go up -- exploring a large distance left or right is unrewarding because it's just more of the same.

It's called Ribbon Maze. It's inspired by ribbon world games. The maze is deliberately narrow both in terms of corridors and the map. That's the mod.

I find I must point that out a lot. I get the impression that a lot of people feel that is it better if a maze is effectively infinite in all directions. Seems cool but... For what gameplay purpose?

I can't see a gameplay benefit in a less directed exploration goal in a game that is still mostly about building factories. Enlighten me if I miss any mechanical benefit to enjoyment.

[H8UL]

Many thanks for creating this mod - I've found the challenge of building a factory in a default-settings (1 chunk wide) ribbon maze really interesting, forcing me to rethink how to design everything. One part I've found especially tricky in a positive way is that any "module" of factory I design that takes up more than a couple of chunks is unlikely to fit into many different places in the maze, and so it's necessary to either break stuff down into very small parts that can be connected around corners, or to build a lot of unique parts - as an example my current 104spm research station is roughly F-shaped and so if I want to just blueprint it and slap down another one I have to find another part of the maze the same shape

I'll be posting pics once I get to the end

Really glad your enjoying it! I wanted first and foremost for the mod to challenge the way we build -- it is a factory building game after all -- so it's fantastic to read you are embracing the default corridors. I just had an idea in fact, I should add an achievement for launching a rocket with a block size of 1 chunk. Maybe call it Narrow Minded

Maybe people can think of better names for it?

[jurgy]

Any ETA for 0.17 support? Love the mod btw <3

[H8UL]

0.17 experimental support now released!

[H8UL]

RibbonMaze 0.7.2 now supports Factorio 0.17.35.

The minimum version of RibbonMaze >=0.7.2 is now Factorio >= 0.17.35, due to breaking changes in the modding api in that version.

[mrudat]

I was pondering how to achieve a fully 2D infinite maze using the same basic algorithm, and it seems like there's a relatively straight forward (though tricky to implement) way to achieve that.

Instead of going row 1, row 2, row 3, the algorithm would be ring 1 (of one tile), ring 2 (of 8 tiles), ring 3 (of 16 tiles), ...:

Ring 0: the starting chunk.

Code: Select all

 1

Ring 1:

Code: Select all

 1 2 3
 8   4
 7 6 5

Ring 2:

Code: Select all

 1 2 3 4 5
16       6
15       7
14       8
13121110 9

There would need to be magic to account for the fact that Ring 1 [1-3] aligns with Ring 2 [2-4] (and 3-4:6-7, 5-7:10-12, 7-1:14-16), and that Ring 1 [1] is adjacent to Ring 1 [8], but I'm fairly certain the logic should otherwise be unchanged.

As far as I know, you still have a perfect maze (only one path continues deeper into the maze), but you now occupy all of the space available on the surface.

I might try my hand at it at some stage, if only for the programming challenge.

[mrudat]

On an on-topic note:

It looks like it should be possible to define a new kind of 'cliff' that has the same image in all orientations, and uses something other than cliff explosive to get rid of to implement the maze chasm with.

Cliffs can't be damaged with anything other than cliff explosives, though I don't know if a custom cliff will still be damaged by cliff explosives if a player throws them, rather than asking robots to destroy cliffs.

Edit: fix tyop, fix gramma

[H8UL]

I thought about doing a spiral, especially because I knew a lot of people would have a gut reaction to want the maze to be infinite in all directions, but you know sometimes players don't benefit for getting what they think they want

The reality is, it's far more satisfying to go deeper into a maze than go round in circles!

Edit: and if you intend to treat each ring as a row, then you have very serious problems, because it is topologically different in two fundamental respects: the ring wraps whereas a row does not, and each ring is larger than the last. So the efficient set logic of Eller's algorithm breaks down.

A lot of work just to dilute the concept of the maze progression by having it meander in all directions!

[mrvn]

The problem with building the maze in a ring is that people don't explore that way. Instead they go in one direction. And then you have to generate the full ring even though only one chunk on one side is needed. The further the player goes the larger the ring gets and generating it will take longer and longer and waste more and more memory.

You have to build something that only generated the labyrinth locally, where you need it.

[H8UL]

The problem with building the maze in a ring is that people don't explore that way. Instead they go in one direction. And then you have to generate the full ring even though only one chunk on one side is needed. The further the player goes the larger the ring gets and generating it will take longer and longer and waste more and more memory.

You have to build something that only generated the labyrinth locally, where you need it.

That's a very good point.

The great thing about Eller's algorithm is it stays at a constant computational cost for each row