First thing you can change...

New SpeedCalc:

New repulsion:


That's one obvious thing that pops out at me.
At least I think that's right... oh well, it seems to behave the same, I think I haven't gone completely crazy yet after 73 hours of no sleep

There's thing you can also do with DifCalc, but I'm making sure I got it all right, and also figuring out what the heck I did exactly with tables to make things faster... I know it was strange though.

EDIT: I think you should start to make sure it the particles ignore themselves, and have a max repulsion also. That way you could probably eliminate the whole if 1 < DifCalc(..)... thing.

oh yeah, i knew speedcalc could have been optimised.. sweet. i'll get on testing that and seeing if i can cut anything down anymore aswell. thanks
if the table thing comes to you let us know, this method can probably only be optimised to about 100 particles or so on your average machine..

Well, okay, I have somewhat of an idea of what I did before.

It involved placing particles into groups. Those groups acted as a globs of water that moved together. I never tested if 2D tables worked yet, so I had start/end points of the "globs". Each glob had its own velocity and position, and I was working on mass/size too. A quick check was done to see if the particles in the glob had a velocity similar to the glob's velocity, compared to a threshold, and the position was also compared against a threshold by the approximate center of the glob (done by a square). If it exceeded the threshold, particle was ejected and made into its own group or "glob" until it fit within the thresholds of another glob.
Globs/single particles were run every UpdateActivity, particles within globs were run every third.

Main vars:
EjectionThreshold: Difference in velocity required to escape a glob.
ElasticThreshold: Difference in position required to separate from a glob.
GlobChildCount: Counter for when to run the particles within a glob (if GlobChildCount >= 3)
GlobDensityTheshold: Density required to be a glob (Particles per game meter, 20px by default)
START_INDEX: Start of a group.
END_INDEX: End of a group.

I am far too busy to reconstruct all that today or within the next week probably, but someone else is free to do it

I would recommend looking into the possibility of two dimensional tables, but I am doubting that it is possible with Lua. If it isn't, you can keep separate tables for start/end offsets of groups, or you can just put them in the array and have it check for those.

NOTE: This actually did work very well. However, this was pretty simple. This had almost no characteristics of water other than it flows and conforms to its container. The particles still die rather fast if they touch terrain, and are spaced out of course. If we had some functions to draw with Lua, I could do this easily, since I already had the globs. If we ever got the drawing functions and had some speed improvements... we could get semi-realistic water that doesn't react much with actors, except for ripping their heads off occasionally.

EDIT: The difference between "is" and "isn't" can mean a lot...

EDIT2: For an idea of how well this worked, find the largest pool area for water, imagine that filled with particles that are spaced a bit. Barely lagging on my computer (2.4GHz).

well, that would be much better, and given the code i could probably make it work in a more realistic way.. i was planning on having some attraction between globs like that and merging globs into a bigger glob with a larger radius if i got something like that working, but i couldn't because of my limited knowledge.. if you could give me an example of that i would get all the other conditions working and try to optimise whatever. i think this will work a lot better as a community thing..
i think i'll put the regulation stuff in a separate function aswell, like i initially intended and then run it every few updateactivity()s

To be honest it sounds like you're complete BSing everything you say. Herp derp it got deleted and removed from the recycle bin yeah OK

But anyone who could program in anything should be able to tell two dimensional tables are easily possible even at a glance(without testing it). Why would one even "doubt that's possible in lua."




Start/end points makes no sense at all. Why would a 2d glob have a start or end point when it could be assumed the water would glob together on a 2d plane and not in a 1d/straight line? This still doesn't point out how you would solve the errors presented in the first code at all. In total, placing each particle into separate "globs" makes no sense. The only reasoning behind this I can see is performing the same calculation on a number of particles that posess similar values. Even then that seems really unnecessary as it doesn't optimize much as you're still doing the math to hold the glob together/check its position against other globs.

Umm... things getting deleted by other users does happen in the actual world. Just because lots of people use it for an excuse doesn't mean every instance of it is a lie. This would be one of those cases that it's not a lie.

How many programming languages do you actually have semi-decent experience with? There are languages out there that do not support 2D arrays, and the structure of these "tables" resembles a linked list in some ways, which could make them only be one dimensional depending on how they work. I'll admit it's rare, but it's foolish to just assume anything in a programming environment.

The end points are in the array to separate globs from other globs.
Pseudo-code:

Make sense?

As for the calculations thing, that is exactly the point: Performing the same calculations on a group instead of separate particles. This saves a LOT of time compared to going through each particle.
The math to hold the glob isn't that intense, and is not calculated every time.
Also, the math to check the glob's distance to another glob is not that intense either, and doesn't need to be calculated often either. When you honestly think of how much each glob would be each frame, it only needs to be checked every few frames. We're not aiming for perfect physics here. And anyway, if a glob was moving too fast for it to connect with another glob, it wouldn't work in the real world anyway. The whole time we've been desperate for anything resembling water, and we have to be content with what we can get.

I've ran all my tests, my methods were faster. Take it and believe it, maybe try to code it yourself and see the results, or start an argument and get nowhere with water in CC. It's your choice.

I'm working on a new method now anyways. I've done a few tests today, and it is much faster to have an external program collect values from CC, run through and calculate everything with optimizations not possible on the Lua level, and pass back the new values for velocities or positions. There's still a few bugs to work out though, lost data, things not being transmitted fast enough, etc. If that can work flawlessly, water particles are very near. (If I hear one person scream that this is impossible, I hope to prove you wrong soon enough.)

NOTE: I am not going to be online for a few weeks in a couple days. School and family complications. I'll try to sneak on at some point though just to check in.

Hah! That's a big insult to Data's coding. But whatever way you can get it done, do it.

wait....

So its reading what's happening in CC, Sending that data to a 2nd program thats also running, which is calculating everything faster, even though it would have less resources available because CC will be running at the same time and take priority because your program is in the background, and then magically transport its new data into CC, ALL BEFORE A NEW FRAME HAPPENS.

Your adding processes, not replacing them, and expect it to do the same calculations, not only in less time total, but less time WHILE its running in the background also while the game is playing, and tell the game what to do, all within 1 frame (real to sim cap LOL).

What I see happening is either real-to-sim cap has to be off, and you'll end up breaking the frame-rate over your leg, OR realtosimcap will be on and everything will move a little, and then blink over to where your program thinks it should be, and every second or to BLINK everything moved a bit. if you seriously found a way to optimize the game by adding a process, then surely you should be able to prove this.


I demand a working screen-cap, of playing in windowed mode, while the process manager is up, and in game you can see the frame rate and real to sim thingey. I want to see CC and your process in the process watcher, AND the framerate and timescale in CC.

If your program does what you claim, then CC + your process will = CC w/o your process, AND with your process the timescale and framerate will both be higher than without. prove it.

Really quick dumb question so I can do all that: How do you get the FPS and such to show? I completely forget.

Ctrl+P or some such.

i love how you can map the terrain with this in the MOID material viewer (ctrl+M x2)
heres a working repulsion demo, for those who are too lazy for anything else. lots of useless files in it from previous attempts but whatever.

Where's the part on the strength of the repulsion? I see how it could be repelling,
but I notice that often I see 2 particles right next to each other in mid-air, and nothing
happens between them.

But yeah, the lag is reasonable.

SpeedCalc() is where its at. it doesnt repel particles that are within one pixel of each other due to the huge speeds that creates (1/0.05 for example gives an addition to the velocity of 10, if speedcalc() still uses the magnitudes i remember). instead it repels them with a random number between 0 and 1.5, but it only does that each 5 or so (i cant remember the exact number) frames, to prevent more lag from happening. there is a definite need for optimisation though

How 'bout just simple circle collison, with constant repel force. Seems
a whole lot less calculating, than actually calculating the speed (even if it is random).
Also, when it goes through every particle, could it also count them,
and remove them as neccasary?

yeah it could, though what would you want to do with that? like auto-limiting the amount of particles?
and yeah, i'll get working on a way that's less half-assed. do you mean instead of inverse-gravity repulsion i should just make it do "if within 3px, repel with 1 velocity"?