Terrain Generation Overhaul Guidebook

Alphado-Jaki · Feb 28, 2018

Terrain Generation Overhaul Guidebook

Ver. 0.2.0

Second pre-release edition

Changelog (Ver. 0.2.0):

Fixed Checkerboard and Cylinder frequency from 500 to 512.

Added manuals for almost all of module.

(excepting non-fast modules, Spheres, Voronoi, RotateInput, DisplaceInput)

Read on web

Download PDF

I write this book to summarize existing knowledge distribute in this forum.

The main purpose of this book is to encourage new modder on terrain generation, and to make good atmosphere to discuss new idea each other.

This book is hosted on GitHub, so anyone who has GitHub account can make change request via PullReq.

However, I'm happy to receive comment or request in this forum.

For this first release, I attached the whole template for existing modules.

I haven't finished writing the guide for each module, but those who wanna test can play with it.

I'm making an unofficial DLL fix patch featuring terrain and hub generation, so next release may come 1-2 month later.

-> Done

xyth · Feb 28, 2018

Very nice. Thanks for doing this!

Tin · Feb 28, 2018

Nice work so far! :encouragement:

n2n1 · Feb 28, 2018

Thanks !

I'm looking for a way to increase the percentage of the "downtown zone", and change the width of the streets inside the hub. (it's hardcoded) does anyone know that now?

Alphado-Jaki · Mar 1, 2018

I'm looking for a way to increase the percentage of the "downtown zone", and change the width of the streets inside the hub. (it's hardcoded) does anyone know that now?

Sadly, haven't tested about that.

But as seeing related classes, HGSocket.TW may have effect to "downtown zone".

For width of the street, the constructer of PathSocketStreet seems to have effect.

Not sure, though. :I

Tin · Mar 1, 2018

Thanks !

I'm looking for a way to increase the percentage of the "downtown zone", and change the width of the streets inside the hub. (it's hardcoded) does anyone know that now?

Yep, it's hard coded and you cant change either at this time but I sure hope we can get control over the zoning sizes and street width at some point.

Or I should say none that I know of..

Alphado-Jaki · Mar 1, 2018

Okay, I confirmed this works correctly for pathradius.

I'll post instruction later (maybe the same time tomorrow?), but in short.....:

Open RWG2.PathGenerator.PathSocketStreet.ctor (2nd one)

Replace 10.5f into _pathRadius

Tin · Mar 1, 2018

Okay, I confirmed this works correctly for pathradius.

I'll post instruction later (maybe the same time tomorrow?), but in short.....:

Open RWG2.PathGenerator.PathSocketStreet.ctor (2nd one)

Replace 10.5f into _pathRadius

So you need to go in the nuts n bolts.. meh, not going to mess with that, just not worth it atm for me

Once TFP actually decide on everything that's when I'm going to do a thorough in depth twixery of everything.

Alphado-Jaki · Mar 1, 2018

So you need to go in the nuts n bolts.. meh, not going to mess with that, just not worth it atm for me Once TFP actually decide on everything that's when I'm going to do a thorough in depth twixery of everything.

Yep. :/

This is too much effort to get the single feature working for most of modders.

And EAC need disabled is bad aspect also.

Tin · Mar 1, 2018

Yep. :/This is too much effort to get the single feature working for most of modders.

And EAC need disabled is bad aspect also.

Good practice anyhow to get familiar with how they're doing things so not a total loss

n2n1 · Mar 1, 2018

Open RWG2.PathGenerator.PathSocketStreet.ctor (2nd one)

Replace 10.5f into _pathRadius

Ahhh....10.5!?....i was looking for the wrong number! (for some incomprehensible reason- i believed it to be an integer...)

Thank You very much!

Alphado-Jaki · Mar 2, 2018

Ahhh....10.5!?....i was looking for the wrong number! (for some incomprehensible reason- i believed it to be an integer...)
Thank You very much!

That confused me also.

I'm not sure why but 2 times of path_radius seems to be used.

StompyNZ · Mar 3, 2018

So you need to go in the nuts n bolts.. meh, not going to mess with that, just not worth it atm for me Once TFP actually decide on everything that's when I'm going to do a thorough in depth twixery of everything.

once sdx is ready for a17 im happy to do some patch scripts to make some unique requirements work for rwg

Not enough time to do any thing significant atm before a17 with my other projects on the go though

StompyNZ · Mar 3, 2018

That confused me also. I'm not sure why but 2 times of path_radius seems to be used.

path radius in the xml adds to the center 1 block, so total width 21, half that for 10.5

Alphado-Jaki · Mar 3, 2018

path radius in the xml adds to the center 1 block, so total width 21, half that for 10.5

Ah, that makes sense!

So, correct way to fix is "replace 10.5f with _pathRadius + 0.5f".

n2n1 · Mar 3, 2018

path radius in the xml adds to the center 1 block, so total width 21, half that for 10.5

Lol

Thanks Cap !

Alphado-Jaki · Apr 11, 2018

Updated for Ver. 0.2.0

Almost all of manual for module is done. (Appendix 2-4)

n2n1 · Apr 11, 2018

I still can't understand what the "seed_additive"...

Will give the same result in: seed_additive="0" and no_seed="true" ?

upd:

that is, seed_additive - additional influences that have affected seedname?

then why these parameters ? (digit)

upd2:

previously, i assumed that the parameters indicate how much influence seedname has on the result.

ie 0 - disabled seedname influence on the result, 1 - little influence, 2 - more impact seedname on the result and so on...

Is that not right?

Alphado-Jaki · Apr 11, 2018

seed_additive is added to seedname.

For example, using "1111" as seedname and setting seed_additive="1" for a module, result that it actually use "1112" as seedname.

(Actual process encode "1111" via UNICODE or ASCII, so may not true. This example is just to understand.)

no_seed forces a module to output always same result, whatever the seedname is.

Alphado-Jaki · Apr 12, 2018

I've made a simple example. Following pics are from RGW previewer with NOT same seedname. But using seed_additive, we can cancel the gap of 2 seedname.

Case 1: Seedname=1 seed_additive=1

Code:

		&lt;terrain_generator name="vanilla" use_old_final="false"&gt;
		&lt;module name="ridge" type="FastRidgedMultifractal" [color="#000080"]seed_additive="1"[/color]&gt;
			&lt;property name="octaveCount" value="20"/&gt;
		&lt;/module&gt;

		&lt;module name="scaleBiasOutput" type="ScaleBiasOutput"&gt;
			&lt;property name="sourceModule" value="ridge"/&gt;
			&lt;property name="scale" value="-90"/&gt;
			&lt;property name="bias" value="90"/&gt;
		&lt;/module&gt;

		&lt;output module="scaleBiasOutput"/&gt;
	&lt;/terrain_generator&gt;

Case 2: Seedname=2 seed_additive=0

Code:

		&lt;terrain_generator name="vanilla" use_old_final="false"&gt;
		&lt;module name="ridge" type="FastRidgedMultifractal" [color="#000080"]seed_additive="0"[/color]&gt;
			&lt;property name="octaveCount" value="20"/&gt;
		&lt;/module&gt;

		&lt;module name="scaleBiasOutput" type="ScaleBiasOutput"&gt;
			&lt;property name="sourceModule" value="ridge"/&gt;
			&lt;property name="scale" value="-90"/&gt;
			&lt;property name="bias" value="90"/&gt;
		&lt;/module&gt;

		&lt;output module="scaleBiasOutput"/&gt;
	&lt;/terrain_generator&gt;

This example shows that the world seedname + seed_additive of each module is used for a seed of the module.

As we know, changingthe world seed, even if 1 char, results completely different world. The seed_additive for a module is same. If we change seed_additive, even if only +1, completely different module is generated.

Terrain Generation Overhaul Guidebook

New member

Community Moderator

New member

Well-known member

New member

New member

New member

New member

New member

New member

Well-known member

New member

New member

New member

New member

Well-known member

New member

Well-known member

New member

New member