No apologies for the double post, but I feel that I have cracked the problem at the eleventh hour (or the twelfth, it's 12am here).
I woke up today with a feeling like I shouldn't have been rooting around in script.cpp after all, so I rolled back those changes, and focused on making the world terrains resemble level terrains.
I had a patch where it wasn't compiling beyond database.cpp, but I figured out to add "wterra.h" to "dataset.cpp" and I was away and racing. Suddenly it was a clear path to compiling, but then opening the application and starting a new game resulted in a crash. I blocked out changes to wterras.cpp and wterras.h and I was able to load the world map! But then entering a dungeon suddenly caused a crash! Loaded up again and tried to see what I could do using the command system while in the world map... not much it turns out... until I tried to save the game. Another seg fault! But a healthy clue. Two problems, one of not being able to save, and the earlier problem of the game picking up the BitmapPos of the owterrain, but seemingly unwilling to place it on the worldmap without crashing...
Hours of searching and messing around, until something subtle catches my eye: Every level terrain has a function which initializes some of the data. I decided to chuck it into wterra.cpp, just for the gwterrains and owterrains, and for completeness. What do you know? To my complete surprise it stops crashing when I save, enter a new area, leave it again, and load. What's more, the BitmapPos is being picked up from either owterra.dat or gwterra.dat!
Happy day.

So, reasons this is getting us where we want to go:
Contributers will want to create their own dungeons. Unfortunately, a world map location is not always where the start point of a dungeon is located. Think of the underwater tunnel exit.
Contributers will want to create their own graphics for their new world map locations; and so on. Therefore we need to represent the owterrains in data files. Plus I want to add climate data to each gwterrain, and I feel the best way to test it out would be using a data file, where I don't have to compile each time.

I remember the tower idea! I like the risk posed by having trapdoors you can fall through.

I've been scratching around in the script engine and the database today, the goal being to move the gwterrains and owterrains into script files. Not much luck after having created a rat's nest of code. I pulled it all out again by stashing it. I really wish the devs had implemented a lua script engine or some such, instead of the bespoke "traction engine" we have serving us today...

So Z has weighed in! I like hearing more from Z, and an interview about HyperRogue is exciting.

I'm becoming daily more interested in taking part. I can talk about development from the perspective of someone who hasn't been there from the very beginning, learnings from building a fork, how the community responded, and then how this shaped my present-day thinking.


Ighalli, what better way to voice your opinion of the show than... on the show itself?

The latest effort is a step towards this, but creating a dungeon from script alone has not been implemented yet, but this is the next step. So yeah, not phase 2 just yet, but we will get there shortly.



Creating you own dungeon is time well spent, and counts as development. Azba, if you feel like starting on an idea for a dungeon, then please do so. If you need features added into the code to give the dungeon that x-factor, then by all means deliver me your specifications.

I'm excited about writing some practical dungeon building tutorials on the wiki, and perhaps explaining some of the features like randomization and the difficulty curves. Maybe even some calculator tools on the wiki?

I am going to follow SquashMonster's suggestion of creating alternate dungeons arcs which you can opt into by choice. Using the encrypted scroll can be the key to enabling this.
Think of Attnam and Gloomy Caves as parent and child locations respectively. In Attnam, you hand over the encrypted scroll, and this lets you find Gloomy Caves on the map, and the scroll disappears. Consider a new set of parent and child locations, let's call them the City of Rihajab and Crimson Ziggurat. You hand over the the encrypted scroll to the municipal authorities in Rihajab, who thank you for contributing to their military intelligence, and who reveal the location of Crimson Ziggurat, which they say you can have for your dominion, if you can defeat the ultimate evil residing there... and so forth.
I'm not a good writer, anyone who played CLIVAN can attest to that. But I just want to illustrate the possibility of using the encrypted scroll to lock out the other dungeon locations in a structural way, until a more general way of doing this can be implemented.

That's the original devs' worldmap (:

Digging the (underwater) tunnel from both ends, I decided I would spend some time picking over some of the outstanding previous work of one Ketmar, a.k.a. vasiliy (from this forum).
I hoisted in a bunch of code from his repository by hand and compiled it. It worked, so I have advanced a pull request to include the changes.
He was able to split the dungeon files, and a whole lot more besides. I only thought to split the dungeon.dat files at this stage as it is the only part that is relevant to the world map.
I hope there are no serious errors as a result

From here, I propose to cause IVAN to place generic, mostly empty worldmap locations - 64 in total - as placeholders whereby someone can come along with no compiler, and create a new dungeon using only the script files. The new dungeon would simply fill in an available empty location slot.

EDIT: The locations would only populate the map once they are non-empty

Hi all! Further to some of the work above, I've been doing some more investigating lately, muddling around with Python. To satisfy my cravings for more visual feedback, I decided to make use of some rather more powerful plotting features available in Python, and create 3d maps and contour projections below.
The code to generate the plots is a little bit clunky, but it seems to do the job. It can save the output to png format in a subfolder.

I attached an animated gif showing how IVAN smooths the initial random field, producing smooth features of varying elevation that resemble geographical features; mountains, seas, sometimes lakes (valpuri.gif).
I caused the plots to render the land and sea green and blue to distinguish between the two (see other attached png images).

The (ugly looking) code is in a specialized repository on GitHub.

Maybe the dev wiki could be hosted on the GitHub page, and the two wikis can link to each other. It'd be cooler if there was one integrated wiki somehow.

I noticed that the GitHub repository has the possibility of adding a wiki page. I wonder if we could make the wiki page on GitHub simply redirect to the Attnam.com wiki page?

Never mind what Andrew Doull said about python, it's a great language for doing anything with, and especially great for something like a roguelike. I feel sad that you were put off, I hate when that happens.

I remember Z once did an interview for Roguelike Radio in episode 82. Maybe he can give us an impression of his experience with it?