Browse Search Popular Register Upload Rules User list Login:
Search:
Did you also fix the emission values written on the label?:D
Well, I made it in quite a short time, but that's because I have done this before already ^^.

Also, about the formula with the complex numbers:

C^2 = (Cx+Cy*i)^2 = Cx*Cx + 2*Cx*Cy*i+Cy*i *Cy*i ) Cx^2 + 2CxCyi + Cy^2 * (- 1)

Short version: C^2 = (x^2-y^2,2xyi)
Oh, thanks. These will proove to be usefull, no more square root and stuff xD
ooh, nice, waypoint mechanics like in one of my scenes. I like it.

Мне это нравится
I Know it has a similar mechanic as the space arcade shooter, but I didn't intend on enhancing it. I may upload another Version featuring shooting, but first I need to find an algorythm to check if a Bullet/rocket collides with an obstacle in 3rd dim. Maybe I could use One collision layer for each 1/8 of the background, but then it would result in quite an unprecise Code...
Last edited at 2015/12/15 21:44:47 by FRA32
It's nice you guys like it. It's kinda sad there are no new featured scenes, because this could actually go there, since the space arcade shooter also made it on that page. But it's not my decision what goes there, so I won't complain:D
I recommend using math.cos and math.sin in your future scenes instead of cos and sin. I for expample can't run any scene containing "cos" and "sin", these wont be executed and the script would break then. Don't know how's it on your version, but I can only run scripts with math.cos and math.sin
dude tripple scene upload?
Happy birthday. I have a gift for you: Lot's of algodecathlons *not*
grr stop the useless scenes and finally start scenes dooing something special! Not that algocampstuff, that is as cheap as thin air.
Thanks mate. I may haven't said it yet, but your conveydor idea is pretty classic but yet pretty smooth. You could actually do this: The body only spawns as many belt pieces as it needs for the full width, and the belt pieces dont die when reaching the border, but instead teleport to the beginning again. That would reduce object RAM stacking and and would even improve the performance a bit, which can be importand when using a lot of belts or a big scene. But I like them like this too and would even use the idea for eventual conveydor belts in my own scenes(if you allow of course ^^)
well yeah, using negative magnetic's causes the objects to fling away, but what if one wants to have the object anti-gravity all time?:D

If you manage to achive that an object permanently stays in it's gravity state without latching to objects via magnetics, you get a free sub(maybe)
Pleaase stop making new camps. You see, algodoo is a physics simulation program, and wasn't designed so that you only make these small competitions with it. User were meant to use it to design physical processes, invent mechanism's or use the scripting feature to create even more special scenes. But it was not meant to be used so that atleast 30 "camps" exist.
I think it's the ghost image that you see when replaying a race to beat your highscore. Basically a recording of your race.
@LastChance

You are PARTLY right, since any number consisting of (x+yi) is called a complex number. And since any number can be replaced with 1 sole variable, and since said variable is dependand on the last result, one says Xn+1 = Xn^2+C, which means the new complex number X is made of the last complex number X squared plus the complex number C, which consists of (x,yi) whereas x and y are the coordinates of the point that the set calculates.

Squaring any complex number is basically like working with a binomial formula:

(a+b)^2 = a^2+2*a*b+b^2

Since complex numbers also own the factor i, the formula is slightly modified, integrating i to all places where b occurs:

(x+yi)^2 = x^2 + 2xyi + y^2*i^2

and since i^2 = -1, and y^2 * -1 = -y^2, the formula finally turns into x^2 + 2xyi - y^2, and now you can easily reorder the parts to (x^2 - y^2 + 2xyi) and you've got the new complex number.
Last edited at 2015/12/19 08:57:50 by FRA32
Well, looks like the mood in algobox is dropping again. Gotta join the ride(maybe)

Of course algobox is spammed to the limits with scenes that should be made in some sandbox program, but as long as algoryx doesnt care, we are left alone without anything against the problem...
NO!

Please, NO more marble races!

dont you get that you guys are overdooing it! You spam these scenes like trash over the street, and anyone trying to make something with quality has to watch how he is buried in this trash. Either start dooing things that were'nt created by 2000 others before, or dont do it at all. It is seriously way to much
Well, it may be another marble race, but at least you did some style. Would be cool if all marble races, which should be way less, would have some work in them
Algodoo is a physics simulator, not a painting program. You're scene is nice and all, but you are probably using the wrong place for this kind of stuff. Try to stay at "running scenes", without static images. Maybe try dooing real art in PaintTool SAI?
why did you even upload this?
Couldnt you have done the level a bit longer? Or put multiple in 1 scene. If you do a new scene for every level, it's spamming algobox full again. Take a look at my game series for example. You can see how freaking fat these are(part 4 is JUST BELLOW LAG LIMIT), and I only seperate the content into a new level when it's neccessary. You could do this with even less efford, since you just need to stick exit and entrance together. So dont post a new scene for every level 'kay?
Finally, the first step has been taken: A hybrid of marble race maker and mature person - A mature marble race maker(I guess?). Now we can use it to infest the other MR guys and then algocamp guys with intelligence! We will reclaim our position as masters of algobox!

...or maybe not, but at least you are dooing your stuff right. THIS is how marble races should look like in algobox, not like these trashspams of 10 minute worktime scenes full of 200 marbles noone is watching that all go the same procedure over and over again, with the scene taking longer to finish than the guy needet to CREATE it...
Click on one of the large circle to drop the next marble, either left or right, depending on what circle you click:D
Please dont upload one scene for every "level". They are way to small this way to be worth uploading. Condense multiple levels into 1 scene before uploading it, then its more enjoyable
dude pls dont upload a new scene for every level, its not worth for such small levels. Please put them together, else you just spam
Also, you really failed at this level. One cant even beat it without cheating. Do you actually test the stuff and put work in it? It looks to me like you just knock together some shapes and upload them as if it was something special:/
It's nice to meet you, but theres a note for the beginning: Dont upload more than 1 marble-race/algocamp per week. The algobox forum is spammed to the limits with these, and if you like to make some yourself, try to be better than all the other 50 marble race users! Maybe, if you gain my help in scripting and stuff, you could do something so special that all the other algocamp fans get so jealous that they all join your camp stuff or whatever. Just remember to make them really worthfull, a scene made in a few minutes is often something everyone could do himself, so he would not watch the scene. If you want, you can tell me your age, then I have an idea at how good you are at understanding scripting. But only if you like to, not that I go to much into privacy then xD

I hope you enjoy algodoo and upload something not Algocamp/marble-race related every now and then
I know, it's not really simple to recreate the path in a way that everything goes exactly as wanted. I added something to the top so the marbles always fall down, but against the occassional cluttering in the paths I can barely do anything unless I want to redesign the polygons on microscopic levels...
Dude dont even DARE to start ANOTHER camp! Dont you see you guys are ruining algobox this way? You throw trash around and dont even care about the others!
Sim.frequency is the variable telling me how many frames run per second of the player. This is needet since, the highter the freq., the more often postStep gets executed, and that means I have to divide by sim.freq. so that the artificial accelleration stays at it's value(The sim.frequence equations are similar to the way algodoo calculates accelleration and movement)

About your suggestions: I will try to add them all, I only need to find out how to work with textures in a way that the ball would seem to be spinning in 3rd dimension. Other than that, I could do the rest
previous | 1 … 7 8 9 10 11 … 31 | next