how to save the devices?

I have just lost one hour erosion, separated in 4 devices, by just a simple click on one of these devices at the wrong location ( I hit one of the brown outputs.
The problem is, that if I have build a terrain and save it, it is opened, but all devices must be new build, because only the parameters, not the outputs of the devices are saved. I have tried after building, to give the devices the output, but that has the result, that all following devices are cleared.
I am working with great terrains, so this behavior cost a lot of time. What must I do, that WM saves also the outputs of every device, so that if i reopen the WM-file, I have not to erose again?

Johannes

Well, that is not quite possible (literally at least), but there are ways of going arround the problem… WorldMachine is like an engine that only works on petrol and doesn’t store any for future uses :P. Given the amount of memory that can be involved its easy to think of why something is flushed out as soon as it isn’t needed. So there is no built-in mechanism that will help anyone regain hours of build time.

However, there is the output device! <Monty Python’s evanly chorus music> 8). For how combersome it may be to use it for this purpose, it is the only suggestion I have. This will sound more complicated than it really is, trust me ;): Connect an output device to the output port of the device output you wish to back up (save to disk) and use a file format like .ter or .r32 that will enable you to maintain great deal of the detail. This of-course can be a bit tricky to use, because if you have several things to back up in this manner, you will have to take note of what file is for what. Then, for each version you make you need to overwrite the files and mustn’t forget that… To make matter worse, each time you wish to load the terrain, you need to connect the input device to the netweork. In the end fo this message I suggest a way to do this.

There is another trick I have to tell you about. WM has a small “feature” that causes the device to loose its build content depending on the way you disconnect its output ports. :arrow: Imagine the device’s output port is connected to another device. If you click on the output port, the device will be fine, If you click on the other device’s input port, the device will loose everything and need to be built again… It was a small oversight Stephen didn’t put much enfasis on. Really not important unless BIG times are involved :frowning:

Oh well, Here is my work arround for this:
:idea: Create and arrange the 4 devices, on the bottom of the picture:
(Splitter, Switch, File Input, File Output)

Use the .r32 file format, as WM can read and write to it, and you have the most amount of detail you can write to disk.
Each time you wish to load a terrain, just go inside the switch device and check the input choice checkbox.

If at the end of your work you think everything is in OK condition, you can unhook all these devices and do a nice overnight build :stuck_out_tongue: Just so you can say you didn’t load any terrain :wink:

Update: For convenience, you may wish (or not) to check the auto-refrsh on every build or save on every build checkboxes inside the input and output devices. Avoid using the incremental file name because you would need to change the input file manually each time you build :stuck_out_tongue:

Update 2: Unfortunately, due to a still lurking bug in version .99, I am unable to use more than one input device from different files at a time. So this can only be done once before WM v1.0 kicks in. :frowning:

Cheers,

thanks Fil.
Well, the workaraound is exact, how it is to solve. so I was not wrong.
I have just tested, whether more than input files are possible. I choose one tga and two ter files, no problem. May be, what you said because of the update2 is only, if you are using r32.

Johannes

I seem to be able to use more than 1 input (not tested for a little while though). I always have “Auto-refresh from file” checked though. Maybe that has something to do with it? All loaded files are also in the same dir, generally speaking. We should definitely verify whether this is a bug for 1.0 though.

  • Oshyan

Ok, It works yes. The bug I was mentioning doesn’t exist :stuck_out_tongue:
I was using a splitter to check the preview… And the Splitter only shows a preview if it has a device connected in its first output port. Since I had none, I was seeing no preview, thus assuming the file input wasn’t reading anything.

This Splitter issue has been noted down :!: