TPT Snapshots / Betas

  • LBPHacker
    7th May Developer 0 Permalink
    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.
    Edited once by LBPHacker. Last: 7th May
  • Ximorro
    7th May Member 0 Permalink

    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!

    Edited once by Ximorro. Last: 7th May
  • jacob1
    8th May Developer 0 Permalink
    @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
    8th May Member 0 Permalink

    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()

    Edited 3 times by Ximorro. Last: 8th May
  • jacob1
    9th May Developer 0 Permalink
    @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
    10th May Member 0 Permalink

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

  • RandomFoxBoy
    11th May Member 0 Permalink

    @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.

    Edited 3 times by RandomFoxBoy. Last: 11th May
  • jacob1
    11th May Developer 0 Permalink
    @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.