New Element - LDBL (Lead Ball)

  • jacob1
    9th Apr 2014 Developer 1 Permalink
    So you aren't asking for moving solids, just single pixel balls? Well that's better. But still not easy at all. The behavior you see with BHOL and PHOT isn't caused by a specific piece of code that can be combined. It's caused because of photon being attracted to gravity sources, and then the complicated realistic reflection / other light movement code. As the photon gets closer to the gravity source, gravity gets stronger (which wouldn't happen with real gravity very much). Also I don't entirely understand the photon reflection code anyway, it's not something I've ever had to modify. It probably wouldn't make sense to add it to a solid.

    Another thing to consider is that, if you did actually attempt to combine the code and make a solid that moves like photons attracted to a Newtonian gravity source, would a lot of them at once even work? They would still all collide with each other and not be able to move very well. I always have this problem when making my own moving solids :P. Allowing them to move through each other is a bad idea, right now only energy particles should.
  • PowderChallenge
    9th Apr 2014 Member 0 Permalink

    @jacob1 (View Post)

     It will be a single pixel, behaving like a photon under BHOL gravity with same reflections and all, however it would also react to normal world gravity and collide with other ldbl same as photon collides with solid objects. I thought it would be easy to implement since the code to do such things already exists.

     

    @jacob1 (View Post)

     What if this was under special? My idea was that it wouldn't also have normal powder physics, unless it has some small reaction to pressure. Also, I know it wouldn't make sense to have powder and photon physics in the same object, but I figured lead ball would only behave as a powder at extremely low velocities. IDK, I just thought since all physics interactions have been coded before and work well that it would simply be a matter of combining the right components. When I code things I often find myself able to take parts of two code chunks and make a third unique behavior. Sorry if I came across as not respecting how challenging coding is, I know all too well and you probably don't need to hear about it being easy.

    Edited once by PowderChallenge. Last: 9th Apr 2014
  • jacksonmj
    9th Apr 2014 Developer 1 Permalink

    The photon reflection code was written by Skylark and is therefore... complicated. It also has a bug which means it doesn't work on some shapes. However, a long time ago I did spend a few days unpicking it, and rewrote it so that it works properly on all shapes (though never merged the change). So I do vaguely understand photon reflection, and I think the surface normal finding code should also work for non-energy particles colliding with solid objects.

     

     

    I suspect the main thing that would need working on is collisions between particles. Photons sidestep this problem by not colliding with each other, and by only changing the photon's velocity and not the velocity of the other particle when colliding with other particles. But that method can't be applied to this suggestion.

     

    Most collisions in TPT do not conserve momentum. At the moment, one of the colliding particles has some component of its velocity (either x or y or both) multiplied by an element-dependent number, which may slow it down, stop it completely, or reverse its direction.The velocity of the other particle is unmodified.

     

    Realistic bouncing would basically be changing this collision behaviour so that the change in velocity is related to the orientation (surface normal direction) of the thing that the particle is colliding with, instead of just multiplying x/y/both by some number.

     

    However, if you want realistic movement for particles that can collide with each other, collisions between particles would need to be fixed so that the velocity of both particles involved in the collision is modified if necessary, instead of just one particle, and so that there is some momentum conservation.

     

    For example: two LDBL particles colliding in mid air - both particles should have velocity changed, and bounce back off each other. Under the current system, one of them might not have its velocity changed. Or you could have a LDBL particle completely stop in mid air when it meets a single particle of dust.

     

    Unfortunately, fixing this would likely involve rewriting most of the current particle movement code.

    Edited 10 times by jacksonmj. Last: 9th Apr 2014
  • KydonShadow
    9th Apr 2014 Member 0 Permalink

    @PowderChallenge (View Post)

    make your own mod then

    Edited 2 times by KydonShadow. Last: 9th Apr 2014
  • Schneumer
    10th Apr 2014 Member 2 Permalink

    @PowderChallenge (View Post)

     I know that there are 5-7 people that know how to code on this very thread. Which is the majority.

    Edited 3 times by Schneumer. Last: 9th Apr 2014
  • NF
    10th Apr 2014 Member 0 Permalink

    @Schneumer (View Post)

     I am a non-coder way too complicated for me.

  • greymatter
    10th Apr 2014 Member 1 Permalink
    @PowderChallenge (View Post)
    Originally in the first post, you said that:
    Very interesting mechanics can be added with this, and we could enjoy playing with rube goldberg machines and other fun bouncy-ball contraptions.



    Now bouncing photons can be a "bouncy ball". To make mechanical rube goldberg machines we need moving solids that are attached to a rotating joint that moves when struck by the lead ball. Now we can't have moving solids like that.
    I don't see much other ways by which this can be incorporated in a chain reaction of any sort. Unless someone manages to make incredibly accurate machines that fire lead balls and hit them together. But even that is useless, and we can fire existing powders all day. I don't really see much uses for this.
    Now my opinion on coding this:
    We'll need a momentum imlpementation to make the lead particle do anything at all. This would mean changing the way a particle's velocity is changed on collision. Which makes things complicated.
    We can't change the physics of the game in order to stay compatible with old saves.
    So if the update of the lead ball could check for any particle nearby, identify whether it is a solid or powder, and have it's velocity reversed (just flipping it's direction) while still under the influence of gravity in case of solid, or halve it velocity and then flip it's direction 180 degrees and add half of the original velocity to the velocity of the powder encountered and flip the powder's direction, this could be possible.
    But I don't know what I just said could be implemented. It involves modification of the velocity of one particle from inside the lead ball code, and I don't know if that can be done.
  • h4zardz1
    10th Apr 2014 Member 0 Permalink
    if lead ball can exist, then rubber ball can exist too
  • PowderChallenge
    11th Apr 2014 Member 0 Permalink

    @jacksonmj (View Post)

     Actually I was thinking maybe lead ball could treat other lead balls as static particles, without worrying about conservation of momentum. It would not be quite so realistic, but still add fun mechanics. I don't personally know how difficult it would be to implement conservation of momentum for a group of experienced devs like yourselves, but if it would be too hard it could be eschewed. This would only apply in LDBL-on-LDBL collisions. I figure having ldbl collide with regular powders and liquids, etc, would just either displace the other particles or bounce off them.

  • h4zardz1
    11th Apr 2014 Member 0 Permalink
    @PowderChallenge (View Post)
    so it works like entity in minecraft?
    @jacob1 (View Post)
    i like this type of coding. (it is basic, so don't think it is colliding any other type of liquid/powder)
    upon collide with watr
    if collide in X pattern
    reduce vy by vy1*1,2
    if collide in y pattern
    reduce vx by vx 1*1,2
    since liquid can be passed by powders, the ball will actually pass it.
    upon collide with stne
    if collide in X pattern
    reduce vy by vy1*1,7
    if collide in Y pattern
    reduce vx by vx1*1,7
    upon collide with ldbl
    if collide in X
    if collide with no vy ldbl=true
    reduce vx by vx1*1,6
    if collide with no vy ldbl=false
    reduce vy by vy of ldbl
    if collide in Y
    if collide with no vx ldbl=true
    reduce vx by vx1*1,6
    if collide with no vx ldbl=false
    reduce vx by vx of ldbl
    if hit in X
    if hit from no vy =true
    add vy by vy1*1,5
    if hit from no vy =false
    reduce vy by vy of ldbl
    and basically same with the Y, just flip the X and Y.
    it would spend a little time copying the degress mechanism, BUT it would spend a lot in the placement.