PTE build 85104-pte is now live!

I doubt Uber is working on that, but if a graphical wizard feels like it, the tech is there now. Simply call some js from a UI mod that places a custom model witth custom animation and custom shader magic to do whatever you want. I am not a shader wizard, but those can do like basically everything. The JS is also allowed to control constants passed into the shader, making it quite flexible.
You'd need to grab the location of volcano CSG from the map data or do something map specific to place it though, but I would guess a solution can be found for that using a bit custom map hackery.

@pinbender
Two observations:

1.) I tried to change the shader to the build shader and did not specify constant values. It seems it then uses some random other values of some other build process that was last done. You probably dont clean some variables somewhere.

2.) When I try to make a boom bot model that is always located at the location of my commander it works, but since I call "update puppet" 50 times a second it does not animate. It seems the update to the puppet reset the animation, basically freezing it at the starting value.
A right just only specify the position data I want to update

Aww... getUnitState will return the build_target of a missile launcher, but fetching that id returns an empty object. On the upside, it has no build_target when it's done, so you can at least monitor working state.

You can get the build progress of regular units being built by factories and fabbers, and it even distinguishes between built and health.

Don't see a way to view stored missiles/units. Units in unit cannons appear in the army list and have a parent that I assume is their pod; but the pod object is empty so it can't be assigned to a cannon.

That puppets API is such fun.

Yes I have but you cannot have both active at once. It only one or the other. Launch Halley to move planet but cannot fire laser. Firing laser then trying to launch Halley will cancel the effect of laser firing.

My only notes for Asteroids is can the Asteroid Belt be renamed to what we want? so it will appear as Planetoid-01, Planetoid-02, etc... Instead of 0-01, 0-02, etc...

And to be able to move the Asteroid Belt instead of just purely being on the outside of the entire system?

Yep, material constants are left dirty, which is by design. This is taking advantage of internal systems that don't have defaults. It's cheaper to assume that all relevant material settings will be explicitly specified.

That is indeed really cool! I'll definately have a go with this

• MM guys did you touch anything of the sun brighness cause yesterday without pte my game looked normal and now is a glowy madness. O used the amd brighness fix but now it is not working and i've tested with and without mods. Please correct that anoying bug.

The asteroids are coming!!!

@pinbender May I assume that the unit list API feature is also going to receive an equivalent server side API method?

So if you are adapting the WorldView concept for that, could we get the option to create a WorldView from the perspective of a certain player as well? This makes both sense client side (user with spectator privilege) and server side (to emulate user view). Default behavior for spectator and server side would be to create a WorldView with global vision.

Either way, my deepest gratitude for these two new API methods. That means client side unit ghosts and radar ghosts for ALL units can now happen.


May I assume that Chronocam injections are also planned? That's the missing gap between the puppet API and the somewhat weird side effects the Chronocam can now cause, as not all objects created with the puppet API are intended to be time-independent.

Translation between custom Chronocam events and user managed objects should be handled by user code. It's only about being able to persist custom entities, with the intention of being able to restore the mod managed state in the same fashion as the state of the WorldView used by the Holodeck is being restored.

Riveting stuff, though I have a few questions:

1. What reason will there be to build halleys on larger planets, or even just a moon? Why not weaponize a completely expendable and otherwise useless asteroid? A scale 400 planet and a scale 250 planet mattered quite a bit in their destructive power, and this made a difference before. I still think that a difference should be maintained in some way, even if not with their destructive power.
2. Annihilaser's power scales with systems, but in many games it wins the game by firing at one planet or maybe two tops. The new asteroids can have a similar effect at a much cheaper metal cost and production time; not to mention the travel time it takes to tour the Catalyst slots (believe me, this matters a LOT if you aren't using Air Fabricators and even then it still matters and those can't be teleported so they must be built on site), so isn't this shaping up to be an even stronger Annihilaser, and therefore a potential balance issue?
3. Does any of this mean that Halleys will do more than just weaponizing a planet in the future? I ask because I can't foresee any reason to not use an asteroid instead as doing anything else means you'll be sacrificing something. As a personal wish I would like the ability to customize orbits for the planets, just like in the system editor, for a planet that has Halleys built on it.

Besides these, I am liking the idea of planet v planet collisions being fatal for both hunks of rock and it is certainly going to mean a lot more tense battles in my maps, so I guess I won't be unhappy either way.

You can make a system without Asteroids, then use the moons with halleys. the same goes with the death star, you can choose not to place moons or asteroids in the system.

To add to this, asteroids can be specified to spawn in late game- so there might not be an asteroid available when you want to smash. I think the crux of the asteroids concept is to change the battlefield late game to break a stalemate.

I have a suggestion for the Planet Smash animation.

Can we have the debris stick around in a vaguely planet-shaped debris field? I was watching that awesome new animation and was super disappointed that it didn't stick around. The planet cracking was amazing

Pretty please?

And if not (for whatever reason) can you please make the debris duration at least moddable so we can make it a mod? THANKS. AWESOME.

The asteroid effect will most likely be a .pfx file and then you can simply find the particle emitter responsible for the debris and increase the lifetime value.

Unless the asteroid effect totally blows me away (or, if it's less than a 7.5 on a scale from 1 to 10) i'll probably have some sort of client side effects mod that makes it better.

PS. The effect is WIP, confirmed by Jables on pa chat.

Nope, sorry. Puppets were relatively easy to add. We've been talking about trying to get similar APIs on the server for a long time, and it just hasn't been practical. (Notably, the server scripts can only track units they create, and accessing any data we expose forces a synchronization point between the server and sim threads.)

Unfortunately, the answer is probably no there, too. Integrating puppets with Chronocam in a efficient manner would require more engineering time than we have the budget for at this point. (Honestly, this went a little over budget already. I liked the early results I was seeing, and talked @jables into letting me spend some extra time on it.) In theory, it could be integrated on the JS side by keeping mirrors of the puppets and restoring them as the time changed, but that would make them relatively expensive. A mod that needed that functionality and decided the expense was worthwhile could totally add it though. (It wouldn't, of course, integrate with save/load, though. That only restores server data, and this is all on the client.)

Please don't take cratering out of the game. Or at least give an option to enable/disable cratering/insta-kill at game creation.

On a different note, why did the commanders get changed along with the removal of commander_table from server-script? Does this mean that you're planning on making commanders mod-able via server mods? (I REALLY hope so, because the faction mod basically requires that).

Currently it doesn't look like the changes bring any advantage other than the potential for commander mods from my end.

I think a feature still needs to be balanced somehow. I would like to have a reason to build Halleys on both if I have both Asteroids and Planets in the same system.

I was actually thinking about something more generic than just puppets.

I'm not sure if the current protocol would even support this, by I was hoping for being able to add custom, "arbitrary" objects to the Chronocam history. In the form of tripplets <CustomType>("Tag","Id" => "Value"), one fixed custom type for each curve type. With corresponding onCreate, onDelete and onChange callbacks for each type+tag combination, as well as an equivalent to the unit list which allows to query for all active entities of a specific type+tag combination. onCreate and onDelete firing at the creation / end of each curve, onChange firing whenever the curve value updates - which can be constantly if it's one of the curves with interpolation (TODO: Clarify if this is sane behavior, or if polling is sufficient and onChange should only be triggered on new data points).

Creating, updating and deleting puppets wouldn't be part of your domain, as that can be handled by the client side mod now. The client side script is responsible for bookkeeping over all active models. It makes little sense to run server side scripts without an client side script anyway. Quite the opposite actually, by limiting to puppets, you would strip the option to use it for synchronization of other data, like live leaderboards, free shape drawing, the long requested "who is currently controlling which unit" feature, and a lot of other features which would require synchronization and are currently only possible via 3rd party services with no integration to replays.

Like I said, I'm not exactly sure how the Chronocam stores the data currently. I have no clue how it currently handles the visibility of entities towards specific users. I don't know either, if the Chronocam natively supports entities with limited lifetime, or if each entity needs to be removed manually. Latter one being not much of an issue, if there is an list function which can be used to restore bookkeeping in JS, both server and client side.



As for the unit lists:
Well, not having an unified access concept available on both client and server is somewhat a pity. I would have expected that it was possible to port the WorldView mechanic over to the server as well, basically a stripped down, minimal client running inside the server process. But since you implied that server and client share only "little" of their codebase, I agree, that would be a huge undertaking. But I'm not giving up hope yet, that might eventually be subject to refactoring.

Great PTE, I love it!

I don't know if it's mentioned already in this thread, i have two remarks:

Unit Cannon still doesn't show how many units have in it (there is a thread for this in the forum).

You could made a bigger on screen announcement that an asteroid entered system.

Keep up!