[0.7.4] Nuterra v0.4.2 - WorldEditor

[maritaria]

Only compatible with stable branch release 0.7.4
Download
Source Code
TerraTech Discord (#modding)

Nuterra modding team
Maritaria (code, models)
Sylver (code, graphics)
Gameslinx (code)
Mottflyer(models)

Features
To prevent the post from growing to an incomprehensible mess, we have moved descriptions and instructions on each mod to their own wiki page:
- Custom Cursor Mod
- Maritaria Mod
- Sylver Mod

Wiki & Install Instructions
We now use the build-in wiki on github. Here you can find info and instructions on each of the mods included in Nuterra.

WorldEditor
This release adds the new WorldEditor mod! With this mod you can add/remove scenery from creative/R&D saves. Controls:

L - Toggle editor
Leftclick - Place item
Rightclick - Rotate camera (drag)
WASD - Fly around
Q - Previous item
E - Next item
Z - Remove hovered item

Let us know if you run into trouble, need help or have ideas.
Have fun

 

[CringeM8]

Yet another excuse for me to learn c#... Modding TT.

 

[Gameslinx]

I love that video

 

[maritaria]

Yet another excuse for me to learn c#... Modding TT.

Fair warning; you need some knowledge about C# and IL to be able to mod unity games, since you don't have a debugger and may need to adjust IL manually.

That said, please do have a go at making something
Some encouragement: try to create a keybinding for giving yourself money. Hint: extend MagnetToggleKeyBehaviour.Update to have a second if statement.
If you pull request a working version I will accept it.

 

[Canute]

Hi,
i got the problem that with that dll the tooltip of object don't appear anymore. When i replace it with the original they appear like before.

Does the anchored solar panels just produced 20% too ? i think so.

And i think 20% is very low, since they only work when you don't move . I would suggest 50%.
10-20% would be fine if they are worked during movement too.

Maybe add a multiplier at the prefs file for this value.

 

[maritaria]

-snip-

Thank you for reporting that, I'll look into it soon

- happy new year :3 -

Also, could you maybe be a bit more specific where the tooltips are missing? I assume it's in the buy menu or something, but more info on where they miss and how you noticed will help me a great deal on figuring this one out thanks in advance either way.

 

[Pink Kitty]

Well, this is impressive.

I especially like the magnet toggle.

Now, if we could get separate key bindings for fans/props and thrusters, then you'd have an 11.

 

[maritaria]

-snip-

Great suggestion, put it on the list for the next version.

 

[Gameslinx]

We need a keybinding to be able to hover in the air, and that the fans on techs adjust accordingly to hover (for AIs). This would fail when the tech goes outside of 'chunk/tile' range, so maybe when the tech becomes to far away it becomes an anchor (temporarily)

 

[maritaria]

-keybinding for hovering-

I think this will be quite a major change for me to make, editting AI and that sort of stuff.
Doesn't the :venture: gyroscope do something similar already?

 

[Zed]

Is there any chance the texture resolution of resources / blocks could be reduced by modding? It would most likely Significantly increase performance for late-stage campaign saves. Please refer to the exchange between replies #142 and #147 here in the "suggestions in a sentence" thread where it seems such a modification could be construed as a "Major" Optimization yet from my perspective should be considered a Quality of Life Improvement for Crafters such as myself.

Thank you in advance for looking into this topic.

 

[Gameslinx]

I think this will be quite a major change for me to make, editting AI and that sort of stuff.
Doesn't the :venture: gyroscope do something similar already?

The venture gyro just attempts to keep the plane/drone horizontal / more stable in the air. I think maybe leaving a hover keybinding to the devs is easier, as I think they confirmed it for later

 

[tomo_cjt]

Is there any chance the texture resolution of resources / blocks could be reduced by modding?

Hey Zed, I saw you post this in the other thread, and changing the size of the texture would only reduce the memory overhead - the resources all use the same texture (and it's not too big at that).
So this wouldn't really do what you want from it.

 

[maritaria]

-all blocks share texture-

Oh, so that's why you switch out the texture on damage the way you do. Was wondering why my custom block wasn't glowing red when damaged.

 

[Zed]

Hey Zed, I saw you post this in the other thread, and changing the size of the texture would only reduce the memory overhead - the resources all use the same texture (and it's not too big at that).
So this wouldn't really do what you want from it.

Thank you for that Clarification @tomo_cjt ; my reasoning behind the suggestion was (and somewhat persists) from the following conceptualization based not only on my own IT experience but also gameplay experience in other sandbox environments:

The resource chunks and tech blocks both contribute to lag when visible through the game interface but less so when they are anchored / attached to an "Entity_Tech" as opposed to when they are "freeroaming" within the game environment most likely existing as an additional Entity_Entry line item which still leads me to believe that the resolution of their individual textures have, when persistently visible within the game interface, a more than insignificant load upon the cpu as it is required to constantly apply forces such as friction / gravity / buoyancy / lighting / shading / shadowing against the product total of the entirety of the resolution of each unanchored block / chunk (the 3d "mesh" of the block) from the perspective of what amounts to an almost-infinitely variable camera perspective (the game window) which undoubtedly leads to a significant amount of frame cropping as the number of cpu calculations required becomes a geometric progression with each untethered block visible within the game interface. An order of magnitude reduction in the generic texture resolution (i.e. 2^8 = 128 becoming 2^4 = 16 as an easy example along each of the x,y,z axises effectively 'cubing' the expressed example products {(16^3) vs (128^3)}) would effectively cut down the number of calculations required by ~75% conservatively. I completely agree with your assessment that any decrease in texture resolution would also slightly reduce the amount of Random Access Memory requested by the game process in order to retain the individually-rendered textures within cache. I for one would wholly welcome an additional slider bar (preferably three; one for blocks another for resource chunks and a third for terrain items such as trees / rock outcroppings) within the options menu to permit the end-user greater control over performance optimizing measures within the game interface which, based on your statement that the elements share the same texture resolution should be relatively easy to encode the value as a variable pinned to a slider within the graphics options sub-menu.

If for whatever reason Unity prevents the logic stated above to realistically occur perhaps another way to resolve the underlying quality of life issue of storing resources on site would be to create a GeoCorp-Equivalent of the SCU which would only store raw resource blocks to wholly remove them from being needlessly rendered in real-time while "idle." This type of additional content / functionality has been undoubtedly requested in the past and would in all probability resolve the bulk of the quality of life issue that is overall frame-rate late-game for all players to varying degrees based on hardware capabilities / style of gameplay.

 

[Exund]

a GeoCorp-Equivalent of the SCU which would only store raw resource blocks

I love that idea!
Maybe Something we could do with mods...

 

[tomo_cjt]

Thank you for that Clarification @tomo_cjt ; my reasoning behind the suggestion was (and somewhat persists) from the following conceptualization based not only on my own IT experience but also gameplay experience in other sandbox environments:

<Snip>

Gah, I'm not intending to sound mean here, but most of your post is incorrect and that's not how most engines work.

You're combing rendering which is mostly a GPU based process with Entity management which is CPU and RAM based.
Reducing the textures doesn't really do at all what you say since the shader on the GPU knows which bit of memory to use and the textures are already loaded.

I'm massively simplifying things here, but I just want to stop that line of thought in it's tracks.

Now physics on the other hand is a CPU based process, so not doing all the work on individual resources when held is something for us to look at.

Basically, you're conflating two separate things - the need for something to be shown on screen with the need for something to updated / have forces act upon it.

Hope that helps,
Chris

 

[tomo_cjt]

Oh, so that's why you switch out the texture on damage the way you do. Was wondering why my custom block wasn't glowing red when damaged.

All resources are one texture, each corp is one texture per corp.

All chunks live in 1 texture, GSO on the GSO texture, GEO on theirs etc.

The reason we switch them out is so that we can batch (have the GPU render all objects that have the same material in one go - I can elaborate on this some other time if people are interested...) All the undamaged GSO blocks together on the GPU.

Now damaged blocks need to flash and they need unique values set on their material so they don't flash in unison, so when a block is damaged we need to swap the material to another temporary one and then back.

This causes a small performance dip, but it's tiny (really) and massively offset by the savings we have by using shared materials elsewhere.

At some point I'm going to combine the corp textures into 1 and atlas them so the different corps batch together.

Again, hope this was helpful / informative.
Chris

 

[Zed]

You're combing rendering which is mostly a GPU based process with Entity management which is CPU and RAM based.
Reducing the textures doesn't really do at all what you say since the shader on the GPU knows which bit of memory to use and the textures are already loaded.

I'm massively simplifying things here, but I just want to stop that line of thought in it's tracks.

While Normally true; the Unity architecture seems to inherently disagree with the assertions above within their own Unity Profiler Window screenshots referenced below:

https://docs.unity3d.com/Manual/ProfilerCPU.html
https://docs.unity3d.com/Manual/ProfilerGPU.html

This assessment is also further supported by the Terratech Requirements listed within steam which directly state that the executable has a dx9 dependency and not dx11 which would provide the ability of GPU-based skinning per Unity documentation. That, In conjunction with the stated minimum graphics requirement of a paltry 520m geforce with its uninspiring thimble-worth of fill rate / memory bandwidth capabilities.

Basically, you're conflating two separate things - the need for something to be shown on screen with the need for something to updated / have forces act upon it.

While I did indeed combine many functions into the following sentence below the supporting statements attempt to make it clear that different aspects are handled differently and at different stages:

a more than insignificant load upon the cpu as it is required to constantly apply forces such as friction / gravity / buoyancy / lighting / shading / shadowing against the product total of the entirety of the resolution of each unanchored block / chunk (the 3d "mesh" of the block) from the perspective of what amounts to an almost-infinitely variable camera perspective (the game window)

It is abundantly clear from both my own in-game experiences (the simplest test is to merely compare framerates by panning the camera on a gaming laptop when operating on battery power vs plugged in while the GPU forces itself to max performance irrespective of power state to witness the impact of cpu throttling to witness just how dependent the framerate is on raw GHZ. Additionally, viewing many Youtube lets plays of Terratech where this slowdown is prevalent that once the user is beyond the draw distance (more or less) that framerates rapidly recover which is indicative of cpu load especially within a unity-augmented environment.

so not doing all the work on individual resources when held is something for us to look at.

Echoing your sentiment, I bear no personal malice with this post nor the previous post; the only conclusive point I wish to make before dropping this topic for the time being is that there would be no harm in trying.

Thank you @tomo_cjt for all of your continuing efforts to improve the community's Terratech Experience.

 

[Dellamorte]

Holly sentence structure Batman,

"The resource chunks and tech blocks both contribute to lag when visible through the game interface but less so when they are anchored / attached to an "Entity_Tech" as opposed to when they are "freeroaming" within the game environment most likely existing as an additional Entity_Entry line item which still leads me to believe that the resolution of their individual textures have, when persistently visible within the game interface, a more than insignificant load upon the cpu as it is required to constantly apply forces such as friction / gravity / buoyancy / lighting / shading / shadowing against the product total of the entirety of the resolution of each unanchored block / chunk (the 3d "mesh" of the block) from the perspective of what amounts to an almost-infinitely variable camera perspective (the game window) which undoubtedly leads to a significant amount of frame cropping as the number of cpu calculations required becomes a geometric progression with each untethered block visible within the game interface. An order of magnitude reduction in the generic texture resolution (i.e. 2^8 = 128 becoming 2^4 = 16 as an easy example along each of the x,y,z axises effectively 'cubing' the expressed example products {(16^3) vs (128^3)}) would effectively cut down the number of calculations required by ~75% conservatively. "

,that could do with some full stops in there. I know I am hardly the one to be able to point fingers but that is a little on the silly side. A little time on formatting would be nice.

While I am no expert but from the explanation you have gotten from the head coder I tend to get the impression that he has a much deeper understanding of the pros and cons of the Unity game engine. I don't want to be hard on you but you do seem to a complete understanding of the issues involved in programing a 3D physics based game.

I do like the fact that you are putting the thought into it and are asking the questions as this can only server to help you (and the rest of us) gain that understanding.