The Powder Toy

LBPHacker

Hi!

a) Yes, sim.createParts has changed, though only in the manner I outlined in my last comment here: in a way that still allows it to be used in simulation contexts without involving brushes. Why this doesn't apply to your case is hard to tell without seeing your code.

b) Dynamic heat display can in fact do that, there just happens to be no way to configure it from the user interface yet, nor is it documented. There's

ren.heatDisplayLimits(low, high)

, where low/high are either numbers or the string

"auto"

, which translates appropriately to the min/max heat being drawn. There's also

ren.heatDisplayAutoArea(x, y, w, h)

to configure the area in pixel coordinates that the min/max is applied to.

Ximorro

Hello!

a) Thanks, I thought the idea was to code it the same but without using the brushes that are only available in the UI. So that last parameter for the shape can only be set to ellipse, is that it? Are there plans to implement rectangle and triangle shapes in the future like the original createParts did?

b) Ah, great! That's fantastic, thank you!

jacob1

@Ximorro (View Post)
About wiki, yeah I'll update it before release (I hope), although I don't know what kind of format the restrictions will be in.

About dynamic heat display, I agree with what you said. Heat display is one of the things I want to port from my mod, and I'll definitely be adding an option to set a fixed min/max onto the UI. (the more powerful options I'll probably leave as Lua only).

@Ximorro (View Post)
Shapes are a feature of brushes, so things like triangle / square won't work. But for square, you can use sim.createBox instead. For triangle ... well, I have no idea why you'd ever want that.

If you have more issues, you can post your script and I can try to help. You may want to offload things onto a tick event for example. Queue up a list of actions and then run them in an interface event, that kind of thing.

Ximorro

I was considering creating a small script to show my problems but I noticed all errors came from createParts creating boxes, and as you suggested with createBox it's fixed now, thanks.

Yes, I understand the wiki is not updated until release, I just checked there before bothering you.

About dynamic heat display, that mode is VERY useful, thankyou. I don't know if many people is using the original mode with the full range.

By the way, why "Reduce gravity effects on ambient heat"? Does ambient heat change gravity??

Ok with the shapes, please notice I was just suggesting, never complaining, you're doing a great job.

EXACTLY, we can do it with sim.createBox(), and yes, I've never used triangle brush, I only mentioned it because it was available in original createParts. I didn't use createBox() before because with createParts I only had to change the last parameter to select ellipse or rectangle so I always used the same function.

Since we have createBox for rectangles/squares and now createParts is only going to create circle (ellipse) shapes maybe it would be a good time to change its name to createCircle or CreateEllipse (or whatever you think is suitable), now that we are in a stage of some LUA changes and maybe we have to update some scripts anyway.

For those interested, the change from createParts to createBox is as follows. Notice that createParts uses center and radius and createBox corner coordinates. For instance creating a rectangle of embers centered in x,y it changes from:

sim.createParts(x, y, radiusX, radiusY, elem.DEFAULT_PT_EMBR, 1) -- 0=circle, 1=box, 2=triangle

to

sim.createBox(x-radiusX, y-radiusY, x+radiusX, y+radiusY, elem.DEFAULT_PT_EMBR)

For circles/ellipses is the same as before, just ignore last parameter in createParts()

jacob1

@Ximorro (View Post)
Ambient heat flows opposite the direction of gravity. In real-world terms that's "hot air goes up", but in tpt gravity could be radial or in any other custom direction, and the air engine accounts for that. 99.0 changed this a little to improve airflow, but it went too far in some cases, so that's why they were reduced. It should still be stronger than pre-99.0.

Ximorro

Ah, thanks for clarification! I didn't know about those mechanics.

RandomFoxBoy

@jacob1 (View Post)

It seems like the lua api changes have broken Alloy Brushes. sim.partKill() seems to not be working the same way it used to bee working. I see no reason why it won't work and it's just saying "particle management is restricted to ID [part count].

Logs:

Press CTRL+. to view buttons added through libactivation
In create func: scripts\downloaded\232 Maticzpl-Alloy Brushes.lua:609: particle management is restricted to ID 0
In create func: scripts\downloaded\232 Maticzpl-Alloy Brushes.lua:609: particle management is restricted to ID 1
... 50,481 more lines

Okay so sim.partKill() seems to not work at all.

Found why: Commit 3adf6ef
I see no reason why that commit was made.

jacob1

@RandomFoxBoy (View Post)
Thanks for the report, that script was broken. I'll have to ask @LBPHacker about the message, it's extremely misleading in every situation that message could be printed in except one. But it is intentional to block that.

The problem with killing the particle in the Create function is that it's unsafe and can lead to infinite loops. It also makes future optimizations (such as multithreading) more difficult.

Here's an example of an infinite loop you can do today:

elem.property(1, "Create", function(i, x, y)
	print("Changing to watr")
	sim.partKill(i)
	sim.partCreate(-1, x, y, 2)
end)

elem.property(2, "Create", function(i, x, y)
	print("Changing to dust")
	sim.partKill(i)
	sim.partCreate(-1, x, y, 1)
end)

But the real reason is not to prevent infinite loops, that's just a bonus. It truly is about the optimization potential. Here's LBPHacker's message about that:

I'd like to further highlight the last point about scripts: I've been adding stuff to the api 1) to replace common hacks (like creating custom elements to implement tools) and 2) to potentially enable performance improvements (like maybe somehow running lua on the render thread, which could enable custom graphics combined with srt)

So that is the real justification. A replacement API for what this script is trying to do was already added in the current release version, checkout the tools api. In this case, rather than an element with a Create callback that immediately kills itself, the tools api can define a tool with a Perform callback. The rest of the code is the same as before.

Let me know about any more broken scripts. I already have plans to go through most scripts (or even every script?) to check for breakages. I've never done that before and would be curious to see what scripts still function for myself. Scripts that are broken by these changes, I'll work with the authors to fix, or just do it myself. I don't expect very many breakages, because most of the things that got restricted are pretty unreasonable.

Jerehmia

@jacob1 (View Post)

I think trying to make it impossible to hang the game with a script is futile because it will render the API unusable. There is always a way for a malevolent scripter to generate infinite loops in a language powerful enough to accomplish anything meaningful.

Here are some more examples of infinite loops (or better infinite recursion) using the Create callback:
elem.property(1, "Create", function(i, x, y) sim.partCreate(i, x, y, 1) end) elem.property(2, "Create", function(i, x, y) sim.partCreate(-3, math.random(4, 607), math.random(4, 379), 2) end)

Or even the most basic infinite loop anywhere in any callback function:

while true do end

LBPHacker

The goal is not to make the game impossible to hang, the goal is to cut down on ways to accidentally make it hang, and to enable future improvements. Your Create callback-based example above is not possible to execute in the latest snapshot, while your infinite loop example is very easy to spot.

TPT Snapshots / Betas