|
|
Post by ganondorfchampin on May 6, 2011 22:46:24 GMT
The purpose of this thread is the intensely study elements in order to better understand their behavior. We aren't trying to generalize an elements behavior, we are trying to figure out EXACTLY what they do from frame to frame in different environment. For example lasers appear to move in beams, but why do they move in beams? When closely examine individual laser particles you discover that each particle has its own direction which determines the location and direction of new laser particles in that beam, and after 13 frames a laser particle dies, keeping the beam at a constant length once its full size. Powder particles don't move at a predictable speed. Rather they appear to have around a 20% chance of falling down one dot each frame. This causes them to spread out, but overall have a predictable average speed. On the other hand bomb has a set speed for each frame in its fall. First it takes 5 frames to fall, then 2, then 2 again, then 1, then I believe it continues to alternate between 2 and 1. This causes bomb particles to fall at the same time and not spread.
|
|
|
|
Post by Draxorion on May 12, 2011 4:22:44 GMT
There are a few of these kinds of threads in the backups. Very detailed, indeed.
|
|
|
|
Post by endy123 on May 12, 2011 17:37:35 GMT
most of them aren't all that complex.
It's the ones with either "behavior" or an odd position exchange system that complicate things.
|
|
|
|
Post by ganondorfchampin on May 12, 2011 22:26:27 GMT
Ant, laser, superball, bomb, thunder, bird, liquids as a whole, powders as a whole, gas and cloud are all elements worth investigating.
|
|
|
|
Post by Anonymousperson5 on May 13, 2011 3:22:49 GMT
Yeah, but powders fall at different rates. Fireworks certainly falls faster than salt.
I have also studied ant quite a bit, and it can be fluctuating. It appears to change between 1 and 2 ppf, but is invariably 1 ppf on diagonals and movement #6 (if you looked at the db wiki, which *cough* I myself contributed the majority of the text to)
|
|
Miczu
New Member
Posts: 17
|
Post by Miczu on May 13, 2011 9:27:37 GMT
Every element is "born" with "id", first element (after reset or something) has id "1" , second "2" and so on.
When element "dies" his id is "free", and if there isn't other free id, that isn't smaller then that id, it will be used with next born element.
After this introduction, this is why I can't work with thunder:
Every thunder move in metal at constant rate - 1 pixel at a frame, but within the frame, thunders with smaller ID move first. Thunder can't move into space that is occupied by other thunder. So if thunder that has id "1" want to move into thunder with id 700, it will die because it's occupied. If the id's where to switch, the thunder with bigger id, would wait till thunder with id 1 would move (or die on the older), and after that move.
After many thunder dies in different places on the screen, the id will mix and you cannot predict outcome from collisions and therefore you cant do collision based gates for thunder even with thunder ball perfect thunder generation.
TL/DR ? Thunder still sux for complex and small data computing (thunder tech).
|
|
|
|
Post by Anonymousperson5 on May 13, 2011 13:33:49 GMT
That can be easily remedied by teh thunder ball. Stuff it in mercury, and you've got a constant rate. Althoiugh I agree it's bad for small things.
Can someone investigate that stuf for the thunder ball?
|
|
Miczu
New Member
Posts: 17
|
Post by Miczu on May 13, 2011 18:59:37 GMT
10300000O100000000100*02102*01*03*06*05*01w00q00004000v00u01u0B*0200Du0F00Cv0E10E00Ku0J*0Hv0Lu0G*0Bv0Q00N10M*0Pu0O*0Su0X00I10V*0Y10b00au0R00e00Uu0fv0T*0W10dv0j*0cu0iu0Zv0m00g*0ku0o10lu0pu0v10u10xu0tu0z00h00**0s010*0n01200r*13*11*17*16*1901501Bv0qv1Du0wu0.*1801Cu1F014v1E10y01Ku1J*1Hv1Lu1G*1Av1Q01N11M*1Pu1O*1Su1X01I11V*1Y11b01au1R01e01Uu1fv1T*1W11dv1j*1cu1iu1Zv1m01g*1ku1o11lu1pu1v11u11xu1tu1z01h01**1s020*1n01*.00x00e00S0By26S28x1wu0..25T28T2A10M.2D000y00T2Fu0B.2Hy2J02Ix0J.2MT2K000.2Q02O12Gx2Jv0BT0A02Uu0Bs2IT2X002x0Js2b02N*2510Ms2fT0Gx2ey2NT2k12iy2m02d12oT2c*2hu0Br2bt2Rr2fo2No2Ny2t000r2br2cy2.v2j02Z00Dy2py32y36x0Jv2jq00n0Sw39y2Nw2Nv3Fw3DT0Bw2mp2Xp2cv00w3Hs2uT2cT3P03G12Gy2Nr2pT3QT3C10Mo2bp3K02Jp2cr3U03cv3M13Xy3cT3V02*T3hT3Lw0Jo33T3j03i03g03Ru0Bo3m03pr3pT3k13fT3nT3bT3x00Dw3ly3u02pr40T3Wu3ry4203TT3zv3eu44T3zT3O040v48000o3sT3hr45v4Do4F03cr4Hw3*T4A03oT3nv4Iy45T4BT4Pw4M045r4L13w04VT47w4UT3zr4Wu4904Y04Cw4ap3ZT2*000p4c04Ey2Nz2Np4ko2b*0Bp3a04rT4j03.11y02201r*23*21*4z*4y*4*04x051v1qv53u2B04wv5414v*4.052u55*59v57u1.*5Cu5B*50v5D056u5G05A158*5Hu5Kv5I*5F15M05Lu5E*5N15Rv5P*5Uu5T05S05J15Vu1w*0710415e*5dw0A0dM7
Every load you get different result so it's quite bad...
|
|
|
|
Post by disabled on May 17, 2011 18:42:29 GMT
On every load, the position in the element vector are randomized to make it nondeterministic. If you'd reset, and then construct the same thing in the same order a couple of times, it's deterministic. You can also try this with copy/paste, as the element vector is not mixed when you paste something. Create a small device, copy it, reset, paste it (to an exact position) and see how the thunder reacts, repeat and the thunder will do exactly the same. Being non-deterministic is a design concept of PG. *edit* I dedicated a blog entry to thunder movement in thin air. |
|
