i currently have a long list of conditionals such as "if costume = " etc and im planning to add a bunch of upgrades, so i do not want to suffer through adding that many conditionals, any way to make a system/script for this?

go to this project and go to the 'buffs" sprite, scroll down, and you would see what im asking for

With a big variety of upgrades, I think a lot of conditionals is probably the way to go. Here's an example: https://scratch.mit.edu/projects/1040219984/

Jlerpy wrote:

With a big variety of upgrades, I think a lot of conditionals is probably the way to go. Here's an example: https://scratch.mit.edu/projects/1040219984/

thats the easiest solution i can come up with… only issue is that im adding more than 20… (with base inspiration from TBOI)

bump

Why the bump? Do you have a followup question?

Jlerpy wrote:

Why the bump? Do you have a followup question?

i was hoping that someone had a better solution to this since im not sure if adding lets say 25+ "if varible = " would start lagging the project

I wouldn't think checking the variable would take long, but another path that's worth a try is to get it to broadcast its costume name and instead of a strong of IFs, have a cloud of “when I receive” blocks that can operate in parallel

squelz wrote:

im not sure if adding lets say 25+ "if varible = " would start lagging the project

It will not. Modifying the script so you can add “stop this script” in every if statement may prevent the nonexistent lag even further. As such, the solution I have written below is mostly for cleanly handling a large amount of upgrades; i have not compared its performance.

If you intend to have many upgrades you can reformat your code to avoid the if statements. However, the information for the upgrades has to go somewhere, so it will be stored in lists.

For a simple example, let's say you have a bullet that does 10 damage. Upgrade A doubles the damage, and Upgrade B adds 6 damage on top of that. This can be scripted in the following way:

set [Upgrade A bonus v] to [2]
set [Upgrade B bonus v] to [6]
set [bullet damage v] to (((base damage) * (Upgrade A bonus)) + (Upgrade B bonus))

The issue with this is that for each upgrade, you would need if statements to determine which variable to modify. To fix this, the upgrade bonuses have to be in a list so you can choose one without an if statement:

replace item (1 v) of [bonuses v] with [2]
replace item (2 v) of [bonuses v] with [6]
set [bullet damage v] to (((base damage) * (item (1 v) of [bonuses v] :: list)) + (item (2 v) of [bonuses v] :: list))

From here we implement the process of getting the upgrade. Since we don't initially have the upgrades, we should set the bonuses to default values:

replace item (1 v) of [bonuses v] with [1]
replace item (2 v) of [bonuses v] with [0]

Each upgrade will come with two pieces of info: Which index they change in the bonuses list, and what value they change it to. This can be stored in a list like this:

1. Upgrade A
   
2. 1
   
3. 2
   
4. Upgrade B
   
5. 2
   
6. 6
   

And from there there's a few ways to find the correct index in this list to get the upgrade stats, including math or using a third list. This method for implementing upgrades can be expanded for more flexible use cases.

DEMO

Jlerpy wrote:

another path that's worth a try is to get it to broadcast its costume name and instead of a strong of IFs, have a cloud of “when I receive” blocks that can operate in parallel

This would be visually messy and make it unclear at what point they run in the script order. Is there a significant difference in speed?

g6g6g66g6g wrote:

This would be visually messy and make it unclear at what point they run in the script order. Is there a significant difference in speed?

I actually have no idea how it compares in processing speed, but in human comprehension, it means you can spread them out and look at them separately, which can be helpful for understanding what each one does.

so just use a list instead of a bunch of variables and make them set to an item forever? kay

g6g6g66g6g wrote:

squelz wrote:

im not sure if adding lets say 25+ "if varible = " would start lagging the project

It will not. Modifying the script so you can add “stop this script” in every if statement may prevent the nonexistent lag even further. As such, the solution I have written below is mostly for cleanly handling a large amount of upgrades; i have not compared its performance.

If you intend to have many upgrades you can reformat your code to avoid the if statements. However, the information for the upgrades has to go somewhere, so it will be stored in lists.

For a simple example, let's say you have a bullet that does 10 damage. Upgrade A doubles the damage, and Upgrade B adds 6 damage on top of that. This can be scripted in the following way:

set [Upgrade A bonus v] to [2]
set [Upgrade B bonus v] to [6]
set [bullet damage v] to (((base damage) * (Upgrade A bonus)) + (Upgrade B bonus))

The issue with this is that for each upgrade, you would need if statements to determine which variable to modify. To fix this, the upgrade bonuses have to be in a list so you can choose one without an if statement:

replace item (1 v) of [bonuses v] with [2]
replace item (2 v) of [bonuses v] with [6]
set [bullet damage v] to (((base damage) * (item (1 v) of [bonuses v] :: list)) + (item (2 v) of [bonuses v] :: list))

From here we implement the process of getting the upgrade. Since we don't initially have the upgrades, we should set the bonuses to default values:

replace item (1 v) of [bonuses v] with [1]
replace item (2 v) of [bonuses v] with [0]

Each upgrade will come with two pieces of info: Which index they change in the bonuses list, and what value they change it to. This can be stored in a list like this:

1. Upgrade A
   
2. 1
   
3. 2
   
4. Upgrade B
   
5. 2
   
6. 6
   

And from there there's a few ways to find the correct index in this list to get the upgrade stats, including math or using a third list. This method for implementing upgrades can be expanded for more flexible use cases.

DEMO

Jlerpy wrote:

another path that's worth a try is to get it to broadcast its costume name and instead of a strong of IFs, have a cloud of “when I receive” blocks that can operate in parallel

This would be visually messy and make it unclear at what point they run in the script order. Is there a significant difference in speed?

wait i still want a way to not use that many “if” statements

What exactly are you asking for that you feel hasn't been resolved?

i- nevermind forget about it