PTE build 85104-pte is now live!

Not so much true. The overhead for making the call itself is so low, you should be able to make about 5-15 million calls per second. Converting respectively extracting the parameters from JS runtime to the native API is actually the expensive part. Also inserting the puppets into all of the index data structures, just to have them removed again right away...

Since your goal is to get the heightmap, you should eventually just ask to get a dump of the world geometry. Iterating once over the vertex list is O(N) and should allow you to build the minimap in a few micro seconds as opposed to ...
I don't even want to know what complexity your current approach actually has ...

hair splitting I'd guess my current approach at max quality using the puppets has whatever complexity inserting and deleting a puppet as times the number of pixels I have.
A faster version I have now that generates a little lower quality images:



Runs within 2 seconds to generate that image. The raytrace calls are super fast really, the annoying part of the raytrace API is that it works from screen coordinates. So to generate this I make a temporary small extra view and move the camera around in that to raytrace.
Still tweaking to find the optimal configuration of holodeck size, camera locations, etc

Really this is light speed already, I am used to using 10 minutes to generate an image that was much much much less detailed. xD

EDIT:
If I could dream up an API call for this I would btw not want the full planet geometry.
Figuring out the heightmap from that is something that native code can do better than I can, because the native code probably already has all sorts of acceleration structures to query these things while I would need to build them first.
Instead I'd like:
1. parameter: an array of word coordinates
2. parameter: a number indicating a radius

Returns an array of objects. Each object has the world coordinate snapped to the actual planet height at the location and the average height of the planet in the sphere given by the snapped position and the radius as well as info on what layers that area belongs to, so water, land, lava, etc.
Additionally I'd need a call to get a list of all map features with their type and location.

There also is a bug with the air scout. If you place it to the edge of a lake then its impossible to shoot it down or reclaim it. The only way to kill it is with an ubercannon.

Bug in system editor: If you choose "asteroid" in the planet biome dropdown, and then preview terrain, it gets stuck saying "The planet is loading." Secondary effect: in this state, refreshing the UI crashes the program.

I was able to Close the system and discard changes without a crash, but I was also able to repro the "planet is loading" stuck screen. Thanks!

So will we be looking at a release candidate soon?

I think in PA Chat jables said that they will update the PTE once more like tomorrow or so and if it then works all well it may happen by the end of the week.
We'll see I guess.

What Colin said hehe

I hope it includes the personality_tags fix, that'll make me a happy bunny

I am playing around with that now and I think there may be some issues lurking with doing it like that. When I create a 2nd world view and set it to second 0 I get occasional flickering economy stats. They flicker to zero, the value the economy in my 2nd world view has. I also get the init messsages to the UI again, so stuff like the celestial data handler is triggered the moment I first query the 2nd world view. I suspect some of the code makes questionable assumptions about the number of existing world views or rather all existing views just spam all UI scenes with their status data.

To reproduce in an unmodded PTE run these commands in live_game_econ after spawning your commander:
api.time.set(0, api.getWorldView(1)); model.energyGain.subscribe(function(v){console.log(v);});
You will see it print 0, 2000, 0, 2000 and if you look closely the values in the UI will flicker to 0 once in a while.


Another idea: How does the server culling react if I switch it on/off once a second? Can I somehow have it enabled for a short time and then disable it again to get occasional full updates?

EDIT:
:s
There is another two issues that to me are more important than all the rambling I did on the previous pages:

1.) Radar dots do not show up in the unit info API at all.
2.) There is no indicator I know of if a unit is currently visible or if the data I get from the API is outdated. So if I look for enemy units I cant easily know if it is hidden in the fog of war or not.

Any chance this still gets added? There is no way at all to work around 1 and for 2 I would need to reimplement the whole fog of war stuff in js. The client has boolean flags with this data on visibility ready somewhere, I'd really love to get them.

EDIT 2:
Some other things, not as important but also would be really nice to have:
The info on orders for structure build orders seems incomplete. Fabbers only have a location of the order and the info that it is a build order. There is no info on what is being constructed. For factories the info is there. It's just not possible for me to know where a player wants to build what structures.

As far as a heightmap goes, you can use the puppet API to determine that information. Generate a puppet with location snap and no model, and if you set the description flag, the result will come back with the terrain location. (But no navigation information, unfortunately. I would like to add that in the future, however.)

I have an experimental upgrade for puppets that allows it to accept bulk puppet requests, but it's too risky for our current timeframe. It will have to be added in a future update.

As I said that is what I am doing, among other things. However doing one puppet request per pixel of my map makes it kinda ... slow. Lower resolutions are faster but less pretty
Well if midterm you get out that extension to puppets that'll be nice, maybe I can then push the resolution a bit up.
Either way any chance to get a "is currently visible" bit on the unit info query? I think that may be something you can still do on a rather short term.

One can hope

Yes, the secondary view trick really needs some extra support before it's truly viable. I've added it to my to-do list for a future update.

RE: 1) the radar dots (we call them "blips") are not currently exposed, you are correct. I've added that to the backlog.
RE: 2) we do have some observability state that we are not currently exposing via the worldview api. I'll add that to the backlog as well. I'm not actually sure if the observability you are after is sent to the client, however. The fog of war is calculated on the GPU in screen space on the client to some degree. Once an enemy goes from being visible to invisible (called a ghost on the server side), I believe it stays "visible" on the client, from the worldview perspective. It then relies on the fog of war distance field rendering as an indicator that it's stale recon information.

Also, you mentioned the fabber orders. The orders are their own entity, which is listed in the unit information the worldview API reports. Unfortunately, the orders aren't currently exposed. (That one's already on the backlog.)

Ah, I see. This was on the previous page. (heh.)

The build placement test is performed entirely on the client.

I like your backlog and wish it the very bes
About the visibility bit: It's on the client 100% certain. Before I had the API I was using an external program to read data from PA client memory space. There is a flag I read that had exactly the data I want. I can tell you the bits I am looking for in version 82098 were at the offset 0x1A5 after the base address of the unit data structure. Quite a few bytes offset, but constantly. So you have to have some boolean flag somewhere that is placed always in the same location relative to the units that states "is visible or not". The unit structures (well the base pointers to them) I was dealing with were in a big array list that contains all entities of the game, so also stuff like features and the like. (which I btw would also love to see on your backlog "allow to query a list of all features")

I run a lot of AI games at 2.1x speed. Recently I've been seeing a lot of the following error:

WARN Misuse of StepCurve::appendStep()! Adding a key at time 653608 after we have already added a key at 653686.

Build 84871-pte - 7/29/15

For more information about PTE and how to access it, please visit: http://exodusesports.com/guides/exodus-explains-planetary-annihilation-pte/

Asteroids
Increasing the spawn times of asteroids on Medea system


AI changes
AI unit cap no longer affects Nukes and Anti-Nukes
Fix for an issue where the AI would not fire nukes in mutli-planet games
Fix for an issue where the AI would send an orbital radar to another planet and it sits there doing nothing
More fixes to the AI platoon distance calculation
Fix for the bug where the AI sometimes would build Nukes/Anti-Nukes and then not have them ever build anything
Minor AI econ balance change
Fix for AI personality_tags having no effect
AI should expand to other planets a bit faster
AI will build more ion cannons
Fix for crash in AI if a transport died immediately after unloading a unit
AI can build Ion Cannons with advanced fabbers
Improved the AI's orbital game a bit
AI perf improvements
AI will let its metal storage fill up a bit more before using the wasting metal build items


Mod support
Fix the documentation of the world-space order schema
Added WorldView.fixupBuildLocations
-Performs a build placement test, including snapping & etc as appropriate
-Fixes the units list in various WorldView.sendOrder commands
Changed the schema of holodeck raycast call results to include the currently focused planet
Added Holodeck.focusedPlanet() function call, which returns the currently focused planet
Fix for the misspelling of "maneuver" that was prevalent in the codebase
- In WorldView.sendOrder, removed the requirement on location for non-location commands
- Added valid stance value documentation for the WorldView.sendOrder


Bugfix/polish
Fix for AMD/ATI brightness bug
- Trades brightness for banding
- Use --gl-force-mrt-srgb-capable on the command line to turn this behavior back off
- It is still uncertain whether this is a driver bug or a pipeline configuration bug. It appears that there is some state that leads to improper blending occuring while filling the diffuse colors in the g-buffer.
Fix for a possible divide by zero in physics
Minor physics perf improvement
Fix for overlapping controls (add slot, tag, and privacy controls) in minimum resolution
Fix for particle emitters with the same shader and texture but different facings sometimes not respecting the facing setting
Fix the autoscroll handler
Fix for game stats and pause screens constantly updating in the background. Significantly improves UI responsiveness
Show that a game is sandbox in server browser
Fix the start screen music not playing
Fix for beam particles sometimes not rendering
Coherent crashes that would leave the UI in a non-responsive state now refresh the crashing panel
-Includes a 30-second cooldown to avoid infinite refreshes.
-The exception dialog will still show up, if one would be triggered.
Teleporter (A) now sends a new "Linked" UnitEvent which is processed through the watch list and handled by audio.js
Saving the game is no longer enabled during landing & game over states
Disabled the "play from here" button when it would end up before commanders have landed
Fix the sliders in the system editor
Fix a bug where the metal planet's radius could be set lower than the minimum
Fix for the colors in the color picker to flow out of the UI space
Fix an issue where a twin CSG could get left behind in the system editor and the user could not delete it
Fix a server crash when rewinding the game and then saving
Restore the display of Kickstarter backer names in the Armory
Fix for GW battles with mulitple commanders after save/load/resume
Fix for a crash that occurred on some machines when you open chronocam
Fix an issue where the last GW save would not appear in the continue last game spot when you complete a battle and return to main menu
Remove console log spam
Interplanetary transport notifications including visible enemy commanders
Removed a redundant biomes list
If the UI is hidden when the game ends, it will be shown. The UI can be hidden again once the panel is closed (by entering review mode)
Fix for GW systems not spawning the correct type of systems on harder difficulties
Fix preferred commander tile state in Armory
Ensure that correct commander image is loaded on the Start page
Fix a bug where nukes couldn't fire after targeting a gas giant
Fix the Revenants minions so they work like everyone else
Fix for an issue where ranked matchmaking was not matching people properly
Fix for an issue where players could not pick their commanders in ranked matches
Fix for an issue where Mac users would not get build orders on their factory when choosing specific factions


Known issues:
When a player disconnects from a Ranked game, their opponent is not notified that the game is paused due to a disconnect.

Has this been looked into yet? @mkrater

I don't think so, but I can check.

Edit: It is on our list to review, but is at a lower priority at this time.

Well, that should make @Spriggan43 (and others) happy.