Make it rain

[VegeTato]

this extension is useful to make rain weather or just the rain effect on any object, also can help in colliding the rain with another object, it will add the life feeling to any kind of game

You can test the extension here: https://games.gdevelop-app.com/game-1af8241b-004d-4bae-bff0-f65600adefb4/index.html

Version 0.1

-User can select the object to rain -User can select to rain object from a selected direction -User can set condition to check if the rain object collides with another object -User can set action to Stop/Start the rain object -User can select object2 to rain object from it on a selected direction -User can set an action to stop rain object from moving

Version 0.2

-User have the option to select the rain direction from a list (Down/Up/Right/Left) -Fixed a bug where stopping the rain action and resuming it would drop a rain out of range

Version 0.3

-User can set the rain intensity -Updated the example to more realistic rain effect when colliding with player

Version 0.4

-Added the ability to change the rain angle -Added the ability to change the rain animation after the collision and in the same condition Added the options to check Yes or No: •Change rain object position to object surface? •Remove rain object after it finish the animation? •Remove rain object if it collides with the edges of the object? •Stop rain object after collision with other object? -Added an option to check Yes/No to delete the rain objects if its out of screen -Fixed variables names -Updated the example

Version 0.5

-Fixed a bug in the Start/Stop rain actions -Fixed few mistakes in the example -Fixed few wrong sentences in the extension -Added condition to restart scene if player is out of screen in the example -Changed the parameter sentences -Added few long descriptions -Updated the example for the latest updates of the extension and changed the sprites as well for the best

Checklist

• [X] Extension has a proper name and description.
• [X] Extension has tags (for example: "platform, brick, breakable").
• [X] All behaviors have a description.
• [X] All functions (actions, conditions, expressions) have descriptions and proper sentences.
• [X] I've followed the best practices listed on http://wiki.compilgames.net/doku.php/gdevelop5/extensions/best-practices
• [X] I confirm that this extension can be intergrated to this GitHub repository, distributed and MIT licensed.

You can download the example here: https://trello.com/1/cards/60e4c20416f51889fe955282/attachments/6146486ffe1a848f2fda9e82/download/Make_it_rain_extension_example_V0.0.5.rar

You can download the extension here: https://trello.com/1/cards/60e4c20416f51889fe955282/attachments/6146487777ccd32de5ac0d3d/download/Make_it_rain_extension_V0.0.5.rar

[arthuro555]

I am not sure how useful this extension actually is. When we look at what it actually does at its core, it is just a repeat event with create object and add permanant force, and some wrappers for other actions/conditions with different names. Stuff that looks attracting to the user like the splashing effect has to be done manually in the project, and this puts pretty simple instructions (create objects, forces, collisions) in a black box for pretty much no gain. I think it would be good as an example, but offers little value as an extension.

[VegeTato]

i disagree honestly, creating an object in random range which is the screen width/height(for directions) and colliding it and give it ability to set what happens when it collides with other objects and changing at what direction/gravity its done also picking from what the object(rains) will come out from, and setting the speed of the rain yet the intensity of the object, and the ability to stop or start the rain, and don't forget the math behind it to delete the objects when they are out of the screen, and random the object in the screen width or height, all of this will take so much time and effort to make for only ONE object, and that's why the extensions exist, to make things much easier for the users and to save time to focus on the game core more than the backgrounds and the game feel, i didn't add the splash in the extension core because i wanted to give the users the ability to pick what happens when the object collides with other objects, rather than forcing them to make splash, (what if the floor is lava, the rain shouldn't make splash it should make smoke effect, what if the colliding object is wet, it should make a splash either, there are many possibilities of what the user can do, so its better to stay open to user (though we already discussed this in discord at WIP if you want to get back there and there i explained the same idea here). i know this could be easy to make form your side but you should think from the community side not yours. again that's why the extensions are for, to make the complicated things easier and to save time on the user, not to think if you can make it or not. all the extensions in GDevelop can be remade by anyone, its just about time to get it right, but nobody would like to put a lot of efforts to gain 1 project, while you can make it extension and make it happens anytime you want in a seconds.

[arthuro555]

I'm not saying the reason I rejected it is because I think I could do it myself in events, I understood why you would see value in it and I originally spent days (weeks?) reviewing it before coming to this conclusion. After removing code duplication, adding an angle parameter instead of limiting to 4 directions, simplifying and optimizing the events, the end code was pretty those events:

Repeat (intensity) times:
    Create object at RandomInRange((x1), (x2));RandomInRange((y1), (y2))
    Add permanent force of speed (speed) and angle of (angle)

And two wrapper functions that were calling it with scene or object boundaries coordinates. So it really isn't sparing as much work as it originally looked.

But fine, someone might not know how to use those. In that case though, an extension is not a solution, creating objects and forces are the most basic building blocks of events. If you are not able to come up with them by yourself, it is not a problem of complexity but a problem of education, that user would actually need to learn the basics of GDevelop, else they would not be able to achieve anything! Extensions are meant to simplify harder tasks by abstracting them, not to simplify any given task that could be solved with basic knowledge of GDevelop.

If we look at the list of features:

• creating an object in random range which is the screen width/height: Creating objects is a basic of GDevelop, and the expression builder should allow you to find expressions for randomness and scene/object height/width in seconds
• colliding it: your extensions does not add any value here, it is wrapping the built in action.
• give it ability to set what happens when it collides with other objects: no difference with the point before, and is still an engine feature. Your extension does not add anything in this regard.
• changing at what direction/gravity its done: Maybe it'll require some thinking for beginners to get the changing to work via a variable, but in the end your extension does nothing in this regard: in the end they have to pass the new direction to your action, where they would have to do the exact same with a force action.
• also picking from what the object(rains) will come out from: Like I said in the first point, should not be a problem using the expression builder.
• setting the speed of the rain: just like the direction, there is no difference between passing a speed to your action vs passing it directly to a force action
• the intensity of the object: Using a repeat event is easier and more flexible
• the ability to stop or start the rain: There are actions to stop and add forces.
• don't forget the math behind it to delete the objects when they are out of the screen: There is a built in behavior for deleting put of screen objects already.

My other point is that this extension is too specific and thereby inflexible. If a user wants to do rain and chose to use use your extension, if they want to change it later to fit their needs more, they will be stuck because an extension is like a black box: most users won't know that they can easily modify and look at the events. If they do it themselves, which in that case does not take that much work as most tools are provided by GDevelop by default, users will be able to tweak their game to be exactly how they want. It's kind of your logic of

i didn't add the splash in the extension core because i wanted to give the users the ability to pick what happens when the object collides with other objects, rather than forcing them to make splash

But extended further to the whole extension. The extension does nothing, no additional work in particular appart hiding how it works, except maybe for getting the object/scene boundaries. And i don't think encouraging users to be lazy and get stuck with an inflexible solution is a good idea.

If instead this was an example, this would be fine, as it would explain to the user those basics concepts and how they combine into something new, letting them learn how to use GDevelop, tweak it to their liking and understand their own code.

[4ian]

Hey @VegeTato thanks for submitting this :) It looks much better than the existing rain example (https://editor.gdevelop-app.com/?project=https://resources.gdevelop-app.com/examples/rain/rain.json) What do you think all of using this to improve/replace the example? 😀

As arthuro55 said maybe this could be better as an example than an extension. This would allow to showcase the very nice "splash" effect (we would be moving the actions outside of the extension, and keep just a scene with events, and maybe the behaviors to delete objects outside of the scene).

Sorry I know this is some rework but that would allow to do a clean example that would be very useful :) Let me know what you think!

[VegeTato]

hello, i still do think its better to be an extension not an example because the splash is just an animation and not that hard to be done, rain collide with object > stop rain movement > change rain animation to splash > when splash animation finished > delete rain.

while if this was an extension, user only need to provide the rain object, the direction, the speed, the intensity, the layer.

if you guys want to make it an example well go ahead no problem, but honestly i will still use it as an extension, its most useful that way, even the community loved the extension idea when i post it at WIP.

at less its useful to me, am going to upgrade it as well to add the float effect to the rain objects and to rain down in a zigzag way, in case the user want to make snow not rain effect, and also can be made to make air splash using the float and the direction from right and changing the air animation to air splash when it collides with another object. so this can be named as the elements extension maybe rather than "make it rain" since its not about rain only.

same thing goes to thunder effect am also going to upgrade the extension to make the thunder hit in a realistic way with lighting effects which is going to be included with the extension.

ill upgrade it and rename it to "Elements extension" ,if someone asked for it ill just send the extension to them since you guys don't like my extension idea and rejected it thinking its basics to make, well others do think its useful.

[arthuro555]

Just to be clear, I do not reject the idea or rain in games or anything like that. I am only saying that this version you have submitted doesn't in my opinion fit being an extension as just like "the splash is just an animation and not that hard to be done", i think that "the new droplets is just creating objects and not that hard to be done" and that "moving objects is just a force and not that hard to be done", and just like with the splash animation, by not letting the user do it by themselves they are losing flexibility. I think an example is more adapted as the user does not have to search how to do rain just like you said, and also do not lose flexibility.

Generally, I think extensions should not be just any code snippet, but either abstract a complex/specific task or concept by providing a new way to think and interact with it, or do a task that cannot be subject to interpretation.

For example, the console extension adds an abstraction: it hides the parsing and input handling away from the user, and gives them a new way to think about the inputted text: commands and arguments. Another example, a create a grid of objects extension. This cannot be subject to interpretation, as a grid and object creation are clearly defined terminology, whoever makes such an extension will always make one that yields the same result. Therefore, it is indeed useful to reduce it to a single action instead of doing it by hand each time.

In this case, rain is not providing a new abstraction, as it just combines a few built in actions into a single one, and it is subject to interpretation as people can imagine rain as many different things or have it behave in different ways depending on the game and situation.

The way I see it, there are two possible ways to go forward:

1. Make this an example, so that you can show your way of doing rain to other, which allows them to copy it if it just so happens to be exactly what they need, while being able to tweak it easily later on if their needs changes, and allowing people who have another subjective view of rain in video games to inspire themselves but still do their own thing.
2. Keep it an extension, but work on it further, and make it a real abstraction. If for example you hide away the collision handling and splash animation and add new unique ways of interacting with the rain, I think it might bring more value and outperform the downside of the black boxing caused by packing actions in extensions.

Then again this is my opinion, maybe the other reviewers think if it otherwise. Again, I have sent days/weeks reviewing your extension and am not saying it has no value. I appreciate your work (and I think so does everyone else), but I think that extension is not quite useful enough yet, and could become something great by doing a bit more work for the user.

[tristanbob]

I just spent a few hours reviewing this extension and I can understand both of your points. @arthuro wants extensions that make complex tasks simple for users but without including extensions that simply hide the normal way things are done. For instance, I'm not sure what value the "RainInteraction" function adds since it simply does a collision check. That function should probably be removed if more functionality is not added. (BTW, thank you @arthuro for taking the time to review this. Your time and skills are very valuable and we appreciate it!)

However, I also see things from the perspective of @VegeTato. Beginning GDevelop users will need to spend a LOT of time to learn how to make a rain effect like this. Intermediate and advanced GDevelop users could make this effect themselves, but they might still appreciate that they can make it work with a couple of clicks (including me).

From a high level, I think we should error towards encouraging our extension creators. When I first starting making extensions, I barely knew what I was doing. Somehow I managed to successfully make several very simple extensions (don't look at the "Flash layer" extension). However, each time I made an extension I learned something new, and would I use that knowledge in my next extension. In many cases, I have gone back and improved the original version of the extension based on my new skills.

In summary, let's keep this extension open and continue to provide guidance for @Vegetato. My first recommendation is to replace your "intensity" logic with a repeated event (see below):

My second idea is a very small change that provides a more realistic rain effect. When the rain collides with the player, make it move up to the top of the player's sprite. This allows the player to jump up and the rain moves with it (see video).

https://user-images.githubusercontent.com/8879811/130388430-507d1ba5-c2fa-4491-8f24-0bc442e2cd07.mp4

[VegeTato]

I just spent a few hours reviewing this extension and I can understand both of your points. @arthuro wants extensions that make complex tasks simple for users but without including extensions that simply hide the normal way things are done. For instance, I'm not sure what value the "RainInteraction" function adds since it simply does a collision check. That function should probably be removed if more functionality is not added. (BTW, thank you @arthuro for taking the time to review this. Your time and skills are very valuable and we appreciate it!)

However, I also see things from the perspective of @VegeTato. Beginning GDevelop users will need to spend a LOT of time to learn how to make a rain effect like this. Intermediate and advanced GDevelop users could make this effect themselves, but they might still appreciate that they can make it work with a couple of clicks (including me).

From a high level, I think we should error towards encouraging our extension creators. When I first starting making extensions, I barely knew what I was doing. Somehow I managed to successfully make several very simple extensions (don't look at the "Flash layer" extension). However, each time I made an extension I learned something new, and would I use that knowledge in my next extension. In many cases, I have gone back and improved the original version of the extension based on my new skills.

In summary, let's keep this extension open and continue to provide guidance for @VegeTato. My first recommendation is to replace your "intensity" logic with a repeated event (see below):

My second idea is a very small change that provides a more realistic rain effect. When the rain collides with the player, make it move up to the top of the player's sprite. This allows the player to jump up and the rain moves with it (see video).

gmf9d2rdH2.mp4

Hello, thanks for the reviews :3 i updated the extension based on the review:

-changed the intensity to a repeat event (i didn't know this is possible before <.> because when you write Get in other events it automatically tells you "GetArgumentAsNumber" but in the repeat event whatever you type, nothing shows up, so i thought it wont work in extensions)

-updated the example to make the rain more realistic (as suggested in the second idea) but i also deleted the (stop rain) from the event when rain collide with the player, to make the rain even more realistic.

[tristanbob]

Let start with the small things:

• Your variable names have odd formats. Instead of "_.MakeItRain._Remove rain", try using "__MakeItRain.RemoveRain".
  • No spaces in variable names
  • Start with double underscore "__"
  • Use a single "." to separate the extension name from the variables
  • Use CamelCase PascalCase capitalization for variable names
  • Follow these guidelines for all of the variables in this extension
• Why do you have the user pick a name for the object timers? A static object timer name should work and be simpler for the user
• Add more text comments, it helps others understand your code

Now for some bigger concepts:

• Try adding the collision logic into the extension (this is something Arthuro mentioned)
• Always test if you can make your events work without ForEach(). This is a recommendation by Florian to maximize performance. It it doesn't work, you then you can use ForEach().
• Try not to repeat code if you can help it. For instance, your "MakeItRain" function has a section for each direction (up,down,left,right). However, some of those sections are the same. If you ever want to change something, you would have to change it for each direction. Instead, try placing the code that is shared by all directions first, and then add the subevents for each direction.
• Combine your "is on screen" checks into a single event to check if rain needs to be deleted (using "OR" conditions). Once extension dependencies are added, you can use the "Delete if offscreen" extension instead of this.
• Do you want to add more weather functions to this extension? I am looking forward to your work. That could be split into multiple extensions, if it makes more sense.

That's all I have for tonight. Keep up the great work @VegeTato!

[arthuro555]

Combine your "is on-screen" checks into a single event to check if rain needs to be deleted (using "OR" conditions). Once extension dependencies are added, you can use the "Delete if offscreen" extension instead of this.

Personally, I would just leave it to the users of the extension to add the delete offscreen objects behavior by themselves, since it is out of scope for "making it rain". You can add a warning/recommendation in the extension description about using it though.

Try not to repeat code if you can help it. For instance, your "MakeItRain" function has a section for each direction (up,down,left,right). However, some of those sections are the same. If you ever want to change something, you would have to change it for each direction. Instead, try placing the code that is shared by all directions first, and then add the subevents for each direction.

To elaborate on this, you could also make for example a private function that takes in an angle and uses that, and then make your main function compare the direction parameters and call the private function with the correct angle (though generally, I would just trash away those directions in favor of letting users specify the angle, though that's a subjective point of view).

Use CamelCase capitalization for variable names

I think you meant PascalCase ;)

[tristanbob]

Personally, I would just leave it to the users of the extension to add the delete offscreen objects behavior by themselves, since it is out of scope for "making it rain". You can add a warning/recommendation in the extension description about using it though.

For an extension that makes thousands of sprites per minute, this is critical to be part of the extension. Many devs will not understand what is happening when their game gets slow and crashes after a few minutes of playing. Also, if the rain is created off-screen, the standard "delete if off-screen" extension won't work.

After thinking about this some more, the easiest thing to do is check the distance from the center of the screen [CameraX(), CameraY()]. This way it will work for all directions of rain. The distance can be something like (2 * max(SceneWindowWidth(),SceneWindowHeight)). It is not critical that it gets deleted at exactly the right location.

To elaborate on this, you could also make for example a private function that takes in an angle and uses that, and then make your main function compare the direction parameters and call the private function with the correct angle (though generally, I would just trash away those directions in favor of letting users specify the angle, though that's a subjective point of view).

I agree. Try to design a method for users to specify the angle the rain will travel. The hardest part is designing where to create the objects so that they will cross the screen and not have extra rain objects nor a part of the screen without rain. My first idea is to create rain at random locations inside a rectangle that is located off the screen at 180 degrees away from the angle that rain will travel.

I think you meant PascalCase ;)

You are right. :)

[VegeTato]

Let start with the small things:

* Your variable names have odd formats.  Instead of "_.MakeItRain._Remove rain", try using "__MakeItRain.RemoveRain".

  * No spaces in variable names
  * Start with double underscore "__"
  * Use a single "." to separate the extension name from the variables
  * Use ~CamelCase~ **PascalCase** capitalization for variable names
  * Follow these guidelines for all of the variables in this extension

* Why do you have the user pick a name for the object timers?  A static object timer name should work and be simpler for the user

* Add more text comments, it helps others understand your code

Now for some bigger concepts:

* Try adding the collision logic into the extension (this is something Arthuro mentioned)

* Always test if you can make your events work without ForEach().  This is a recommendation by Florian to maximize performance.  It it doesn't work, you then you can use ForEach().

* Try not to repeat code if you can help it.  For instance, your "MakeItRain" function has a section for each direction (up,down,left,right).  However, some of those sections are the same.  If you ever want to change something, you would have to change it for each direction.  Instead, try placing the code that is shared by all directions first, and then add the subevents for each direction.

* Combine your "is on screen" checks into a single event to check if rain needs to be deleted (using "OR" conditions).  Once extension dependencies are added, you can use the "Delete if offscreen" extension instead of this.

* Do you want to add more weather functions to this extension?  I am looking forward to your work.  That could be split into multiple extensions, if it makes more sense.

That's all I have for tonight. Keep up the great work @VegeTato!

Hi :3 i have Updated Make it rain extension to V0.4 based on the recent reviews:

-Added the ability to change the rain angle (BUT i kept the directions in there because the rain spawn position must be picked (from left screen or right or up or down) but now the user can pick the angle of the rain as well for example: (pick rain direction "Down" so its raining from up, and pick angle 90 for straight down or any other value to play with the angle while its raining down). -Fixed the variables names as the review mentioned. -Updated the example to the last extension update. -Changed the rain movements event from: change Object Y position TO add force with angle (that's how i added the angle ability). -Added comments in the extension events.

Try adding the collision logic into the extension (this is something Arthuro mentioned)

-Added the ability to change the rain animation after the collision and in the same condition Added the options to check Yes or No: •Change rain object position to object surface? •Remove rain object after it finish the animation? •Remove rain object if it collides with the edges of the object? •Stop rain object after collision with other object?

Combine your "is on screen" checks into a single event to check if rain needs to be deleted (using "OR" conditions). Once extension dependencies are added, you can use the "Delete if offscreen" extension instead of this.

-Added an option to check Yes/No to delete the rain objects if its out of screen

Why do you have the user pick a name for the object timers? A static object timer name should work and be simpler for the user

i let the user pick the timers names, in case he want to use the extension more than once, otherwise all the (rain objects/make it rain extensions) will interrupt with each other.

Always test if you can make your events work without ForEach(). This is a recommendation by Florian to maximize performance. It it doesn't work, you then you can use ForEach().

not possible, the rain objects will keep spawning and every single rain that spawns should gets own variables (any many times more than 2 rains will spawn in the same time, which need ForEach())

Try not to repeat code if you can help it. For instance, your "MakeItRain" function has a section for each direction (up,down,left,right). However, some of those sections are the same. If you ever want to change something, you would have to change it for each direction. Instead, try placing the code that is shared by all directions first, and then add the sub-events for each direction.

honestly the way you mentioned it makes updating it much harder in the future, its easier this way everything is organized in my events including comments and groups, also its only 4 directions, not a big deal when changes needed.

Do you want to add more weather functions to this extension? I am looking forward to your work. That could be split into multiple extensions, if it makes more sense.

i will make other weathers in another extension, Make it rain is big on its own, i don't want the extension to be a mess.

Note: for a short update news & the download link, refer to the very top of this page to Version 0.4 👍

[Bouh]

I suggest to for the example:

• Move the resources in a folder
• Rename all resources files with camelCase (no space, no dot, no underscore, numbers only for animations)
• Add a restart of the current scene if the player is off-screen.
• Use the external layout for Q and E keys and restart events on all scenes.
• In scene RainDown rename NewObject to Information, and make it global and copy-paste this object on all scenes or use an external layout.
• com.example.gamename -> com.example.makeRain
• Maximum FPS to 0
• All objects like player -> Player, Cloud1 -> Cloud
• What is weeeeeew ? (think to clean unused objects)
• Clean unused resources
• The layout of scene RainDown is excellent and efficient. Reuse this layout for all scenes is welcome!
• Remove all fullscreen events (very annoying in an example in-app to kill the process or Alt+Tab for closing the window.)

For the extension:

• Version number format X.Y.Z not X.Y

• Tags are make, it, rain change to rain, effect, water

• Function MakeItRain: need edit to something like: Use _PARAM1_ as a raining object at a speed of _PARAM2_ and direction _PARAM3_ (respawning in _PARAM4_, timer: _PARAM5_, layer: _PARAM6_, z-order: _PARAM7_, intensity: _PARAM8_, rain angle: _PARAM9_ But here why do you use a direction parameter if you also have a rain angle parameter? For timer we don't know the unit, the value is the second, hours, days? The speed is in mph/h, px/s? Is Angle in radian or degree? Intensity use which type of value? Unit is in parenthesis in the label see:

• Parameter name use PascalCase, then timerspeed -> TimerSpeed

• All Ex and e.g.: like Ex: 0.01 go in the long description parameter.

• All groups & events have to be unfolded, or just fold the parent groups, all children have to be unfolded.

• RainCollide function

All these repeats for each loop can be reduced to one loop with multiple sub-events.

In summarising for variable naming and function naming, we're good. The others thing need to be rewritten fit to the best practices guides:

• Extension Best Practices
• Example Best Practices

[VegeTato]

I suggest to for the example:

* Move the resources in a folder

* Rename all resources files with **camelCase** (no space, no dot, no underscore, numbers only for animations)

* Add a restart of the current scene if the player is off-screen.
  ![image](https://user-images.githubusercontent.com/1670670/133683348-7e1a88a6-3589-4457-a421-c9536d8a6b52.png)

* Use the external layout for Q and E keys and restart events on all scenes.

* In scene **RainDown** rename **NewObject** to **Information**, and make it global and copy-paste this object on all scenes or use an external layout.

* **com.example.gamename** -> **com.example.makeRain**

* Maximum FPS to 0

* All objects like **player** -> **Player**, **Cloud1** -> **Cloud**

* What is **weeeeeew** ? (think to clean unused objects)
  ![image](https://user-images.githubusercontent.com/1670670/133683838-bf1d4cca-4e20-4428-89df-182ad10787f9.png)

* Clean unused resources

* The layout of scene RainDown is excellent and efficient. Reuse this layout for all scenes is welcome!

* Remove all fullscreen events (very annoying in an example in-app to kill the process or Alt+Tab for closing the window.)

For the extension:

* Version number format **X.Y.Z** not **X.Y**

* Tags are **make, it, rain** change to **rain, effect, water**

* Function **MakeItRain**: need edit to something like:
  `Use _PARAM1_ as a raining object at a speed of _PARAM2_ and direction _PARAM3_ (respawning in _PARAM4_, timer: _PARAM5_,  layer: _PARAM6_, z-order: _PARAM7_, intensity: _PARAM8_, rain angle: _PARAM9_ `
  But here why do you use a direction parameter if you also have a rain angle parameter?
  For timer we don't know the unit, the value is the second, hours, days?
  The speed is in mph/h, px/s?
  Is Angle in radian or degree?
  Intensity use which type of value?
  Unit is in parenthesis in the label see:
  ![image](https://user-images.githubusercontent.com/1670670/133685819-fc60fa7f-7a10-4cfc-864b-ce5fc8680fcf.png)

* Parameter name use **PascalCase**, then **timerspeed** -> **TimerSpeed**

All Ex and e.g.: like Ex: 0.01 go in the long description parameter.

* All groups & events have to be unfolded, or just fold the parent groups, all children have to be unfolded.

* **RainCollide** function
  ![image](https://user-images.githubusercontent.com/1670670/133686558-6dff2ddf-16c6-46b7-87a3-48336a9c3066.png)

All these repeats for each loop can be reduced to one loop with multiple sub-events.

In summarising for variable naming and function naming, we're good. The others thing need to be rewritten fit to the best practices guides:

* [Extension Best Practices](http://wiki.compilgames.net/doku.php/gdevelop5/extensions/best-practices)

* [Example Best Practices](http://wiki.compilgames.net/doku.php/gdevelop5/community/guide-for-submitting-an-example)

Updated Make it rain extension to V0.0.5 : -Fixed a bug in the Start/Stop rain actions -Fixed few mistakes in the example -Fixed few wrong sentences in the extension -Added condition to restart scene if player is out of screen in the example -Changed the parameter sentences -Added few long descriptions -Updated the example for the latest updates of the extension and changed the sprites as well for the best

Move the resources in a folder

cant do that, renaming the sprites or moving them into a folder, will break the example (invalid path)

Rename all resources files with camelCase

i renamed the objects for the best, but in the resources folder, i will face the problem invalid path again if i do, so i just changed the names in the editor

Add a restart of the current scene if the player is off-screen.

Added a restart action if the player is off the screen

Use the external layout for Q and E keys and restart events on all scenes. -Use the external layout for Q and E keys and restart events on all scenes. -In scene RainDown rename NewObject to Information, and make it global and copy-paste this object on all scenes or use an -external layout. -com.example.gamename -> com.example.makeRain -Maximum FPS to 0 -The layout of scene RainDown is excellent and efficient. Reuse this layout for all scenes is welcome! -Remove all fullscreen events (very annoying in an example in-app to kill the process or Alt+Tab for closing the window.) -Tags are make, it, rain change to rain, effect, water -Unit is in parenthesis in the label see: -Parameter name use PascalCase, then timerspeed -> TimerSpeed -All Ex and e.g.: like Ex: 0.01 go in the long description parameter. -All groups & events have to be unfolded, or just fold the parent groups, all children have to be unfolded.

Done

All objects like player -> Player, Cloud1 -> Cloud -What is weeeeeew ? (think to clean unused objects) -Clean unused resources

i wasn't planning to upload the example to GDevelop examples, that's why it was a mess of unused objects and random names. Cleared all the unused objects and renamed all the objects for the best

Version number format X.Y.Z not X.Y

i still don't like this version format thing, like i update my extension and increase +1 every time i do that, it looks like nothing now with the numbers 0.0.5 it feels like its gonna take years to finish but its actually finished but its just the version number making it looks stupid and not finished... anyway i changed the version number from 0.5 to 0.0.5 tho i don't like it.

Function MakeItRain: need edit to something like: Use PARAM1 as a raining object at a speed of PARAM2 and direction PARAM3 (respawning in PARAM4, timer: PARAM5, layer: PARAM6, z-order: PARAM7, intensity: PARAM8, rain angle: PARAM9

Done, and also i applied this to Rain down form object function as well just added few words

But here why do you use a direction parameter if you also have a rain angle parameter?

as i mentioned above for Tristan, direction is not the same as angle Direction is there to determine where the rain will spawn from ? (above the screen/below the screen/on the right/on the left)

For timer we don't know the unit, the value is the second, hours, days? The speed is in mph/h, px/s? Is Angle in radian or degree? Intensity use which type of value?

All added in the parameter except the intensity, well... its intensity... there is no value type for it i suppose

All these repeats for each loop can be reduced to one loop with multiple sub-events.

if i understand this right, it will make a mess since each direction has its own events, and combining them into 1 loop with sub events will make things harder i think.

Note: for a short update news & the download link, refer to the very top of this page to Version 0.0.5 👍

[arthuro555]

@VegeTato Do you plan to continue the submission process of that extension or do you wish it to be canceled since you are against other people being allowed to modify your extension?

[VegeTato]

@VegeTato Do you plan to continue the submission process of that extension or do you wish it to be canceled since you are against other people being allowed to modify your extension?

yes continue the process, and that applies to all my already submitted extensions. my other new extensions is not submitted anyway.

[Bouh]

We are closing this thread. You can continue to discuss here and we will reopen the thread when an update to the extension is available.

[VegeTato]

We are closing this thread. You can continue to discuss here and we will reopen the thread when an update to the extension is available.

what are you talking about? this extension is ready for merge and don't require any further update

[Bouh]

what are you talking about? this extension is ready for merge and don't require any further update

Ok sorry, it wasn't clear, please open a new issue with the latest files, the bot will open a new Pull request with your extension.