Scratch

Lucario621 wrote:

demosthenes wrote:

RHY3756547 wrote:

OK HERE IS MAI ROBOUT GUISE







IF IT WERE VISHIBLE IT WOULD BHE CONVEHX SO IHT ISH PERRRFECTLY LEGALLLL

IN FACT IN IT OOVER SISE

I have said many times, it must be filled.

I hoped to avoid confrontations about area because it makes everything more complicated.
[b]Now on robots must fill a 63x78 area at the center of the sprite, it can have anything else but it must have at least that.

I'm not saying that mine ever was not going to be filled, but you never said it had to be filled. So don't say you said it many times...

Also, I'm 99% sure you mean 68x73, I hope, because thats what it was the entire time, and it's not fair that you're changing it...

And also I still think it's unfair that we have to have such LARGE robots. I thought you wanted us to truly use our scripting skills and challenge us to see who could make the best dodging robot, but you're not really showing it, if we have to have big robots...

Can I have a robot, which is exactly the dimensions you required (68x73), and is a exact triangle though (acute, isosceles), so it has about half of the area of a full square? Like maybe, a minimum area of 2000 pixels.... idk.

This is the reason why we need AREA RULES instead of those ridiculous size constraints.

Lucario621 wrote:

Demosthenes - please give us more time. There's many arguments, and depending on whether you change the rules to say yes or no to them, there may be more possibilities for us, or possibly you may disqualify us for doing things that are not against the rules...

I agree.

Lucario621 wrote:

nXIII wrote:

OK fine: a single black pixel in the middle (it's filled) and four at the corners (the correct dimensions)

...Although I think that's stupid, I can still agree with it.

Exactly my point. We need more rule-settling time.

demosthenes wrote:

Okay 1 more day to make your robots I'll work to resolve all controversies when I'm online tomorrow.

...Yeah, but we need 1 day from when you resolve all the controversies. So if you settle them tommorow, we won't have much time, considering we still may have to make changes due to new rules, and we don't have 5 hours, because we're not computer geeks, and we have lives. I vote the deadline should be Friday, at this rate.

Last edited by Lucario621 (2010-03-15 21:05:42)

demosthenes wrote:

Lucario621 wrote:

demosthenes wrote:

Okay 1 more day to make your robots I'll work to resolve all controversies when I'm online tomorrow.

...Yeah, but we need 1 day from when you resolve all the controversies. So if you settle them tommorow, we won't have much time, considering we still may have to make changes due to new rules, and we don't have 5 hours, because we're not computer geeks, and we have lives. I vote the deadline should be Friday, at this rate.

I'd like to make it a little earlier, does Thursday work for you?

Sure. But what's your rush, I'm just wondering? 

demosthenes wrote:

Lucario621 wrote:

demosthenes wrote:

I'd like to make it a little earlier, does Thursday work for you?

Sure. But what's your rush, I'm just wondering? 

I want to get started with the next one    I have a great idea for it although it will require more work to set up than this one.

What is it?My idea would be something that would involve collaborative robots,like Robot soccer or Robot Relays.Also,do you need my robot now?I'm going on vacation on Friday(my robot stands no chance against the trig dependent ones like Lucario or Justickman,but I might get lucky and go against an easy person...).

Last edited by Brass45 (2010-03-15 21:23:48)

Brass45 wrote:

demosthenes wrote:

Lucario621 wrote:

Sure. But what's your rush, I'm just wondering? 

I want to get started with the next one    I have a great idea for it although it will require more work to set up than this one.

What is it?My idea would be something that would involve collaborative robots,like Robot soccer or Robot Relays.Also,do you need my robot now?I'm going on vacation on Friday(my robot stands no chance against the trig dependent ones like Lucario or Justickman,but I might get lucky and go against an easy person...).

Thursday night.

More on-topic, I have a list of the current (most-updated) rules:
References look like this:[1]. Footnotes look like this:{f1}

1. Banned blocks - The '[something] of [aSprite]' block is banned for direction and position[1] on all enemy sprites. Because of the exception for sprites on your team[1], there is no point in banning the 'x position', 'y position', and 'direction' blocks anymore.

2. Robot specifics - The robot can move no more than 10 steps per frame/repetition of a script. Demosthenes will build sensors that can detect unfair movement.[1]{f1} You may only have 1 (one) robot.[1] The robot dimensions and approximate size can be found here. They are 68x73. Specific size rules: The robot must be convex[2] and have LARGER or the SAME dimensions as the example. It must also be a filled shape.[3] Note: a quoted post says that "robots must fill a 63x78 area at the center of the sprite, it can have anything else but it must have at least that."[4] I cannot, however, find the original post. Your robot will have 100 health per round[5], and will compete with one other robot at normal stepping speed.[6]

3. Projectile Specifics - the projectile costume guideline can also be found here. The projectile must move 12 steps per repetition[1] and expire after 45 frames.[7] You may only have ONE projectile per robot.[1] Projectiles subtract 1 health from their enemy when they hit.[1]

4. Miscellaneous Rules - You may have NO MORE THAN 7 sprites on your 'team', which MUST include 1 (one) projectile and 1 (one) robot. The other sprites CANNOT be robots or projectiles, and MUST NOT deal damage or affect the match in any other way than sensing.[1]

to be finished... just posting to save it.

Footnotes -
{f1} Note to Demosthenes: this will not work, because scripts run at different repetition rates due to their lengths. In other words, if the script repeats faster than the sensors, it will instantly be disqualified, and if it runs slower, it may never be disqualified.

References -
[1] Original Post (here)
[2] Update post by Demosthenes (here)
[3] Answer post by Demosthenes (here)
[4] A reply by Lucario (here)
[5] A post by Demosthenes (here)
[6] A reply by Demosthenes (here)
[7] A post by Demosthenes (here)

Last edited by nXIII (2010-03-16 15:14:20)

RHY3756547 wrote:

And NXIII - in your post you said the robot had to be concave. This is incorrect.

Oh... sorry. Fixing...

RHY3756547 wrote:

OK - here is my revised robot. This had better be "legal" or I will strangle someone.

http://i364.photobucket.com/albums/oo85 … Newbot.gif

Size is 63x78.

Robot Shape is convex.

Robot is filled.

Everything checks out.

Confirm this so I can make final changes.

And NXIII - in your post you said the robot had to be concave. This is incorrect.

I'm doing my triangular robot the other way (the thinnner, longer way)

Last edited by Lucario621 (2010-03-16 15:36:03)

Lucario621 wrote:

nXIII wrote:

{f1} Note to Demosthenes: this will not work, because scripts run at different repetition rates due to their lengths. In other words, if the script repeats faster than the sensors, it will instantly be disqualified, and if it runs slower, it may never be disqualified.

I disagree with that. It will always work perfectly...

Yeah - that's kind of incorrect.

Scripts run in paralell. all loops are processed in one frame every frame. There are no frame delays.

nXIII wrote:

RHY3756547 wrote:

Lucario621 wrote:

I disagree with that. It will always work perfectly...

Yeah - that's kind of incorrect.

Scripts run in paralell. all loops are processed in one frame every frame. There are no frame delays.

I'm not sure about that... one second -
Nope. Not true; test it out: make a new Scratch project, make two sprites with a variable 'x', give one this script:
[blocks]<when green flag clicked>
<forever>
<change{ x }by( 1
<end>
[/blocks]
And the other this one:
[blocks]<when green flag clicked>
<forever>
<change{ x }by( 1
<wait( 1 )secs>
<end>
[/blocks]
The variable in the first sprite changes a lot faster, meaning the loop isn't waiting for the other one to finish before it starts again. Apply this to the problem at hand, and the quicker loop repeats more, triggering a false alarm.

OMG!!!

You're really making me angry, considering how you're making the stupidest statements.

OBVIOUSLY, it has slowed down, because there is a block that PURPOSELY slows it down, and allows the other scripts to run in the mean time. That is the worst example you can possibly give.