PTE build 85104-pte is now live!

yes.

Yes.

YESSS

Of course. I didn't do any performance testing on it, however. It's a pretty heavy-weight function, and it has to be evaluated per-location. So while it can, you may not want to do very many.

Well a few hundreds to thousands once at the start of the game. Seeing how area build planet wide with storages show no issues to update all previews in realtime I would hope that will work out.
Even if not it'll definitely be a few orders of magnitude better than my current solution which locks up the client in a dedicated mapping mode for 20 minutes per planet in case of big planets, I think it is around 15 locations per second using the main view atm. I am sure the new API will be able to do more

So great stuff. Can't wait to get my hands on it.

You sneaky devils, you made the sun prettier and thought we wouldn't notice

will there be anything new regarding better random planetgeneration?

One little thing about the raycast API: It does not say what planet was hit. Now there is that info on what planet is focused, but that info isn't really very good. It suffers from the fact that the player can have multiple views that focus different planets. The UI just is informed "a new planet is focused" every time the focus changes in any holodeck and trying to track correctly which holodeck has what planet focused is kinda a pain. Just having the planet id in the raycast info would be great.

Another thing about the cilantro errors: Killing the coherent process in the taskmanager by hand triggers it. I do that when I see a coherent process that eats 35% CPU for no reason and I want to know which scene it was. Well the log does tell me, but if (I have no idea if you can) you can detect that the user just killed the process you might just not want to send an error report:

Code:

[15:29:45.604] ERROR [ViewError/game_paused_panel] AbnormalTermination: View was terminated in an abnormal fashion.

Now that scene creates 35% CPU load on its coherent process it seems after I load a match on styx for me even when I have no mods enabled at all.

Hmmmmmm. Triggering Pause/Unpause seems to fix it.

Btw I also would like a "continue playing" button on the cilantro dialog. Like in the past I did actually finish some games with a crashed UI part that just didn't matter, some static unimportant scene basically.

EDIT:
I found the heavy CPU waste bug with the pause dialog.
To fix it do this in the pause dialog:

Code:

<div class="background_glow"></div>
add visible binding =>
<div data-bind="visible: paused" class="background_glow"></div>

I do not understand why it does it, but it seems if you have the glow in there then it will eat a TON of cpu for *something* until the glow is first made visible. Probably a weird bug caused by the fact that by default it seems the whole pause dialog html is always visible inside the pause scene. It however is hidden to the player because the pause scene itself is not visible in the main live_game scene. It seems that freaks out coherent somehow with the animation until the animation is made at least once visible it will eat cpu.

EDIT 2:
I am also seeing other weird CPU usage issues for the chat mod. It would be helpful if the coherent processes had some startup parameter that tells which process is which scene when looking at the taskmanager.

Yeah, I noticed the pause thing and fixed it already. (I noticed a UI slowdown after going into the configuration screen, which pauses in single player.) Also, I noticed that the stats API was rendering the graph when not visible as well. Both fixes will be in the next patch.

Adding the planet index to the raycast results would increase the communication overhead due to adding it to every bit result. I will have to change the schema to make that happen. (That might make it into the next build. I will see what I can do.)

I guess an alternative would be another call "tell me which planet is focused on this holodeck right now".
People can't click other planets without changing the focus anyway.

If there will be an Uber-employee-of-the-month title someday, I would definitely vote for you.

Random thought about asteroids: The asteroid belt looks cool.
Why not always add it as a graphical gimmick? Doesn't need to spawn asteroids all the time, but it always looks cool.

I figured out I need to isolate the schema change to the JS side of the API anyway. So it should look the same from your side.

In the process, I also added a focused planet call, since this change made that possible.

I totally agree! It should always be there. Looks way cooler

Yeah why not just both

You're awesome indeed.

I agree that it is a really nice reference point. I was concerned about the WYSIWYG aspect of astroid belt = astroids coming, though that should be evident from the game lobby (as long as the player remembers)

The UI ingame knows how many asteroids the system will have it could display some sort of warning "there will be 2 asteroids soon..." in the planets overview.

I was thinking about this too and yeah you can see that in the lobby was my thought of how to know if there are going to be asteroids or not. You know what. Maybe even a Timer for when an asteroid is going to spawn would be good (along with the warning)!

That reminds me. Another timer for knowing when the smash is about to happen would come in handy too! That way you know how much time you have to actually counter the smash. same goes for the lazer

I think WYSIWYG trumps better graffixez here.

@pinbender
Can you add a list of all stances to the documentation? I am trying to change the energy stance of units, from what I understand that means "pause/unpause", but I can't get it to work. It tells me "invalid energy_stance":
My command looks like this, I also tried some other stances, like conserve, CONSERVE, off, OFF:

Code:

{   "units": [     1401,     1417,     1425   ],
"location": {     "entity": 1401   },
"command": "energy_stance",
"stance": "Conserve" }

Also I need to specify a location otherwise I get the planet invalid error, kinda weird for that kind of command.

EDIT:
Wait a second maybe I am stupid. I think what it wants to tell me is: That pgens does not have that energy stance. I guess I should not try to pause pgens...

Still a list of all stances would good, though it seems my "randomly search for strings within PA.exe" did work after all.

EDIT 2:
Hmm or maybe it really isn't work.
I am not really sure anymore. Knowing the right stances would help.

EDIT 3:
Okay I have the right stances now, but I get the "true" message and nothing happens.
Maybe the same bug as the build placement that isn't working yet?
I can't get the other stance commands to work as well. The example fire_at_will as a weapon stance yields me an "invalid weapon stance". The stance "roam" as movement_stance is accepted but does not change anyting, returning true.

The action bar sends "fire at will" (with spaces) to the selection, though roam looks correct.

Correct, this is the same bug that the build placement has in the current build. I've verified that it works in my local build. (Although the action bar UI does not update if the units are selected, because it assumes that it is authoritative.)

I'm including the stance list (which you already figured out...) in the docs, removing the requirement for a location field on those commands, and fixing the misspelling of "maneuver".