Oh! Oh! *Raises hand* I forgot! You can still color sense a sprite even if it's ghosted! So you can set the ground sprite to a ghost of 100 and you'll still sense it! Works for regular “touching?” too!

JoeyTheChicken wrote:

Oh! Oh! *Raises hand* I forgot! You can still color sense a sprite even if it's ghosted! So you can set the ground sprite to a ghost of 100 and you'll still sense it! Works for regular “touching?” too!

And?

alexphan wrote:

JoeyTheChicken wrote:

Oh! Oh! *Raises hand* I forgot! You can still color sense a sprite even if it's ghosted! So you can set the ground sprite to a ghost of 100 and you'll still sense it! Works for regular “touching?” too!

And?

And that (Hopefully) will solve the problem the First Poster is having!

So after painfully reading all the posts. I've gotten two things:

1. Lot's of people can't support their own reason to not support (Weird right?)

2. Apparently it's “hard to code” which in fact IS NOT.

So, not trying to sound like an arrogant idiot, (No offense ) but honestly a lot of people here are making points they have no proof for which leads me to the belief they're trying to hate on the OP. In the long term it's rude; unless you give a good reason.

So truly, I support it as per the people who can support their ideas on supporting.

(cmd/ctrl F … too much “support”)

Support, unless a possible workaround is found.

PrincessPanda_test_ wrote:

Support, unless a possible workaround is found.

^^^

PrincessPanda_test_ wrote:

Support, unless a possible workaround is found.

Changing stance to this…

…but semi-support, there are workarounds, though

Zekrom01 wrote:

PrincessPanda_test_ wrote:

Support, unless a possible workaround is found.

Changing stance to this…

…but semi-support, there are workarounds, though

I said there are probably no direct workarounds to the block itself. But I may find a workaround for the game! But I would still like the block. It's helpful for people like me.

JoeyTheChicken wrote:

alexphan wrote:

JoeyTheChicken wrote:

Oh! Oh! *Raises hand* I forgot! You can still color sense a sprite even if it's ghosted! So you can set the ground sprite to a ghost of 100 and you'll still sense it! Works for regular “touching?” too!

And?

And that (Hopefully) will solve the problem the First Poster is having!

Well… it still presents the problem of the need of that block. Because I have two different sprites that each display sensing stuff. Might still help, though. I did just think of something… as I was thinking up how the game could work, I thought that perhaps both players could have one-fourth of the screen when they split up, so as not to use distortion (which is technically impossible, unless of course you use pen or manually distort the levels in the costume editor…) or cut out parts of the level. The game isn't a scrolling, so I should have no problems with having a split-screen. But then there's those extra 2/4 of the screen. And then I thought, "Wait, two-fourths of the screen. If I used ghosting and made sure they were completely hid… I could use those for sensing! Why did I not think of this? Well, I just did, so…" But this would still be a helpful block in the future. So thanks all who support!

MathlyCat wrote:

So after painfully reading all the posts. I've gotten two things:

1. Lot's of people can't support their own reason to not support (Weird right?)

2. Apparently it's “hard to code” which in fact IS NOT.

So, not trying to sound like an arrogant idiot, (No offense ) but honestly a lot of people here are making points they have no proof for which leads me to the belief they're trying to hate on the OP. In the long term it's rude; unless you give a good reason.

So truly, I support it as per the people who can support their ideas on supporting.

(cmd/ctrl F … too much “support”)

Coding is hard. Maybe you haven't done a lot of coding yet, or at least not serious coding, and that's okay. But rest assured, the “serious” stuff – fast code, 3D games, operating systems, compilers, distributed stuff, AI, computer vision, etc. — is hard. As it turns out, even text editors can get out-of-control!

Actually.. scratch that (no pun intended). Coding is somewhat hard. Debugging is hard, and that makes coding hard by extension. It's also what OP is struggling with… hence my gentle (or not so gentle) reminder that this is the life of a programmer.

“Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.”
- Brian Kernighan

hahasamian wrote:

Interkey wrote:

1004587 wrote:

alexphan wrote:

1004587 wrote:

No support; easy workaround,

<<touching [sprite v] ?> and <touching color [#ff0088] ? >>

But what if the color doesn't belong to that sprite? What if you're touching one sprite, but the target color is from a different one?

I suppose this could work, other than the fact that the color could belong to the background. I would try:

switch backdrop to [blank v]

before trying the other script and afterwards,

switch backdrop to [other background v]

.

This will filter the background colors, too, but sadly, there is no way to filter colors without doing this.

The problem is that it constantly blinks when I did something similar: I made it hide. I should expect that a blank costume wouldn't help? So that is why I'm asking for this block. It's the best workaround for the glitched code.
*sighs*

If you put that test in a run without screen refresh custom block, it shouldn't flash.
Semi-support. It's hard to work around, but doesn't seem like it would be useful for most people.

Anyway, for a challenge, maybe try a MVC (model-view-controller) approach, which is what is used in The Real World*

The idea is that you split your program into 3 parts. You can guess their names.

1) Model
This part of your program is responsible for handling all of the data in your program. Everything from a sprite's position and rotation to its velocity to its health is handled here. The caveat is that to set any of these values from anywhere in your code, you have to route it through the model first. (Best handled by a custom block in Scratch). The setter needs to verify the value, set it if it's okay, possibly do some trivial logic to keep the program in sync (like updating the speed and direction values when velocity is changed, maybe), and finally emits an event* to the view and controller that something changed looks. It might look like this:

define set x to (x)
set [_x v] to [(x) ]
broadcast [x position changed v]

2) View
This part of your program handles all of the user-facing code. That is, it handles the display, the keyboard, the mouse, the sounds, etc. It must *only* fire events to the model/controller or respond to events from the model. Try not to put any logic (except for view logic) here.

when I receive [x position changed v]
set x to (_x)

when [left v] key pressed
broadcast [go left v]

3) Controller
This is the meat of your program. It listens to events from the model (and view maybe), decides what to do with it, does some computation probably, and then sends back some updated information through the model. All logic should go here, and it should not touch any of the data or the screen stuff.

when I receive [go left v]
set x to ((_x) - (10)) :: custom

I think you'll find if you building your game like this, problems like collision detection become much simpler. (Hint: compare positions and sizes to other sprites when there is something happening in the controller.)

* Or so it is said. I'm more of an academic myself…
* This is more Real World lingo. Broadcasts are probably the closest Scratch-ism to this.

bobbybee wrote:

Anyway, for a challenge, maybe try a MVC (model-view-controller) approach, which is what is used in The Real World*

The idea is that you split your program into 3 parts. You can guess their names.

1) Model
This part of your program is responsible for handling all of the data in your program. Everything from a sprite's position and rotation to its velocity to its health is handled here. The caveat is that to set any of these values from anywhere in your code, you have to route it through the model first. (Best handled by a custom block in Scratch). The setter needs to verify the value, set it if it's okay, possibly do some trivial logic to keep the program in sync (like updating the speed and direction values when velocity is changed, maybe), and finally emits an event* to the view and controller that something changed looks. It might look like this:

define set x to (x)
set [_x v] to [(x) ]
broadcast [x position changed v]

2) View
This part of your program handles all of the user-facing code. That is, it handles the display, the keyboard, the mouse, the sounds, etc. It must *only* fire events to the model/controller or respond to events from the model. Try not to put any logic (except for view logic) here.

when I receive [x position changed v]
set x to (_x)

when [left v] key pressed
broadcast [go left v]

3) Controller
This is the meat of your program. It listens to events from the model (and view maybe), decides what to do with it, does some computation probably, and then sends back some updated information through the model. All logic should go here, and it should not touch any of the data or the screen stuff.

when I receive [go left v]
set x to ((_x) - (10)) :: custom

I think you'll find if you building your game like this, problems like collision detection become much simpler. (Hint: compare positions and sizes to other sprites when there is something happening in the controller.)

* Or so it is said. I'm more of an academic myself…
* This is more Real World lingo. Broadcasts are probably the closest Scratch-ism to this.

Okay. Might try that. I kinda get the idea of what you're saying, the blocks help a lot, but you might lose more, well, inexperienced Scratchers. Just saying. It's a very good idea, though. I didn't even notice the use of that check-box on the custom block maker! Thanks for bringing that up, @BookOwl !
Can't wait to try and release this game!

No support

MClovers wrote:

No support

Please don't just state you don't support if you're not going to give any reason why.

No support - If you absolutely positutely need this block, and ((touching sprite) and (touching color)) doesn't work for you… code your game differently.

Maybe you should use invisible sensor sprites instead, or make the 2 sprites have colors which are almost, but not quite, the same color! Treat this as a learning experience, and not something missing from Scratch. How can you work around this problem?

Scratch is about learning programming, and it's not a set of “do this” and “do that” tools (like Sploder). In quote-unquote “real” programming, we don't get to request features because we don't want to program them ourselves.

hahasamian wrote:

bobbybee wrote:

Anyway, for a challenge, maybe try a MVC (model-view-controller) approach, which is what is used in The Real World*

The idea is that you split your program into 3 parts. You can guess their names.

1) Model
This part of your program is responsible for handling all of the data in your program. Everything from a sprite's position and rotation to its velocity to its health is handled here. The caveat is that to set any of these values from anywhere in your code, you have to route it through the model first. (Best handled by a custom block in Scratch). The setter needs to verify the value, set it if it's okay, possibly do some trivial logic to keep the program in sync (like updating the speed and direction values when velocity is changed, maybe), and finally emits an event* to the view and controller that something changed looks. It might look like this:

define set x to (x)
set [_x v] to [(x) ]
broadcast [x position changed v]

2) View
This part of your program handles all of the user-facing code. That is, it handles the display, the keyboard, the mouse, the sounds, etc. It must *only* fire events to the model/controller or respond to events from the model. Try not to put any logic (except for view logic) here.

when I receive [x position changed v]
set x to (_x)

when [left v] key pressed
broadcast [go left v]

3) Controller
This is the meat of your program. It listens to events from the model (and view maybe), decides what to do with it, does some computation probably, and then sends back some updated information through the model. All logic should go here, and it should not touch any of the data or the screen stuff.

when I receive [go left v]
set x to ((_x) - (10)) :: custom

I think you'll find if you building your game like this, problems like collision detection become much simpler. (Hint: compare positions and sizes to other sprites when there is something happening in the controller.)

* Or so it is said. I'm more of an academic myself…
* This is more Real World lingo. Broadcasts are probably the closest Scratch-ism to this.

Okay. Might try that. I kinda get the idea of what you're saying, the blocks help a lot, but you might lose more, well, inexperienced Scratchers. Just saying. It's a very good idea, though. I didn't even notice the use of that check-box on the custom block maker! Thanks for bringing that up, @BookOwl !
Can't wait to try and release this game!

Problem, I just tried something which used my already-made system, and it lags, REALLY BAD. I think it may be a time I need more modification to the system!

hahasamian wrote:

hahasamian wrote:

bobbybee wrote:

Anyway, for a challenge, maybe try a MVC (model-view-controller) approach, which is what is used in The Real World*

The idea is that you split your program into 3 parts. You can guess their names.

1) Model
This part of your program is responsible for handling all of the data in your program. Everything from a sprite's position and rotation to its velocity to its health is handled here. The caveat is that to set any of these values from anywhere in your code, you have to route it through the model first. (Best handled by a custom block in Scratch). The setter needs to verify the value, set it if it's okay, possibly do some trivial logic to keep the program in sync (like updating the speed and direction values when velocity is changed, maybe), and finally emits an event* to the view and controller that something changed looks. It might look like this:

define set x to (x)
set [_x v] to [(x) ]
broadcast [x position changed v]

2) View
This part of your program handles all of the user-facing code. That is, it handles the display, the keyboard, the mouse, the sounds, etc. It must *only* fire events to the model/controller or respond to events from the model. Try not to put any logic (except for view logic) here.

when I receive [x position changed v]
set x to (_x)

when [left v] key pressed
broadcast [go left v]

3) Controller
This is the meat of your program. It listens to events from the model (and view maybe), decides what to do with it, does some computation probably, and then sends back some updated information through the model. All logic should go here, and it should not touch any of the data or the screen stuff.

when I receive [go left v]
set x to ((_x) - (10)) :: custom

I think you'll find if you building your game like this, problems like collision detection become much simpler. (Hint: compare positions and sizes to other sprites when there is something happening in the controller.)

* Or so it is said. I'm more of an academic myself…
* This is more Real World lingo. Broadcasts are probably the closest Scratch-ism to this.

Okay. Might try that. I kinda get the idea of what you're saying, the blocks help a lot, but you might lose more, well, inexperienced Scratchers. Just saying. It's a very good idea, though. I didn't even notice the use of that check-box on the custom block maker! Thanks for bringing that up, @BookOwl !
Can't wait to try and release this game!

Problem, I just tried something which used my already-made system, and it lags, REALLY BAD. I think it may be a time I need more modification to the system!

I haven't tried implementing MVC in Scratch. It wouldn't surprise me – MVC by its very nature has quite a bit of overhead. There's probably a better way to implement it than broadcasts. Maybe try custom blocks for event handlers that are called directly, with all blocks set to atomic (“Run without screen refresh”). I'm not positive that is the correct behavior, though.

bobbybee wrote:

hahasamian wrote:

hahasamian wrote:

bobbybee wrote:

Anyway, for a challenge, maybe try a MVC (model-view-controller) approach, which is what is used in The Real World*

The idea is that you split your program into 3 parts. You can guess their names.

1) Model
This part of your program is responsible for handling all of the data in your program. Everything from a sprite's position and rotation to its velocity to its health is handled here. The caveat is that to set any of these values from anywhere in your code, you have to route it through the model first. (Best handled by a custom block in Scratch). The setter needs to verify the value, set it if it's okay, possibly do some trivial logic to keep the program in sync (like updating the speed and direction values when velocity is changed, maybe), and finally emits an event* to the view and controller that something changed looks. It might look like this:

define set x to (x)
set [_x v] to [(x) ]
broadcast [x position changed v]

2) View
This part of your program handles all of the user-facing code. That is, it handles the display, the keyboard, the mouse, the sounds, etc. It must *only* fire events to the model/controller or respond to events from the model. Try not to put any logic (except for view logic) here.

when I receive [x position changed v]
set x to (_x)

when [left v] key pressed
broadcast [go left v]

3) Controller
This is the meat of your program. It listens to events from the model (and view maybe), decides what to do with it, does some computation probably, and then sends back some updated information through the model. All logic should go here, and it should not touch any of the data or the screen stuff.

when I receive [go left v]
set x to ((_x) - (10)) :: custom

I think you'll find if you building your game like this, problems like collision detection become much simpler. (Hint: compare positions and sizes to other sprites when there is something happening in the controller.)

* Or so it is said. I'm more of an academic myself…
* This is more Real World lingo. Broadcasts are probably the closest Scratch-ism to this.

Okay. Might try that. I kinda get the idea of what you're saying, the blocks help a lot, but you might lose more, well, inexperienced Scratchers. Just saying. It's a very good idea, though. I didn't even notice the use of that check-box on the custom block maker! Thanks for bringing that up, @BookOwl !
Can't wait to try and release this game!

Problem, I just tried something which used my already-made system, and it lags, REALLY BAD. I think it may be a time I need more modification to the system!

I haven't tried implementing MVC in Scratch. It wouldn't surprise me – MVC by its very nature has quite a bit of overhead. There's probably a better way to implement it than broadcasts. Maybe try custom blocks for event handlers that are called directly, with all blocks set to atomic (“Run without screen refresh”). I'm not positive that is the correct behavior, though.

I think that I might just use my other idea. You may have read it. 1/4 of the screen is a screen display for each player, while the extra 2/4 are actually used for sensing and are hidden with ghost. That will probably work well, but it will cut down screen size.

hahasamian wrote:

I think that I might just use my other idea. You may have read it. 1/4 of the screen is a screen display for each player, while the extra 2/4 are actually used for sensing and are hidden with ghost. That will probably work well, but it will cut down screen size.

Why split them up?

If the sprites are made invisible with the ghost effect, you can put them wherever you want on the screen, because they will be… invisible! You could even put them directly on top of the game window itself.