About the memory usage in the system editor: If you are not showing metal spots we do not create the physics or nav world. This is probably the reduced memory usage you are seeing because we are not generating the thousands of voxels nav uses. Landing zones: I was tasked with making it so you could see the metal spots in the system editor. That task was supposed to take a lot longer than it did. Since there is more time left in this sprint I am now tasked with getting the system editor to show landing zones. That work is largely done, so you can expect that in a future update. Metal density vs clusters: Metal clusters is the overall number of clusters of metal you will find on the planet. We are essentially splitting the planet up into grids. The higher the metal cluster value the higher the likelihood of any one grid containing at least 1 metal spot. Metal density controls how many metal spots can be found per cluster. The higher the metal density value the higher the likelihood of a cluster having the maximum value of metal spots. Cooldown on orbital entry: I don't think was mentioned anywhere, but the wait time for orbital units is moddable, and moddable on a per unit basis, if you so choose. Base_orbital.json has a value '"planetary_arrival_cooldown_time": 3.0,'. Adding that line to any other orbital unit will allow you to adjust the cooldown time for that unit. Guard radius: The intention of guard radius was always to be a simple statement of how far a unit is willing to move, without player interaction, to chase down and engage a nearby enemy. Unfortunately, this message got lost somewhere along the way (probably my fault). So, for all you modders out there that love messing with numbers, here is how we use the guard radius. When we are looking for nearby enemies to engage, a nearby enemy is deemed close enough to attack if it is within gaurd_radius + max_weapon_range of our leash position (the position the unit was in when it stopped receiving orders from the player). For fabbers looking for nearby things to repair the calculation is guard_radius + build_arm_range. This ensures that if the guard radius is 30 meters the unit will not wander more than 30 meters away from its leash position. This also ensures that when looking for a target of opportunity the unit is taking its weapon/build arm range into account without having to adjust the guard radius manually every time you adjust a weapon/build arm range.
But didn't the system editor show metal spots in Alpha? I thought it was removed because it was used to cheat or something silly like that. I could have sworn it used to be in, haha.
Neat. Modded a combat fab to 500 and got an inferno damaged. If it's on patrol, the CF will walk over and fix it. Of course, so will all of them if more than one is patrolling ;^)
It was removed so we could better control the metal spot distribution, including attempting to ensure that all starting locations had a minimum amount of metal spots nearby.
The cooldown on orbital units will certainly help address a few exploits, but I'm thinking... wouldn't it make more sense to have a charge time before departure? What with the ships firing up their engines and setting the course and so on. This seems like it would make more sense from a gameplay standpoint, since the current cooldown will probably make heavily guarded planets even harder to breach without superweapons. Meanwhile, SXX sniping could be nerfed by having a charge time before the first shot. Just my five cents.
Not to get too far ahead. But could that possibly pave the way for assigning landing zones as 'slots' & being able to move them? So that making team starts could become a thing!
Thanks, any insight on how it may work? Like spawn visualiation per number of players? I also see overlapping metal spots in current pte...
Anyone noticed that when you move the planet in system editor metal spots are generated again on different places? Is it the expected behaviour?
We have the impression that everything including spawns are relative to planet positioning withing a system. Not sure until Uber can confirm that though
This seems like a more elegant solution, IMO. And could be more easily visualised in-game (let's see and hear some fancy additional thrusters fire up slowly while preparing for a transfer). I love me some WYSIWYG.
I can confirm that I noticed at least one pair of metal spots "too close" to build a T1 MEX on both of them. I forgot to save the Lobby ID, however. Another issue (kinda): It appears as if Nanolathing color is now Team Colored by default, even without any mods. At least it was mentioned on Steam (http://steamcommunity.com/app/233250/discussions/0/616189106662693061/) and I can verfiy it for the PTE build. As this was afaik nowehre mentioned I asume this is a bug/omission.
This is intended behaviour. It's also in the latest stable release. There's even a mod to revert back to the plain green nanolathe out there.
It should be green by default - it is a lot harder to judge how far a building has finished from the look of the animation alone. Also nostalgia, please don't kill this inheritance from TA.
Apparently this build is no longer valid. I got a steam update trying to start the PTE version. Game version now lists as 72996.
Yes.. 72996 is identical to prior build, except we no longer limit coherent processes by default. You can still override if you're having memory problems and need to reduce it.
I still don't understand why you can't just set the number of processes based on the available system memory. It feels to me like you're jumping between two extremes (too many/too few processes) when there is a reasonable middle ground. Seriously, a couple of new if statements in the code and you're done.
