PTE Stream: 72908

Discussion in 'Support!' started by garat, September 26, 2014.

  1. Sorian

    Sorian Official PA

    Messages:
    998
    Likes Received:
    3,844
    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.
  2. squishypon3

    squishypon3 Post Master General

    Messages:
    7,971
    Likes Received:
    4,357
    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. :p
  3. wondible

    wondible Post Master General

    Messages:
    3,315
    Likes Received:
    2,089
    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 ;^)
  4. Sorian

    Sorian Official PA

    Messages:
    998
    Likes Received:
    3,844
    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.
    stuart98 and thelordofthenoobs like this.
  5. takfloyd

    takfloyd Active Member

    Messages:
    202
    Likes Received:
    165
    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.
    cwarner7264 and iacondios like this.
  6. xonal

    xonal New Member

    Messages:
    13
    Likes Received:
    13
    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!
    stuart98 likes this.
  7. cola_colin

    cola_colin Moderator Alumni

    Messages:
    12,074
    Likes Received:
    16,221
    yey
    yey
  8. Tripax

    Tripax Member

    Messages:
    67
    Likes Received:
    62
    Thanks, any insight on how it may work?
    Like spawn visualiation per number of players?

    I also see overlapping metal spots in current pte...
    Last edited: September 29, 2014
    totalannihilation likes this.
  9. draiwn

    draiwn New Member

    Messages:
    24
    Likes Received:
    8
    Anyone noticed that when you move the planet in system editor metal spots are generated again on different places?
    Is it the expected behaviour?
  10. Tripax

    Tripax Member

    Messages:
    67
    Likes Received:
    62
    We have the impression that everything including spawns are relative to planet positioning withing a system. Not sure until Uber can confirm that though
  11. cwarner7264

    cwarner7264 Moderator Alumni

    Messages:
    4,460
    Likes Received:
    5,390
    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.
  12. zgrssd

    zgrssd Active Member

    Messages:
    658
    Likes Received:
    185
    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.
    ace63 likes this.
  13. DeathByDenim

    DeathByDenim Post Master General

    Messages:
    4,328
    Likes Received:
    2,125
    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. :)
  14. ace63

    ace63 Post Master General

    Messages:
    1,067
    Likes Received:
    826
    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.
  15. zgrssd

    zgrssd Active Member

    Messages:
    658
    Likes Received:
    185
    Apparently this build is no longer valid.
    I got a steam update trying to start the PTE version. Game version now lists as 72996.
  16. garat

    garat Cat Herder Uber Alumni

    Messages:
    3,344
    Likes Received:
    5,376
    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.
  17. Zainny

    Zainny Active Member

    Messages:
    123
    Likes Received:
    146
    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.

Share This Page