Author Topic: [Request] Simple(?) Requests for WM 3.0  (Read 1514 times)

0 Members and 1 Guest are viewing this topic.

SaviorNT

  • Community Member
  • **
  • Posts: 6
    • View Profile
[Request] Simple(?) Requests for WM 3.0
« on: May 10, 2015, 03:41:27 PM »
Just some simple requests for the next release of WM (3.0).. I hope that they can be included due to my own selfish needs and desires.

Quasi-Random Number Generator

This should be the easiest to implement. The user can specify a seed value, a minimum value and a maximum value. If the user does not like the result, there should also be a "Generate" button in the properties window. The generated number should then be saved in the project file so that the output will be the same no matter when the user edits the world (to avoid irritating results across sessions).

Render multiple outputs

This would be so that developers and/or world builders can create and "let run" the results. I've attempted to build more than one "world" and it failed. Or more precisely, I stopped the rendering process after 4 days to build 3 "worlds". If this is not achievable, would it be possible to include a separate "Macro Renderer", which will allow the user to choose what projects they want rendered, it will then process each project in the array.

Filename outputs - auto generated

This would be highly useful, save a bit of time, and prevent my organizational OCD from flaring up. World machine, by default, should create a folder in the default document location named as the WM file name. For example, if my project is named L001, then WM will check "%Userprofile%\Documents\World Machine Documents\" to see if there is a folder labeled as L001. If not, then it will create it.

The program should also create a nested folder within the one it just created for the different output types. By default, it will create a Height Output folder and a Bitmap Output folder. This should be able to be changed in the output nodes however. So for example, let's take a Heightmap:

By default, the Height Output folder will be created, and it will be rendered into that folder. However, if I open the node to edit it's settings, above the filename box, will be another text input box with the default of "Height Output" pre-filled in. So let's say I change this to "Heightmap".. when this node is rendered, it will create a folder named "Heightmap"

For filenames, if your World was named as ExampleWorld01, then you could use: %F_HighAngle.png which would create a file named: ExampleWorld01_HighAngle.png

Save Project Settings

This kind of relates to rendering multiple builds, however, in the Project Settings, you are able to create multiple Extents. These should be shared between projects.

Logic Gates

This also relates to the quasi-random number generator. Logic gates should include:

If/Then
For/Next
And/Or
Math Functions (=, +, -, /,*, x^y, sqr, %)

Export World Parameters as a .txt file

It would also be helpful if we had the ability to read/write the world parameters and export a text file. This way I can create or modify world max height, do some math, and export a text file to state what the Z scale in UE4 shoud be :\

Standardized XML for Automation

This request, I feel, would be the hardest to implement, possibly. Please keep in mind that I have not experimented, therefore, have not discovered it, however, according to documentation, some of the tags that are not the beginning of sections end in "/".. this should not be the case.

Current way:

Code: [Select]
<enable group="A" />
Proposed way:

Code: [Select]
<EnableGroup>A</EnableGroup>
Something else about the automation xml, is that according to the example, the file tags are held outside of the sections. This shouldn't be the case!

Current way:

Code: [Select]
<!-- Load a TMD file into WM-->
<load file="example_script2.tmd"/>
<section name="HF Export">
...
</section>

Proposed way:

Code: [Select]
<!-- Open file and add stuff to it -->
<Section name="HF Export">
<LoadFile>example_script2.tmd</LoadFile>
...
</Section>

By making the XML format to this standard (which is also the standard as per W3.org), it will do two things for use:

- It will allow users to more easily ease into the automation of World Machine
- It will allow developers to create programs more easily to auto-build automation XML files; which is what I am trying to do btw ;)

As far as the self closing tags, as per the specification, “the empty-element tag SHOULD be used, and SHOULD only be used, for elements which are declared EMPTY”. For my previous example, <enable group="A" /> is not an empty tag. An empty tag would be: <enable group /> (but again, it should be: <EnableGroup />

I hope this will be the last edit :)