![[ca]](/mwf/flags/ca.png "Canada")
In the base Clonk Rage weather system, rain spawns from x=random y=0. I've recently been working on a demo for dynamic clouds (currently, clouds aren't placed dynamically due to PlaceObjects() bugging out for placing objects in the sky) . It's made for CR, as I'm really unfamiliar with all the changes to CZ script functions. Bear in mind this is only a beta-demo; it's not meant to be a replacer for the weather system... at least not yet.Further features this weather system could implement would be dynamic storms, acid rain; etc. (already implemented :] )
You can get the latest version of the Cloud system (for Clonk Rage) here:
I hereby license the following file(s) under the ISC License
$ hg clone http://www.bitbucket.org/ringwall/cloud-system/
i did not tested it yet, but i like the idea. i also misliked the position of the rain when it spawns. espacily when there is strong wind and all the raindrops fall to the left. they all stick on the one side of the map, while there is a huge area in the right, direct to the scenario-end, where no rain falls. same (and even worse) with snow. dynamic clouds would be a good idea, but they should be activated for each scenario individualy. if this will not be implemented, i hope at least the thing with the area is going to be changes. if something unclear with this, i could screenshot it..
mfg mimmo
I've recently been making many changes and improvements to the current cloud demo. In the old demo you can download from my last post, there are many bugs... I don't remember which were fixed before or after I uploaded it though.Some features I've recently made are:
*Looping clouds- clouds will act like world is "round" if they reach edge of map
and
*Storm Clouds- only in summer
One large bug which currently exists is the fact that clouds will evaporate any liquid, even oil, and condense into water or snow. This is because the GetMaterial() function will only return solids, so currently the Evaporation script uses GBackLiquid() to find water (or any other liquid). (If anyone knows of a method to search for water at X,Y; that would be great :] )
![[de]](/mwf/flags/de.png "Germany")
You can pull the current project from here: http://www.bitbucket.org/ringwall/cloud-system/
i thaught about a repos compatible with the OC repos so that i only type "$ hg pull your-repos.de"
You can clone from Bitbucket and use the forests extension or subrepositories to get it inside your OC tree. Also please tell us if this works, I haven't had any experience with subrepositories yet. :)
it works well.
but the clouds have a drawing bug - and they are moving away too fast.
but the clouds have a drawing bug - and they are moving away too fast.
![[se]](/mwf/flags/se.png "Sweden")
Are we talking about this (http://mercurial.selenic.com/wiki/subrepos)?
Either way, since Im currently learning mercurial Im taking all chances to check the system out.
Any reason why Ringwaul choosed not to put this in i clone of the official repo?
Either way, since Im currently learning mercurial Im taking all chances to check the system out.
Any reason why Ringwaul choosed not to put this in i clone of the official repo?
> Are we talking about this (http://mercurial.selenic.com/wiki/subrepos)?
Yes, that one.
![[us]](/mwf/flags/us.png "United States")
> If anyone knows of a method to search for water at X,Y
"if(GetMaterial(x, y) == Material("Water"))" should do the trick.
Hmm. I stand corrected about GetMaterial(); it works fine. Maybe I was confusing it with another bug I was having before...I would like to have clouds dynamically placed in the sky (and rise to normal cloud height via Temperature and Cloud size), so naturally I planned to use something like:
PlaceObjects(CLWD, LandscapeWidth()/35, "GBackSky");
It seems that it will always either place the clouds on the ground place them in a liquid. I've used the exact function printed above, and it will never place them in the sky. If this is a broken function; I'll go ahead and create my own PlaceInSky(id pObj, int iAmount) function.
Don't forget that it's completely in our hands to rework the seasons system, the day/night cycle, the wind system etc if a new and more fun wheather system requires it.Edit: And that I read now about evaporation and more possibly "realistic" extensions - keep in mind the changes the wheater system has on the gameplay. Realism is imo not too important as long as it a) looks good and b) is fun.
The main problem (or feature, if you will) with rain in CR is the fact that it will eventually fill the entire map, unless the Sea Level rule is on. Even if this rule is on, tunnels and underground caverns will fill up with water.Currently the only thing I can see in CR that conflicts with the weather system I'm making is when it's winter, all water on the map will freeze (given enough time). If only a couple feet of water (relative to a Clonk) froze, it would allow clouds to continue producing snow. Of course one can see that this would eventually drain out frozen over lakes. Though I heard some talk of water traveling through solid materials; if water could diffuse through ice this would prevent these lakes from draining.
I always loved that, when trying to mine and the tunnels filled with water and you had to set up elaborate pumping systems to maintain them. It was just another fun and challenging aspect of the game.
Of course, this also meant that, somewhere on the map, there had to be a bottomless pit or similar. Since the water has to go somewhere once pumped out of the tunnel.
Of course, this also meant that, somewhere on the map, there had to be a bottomless pit or similar. Since the water has to go somewhere once pumped out of the tunnel.
Wow, very cool :)
Alright, the cloud placement is finished. :) Thanks to Maikel's function, I was able to finally make dynamic cloud placement work properly.You'll be able to pull it from the repository mentioned in the first post.
I believe I've fixed the majority of issues the normal clouds have. Fixes:
*Clouds will spawn at realistic heights on any map (even Sky Islands)
*the option to disable lightning strikes by setting the cloud environ-obj to 2x in the editor, though this will likely be changed to a seperate environment object to allow lightning strike frequency when stormy.
*some other small tweaks I can't recall
There are some features I should add, such as acid rain (on/off option) and clouds moving vertically based on heat. However, there are still a few bugs, such as an airship's TopFace's being drawn in front of clouds, and clouds pushing clonks out of airships due to collision with the cloud's vertices.
>and clouds pushing clonks out of airships due to collision with the cloud's vertices.
Which category do they have? I think C4D_StaticBack| C4D_Foreground wouldn't cause such problems
C4D_Foreground is used for GUI elements and has some special drawing code in OC. I think we should rename it to C4D_GUI.We should consider replacing the category sorting system with a simple sort order attribute.
C4D_GUI should be...:+ parallax by default
+ in the foreground, even in front of FoW
+ calls to GUI objects for mouse clicks, drag and drops
+ should get the calls from GameCallEx too
+ zoom is not applied
> + parallax by default
I could change the GUI rendering coordinate system so it will not apply view offset to GUI objects. This would simplify the code (no special handling in parallaxity check). However, I'm not sure this is a good idea. What if you want to attach a GUI element to an ingame object (such as e.g. the fantasy combo menu does now)? There would be no way to turn off parallaxity.
> + in the foreground, even in front of FoW
FoW is rendered by modulation and as such independent of object Z order. However, there might be cases when you want GUI objects to be attached to normal objects and be affected by FoW.
I'd say we keep our three categories and just add C4D_GUI = C4D_Foreground | C4D_Parallax | C4D_IgnoreFoW.
> + calls to GUI objects for mouse clicks, drag and drops
C4D_MouseSelect works already. We need additional object properties for more advanced mouse interaction. Not sure if they need to be GUI-specific.
> + should get the calls from GameCallEx too
I don't like where this is going. We might think of better, more generic methods of hooking into function calls.
> + zoom is not applied
I think this is already the case?
> FoW is rendered by modulation and as such independent of object Z order. However, there might be cases when you want GUI objects to be attached to normal objects and be affected by FoW.
I'd like to change the FoW to be a simple texture blit. Or at least have the possibility to do so. So requiring that objects not affected by the Fog of War be in front of everything else would be good.
Why? It was changed so you could have objects integrated in the normal landscape shine through FoW.
Maybe, but is that really that useful? If it's that important that the object can be seen, why would you want it obscured by some other object?
What about a spell that grants vision on all enemy Clonks for a while?
What's the problem with giving away the enemy Clonks immediate surrounding as well? Or alternatively, what's wrong with painting the magical graphics above the FoW? You couldn't just set the ignore-FoW-flag on the original Clonks anyway, because such a spell shouldn't grant vision to your enemies other enemies as well.
Night vision maybe?
>*the option to disable lightning strikes by setting the cloud environ-obj to 2x in the editor, though this will likely be changed to a seperate environment object to allow lightning strike frequency when stormy.
How about something like global func AdjustLightningFrequency(int freq) { FindObject(Weather)->SetLightningFrequency(freq); }?
>such as an airship's TopFace's being drawn in front of clouds, and clouds pushing clonks out of airships due to collision with the cloud's vertices.
Why does the cloud have vertices?
I was planning on making a lightning environment object, that would have no internal script of it's own, but would be found by the cloud script and adjust lightning frequency as to how many lightning environ-objects were found. Of course, that would require more objects on the scene and not be very precise. Your method seems more precise and simpler to integrate into the editor, though.Mainly to stop clouds from passing into terrain and getting stuck (as nothing by sky affects wind). I guess I could make scripted GetMaterial checks at either side of the cloud instead of using vertices for terrain collision.
>I guess I could make scripted GetMaterial checks at either side of the cloud instead of using vertices for terrain collision.
But that will probably be slower - if you can do it with vertices, I think there is nothing wrong with that
Hmm, I'm having some trouble converting the cloud system to CR. Does anyone know how to get debug logs?
Alright, I've successfully ported the clouds to OpenClonk; now that I finally had some free time. Contrary to the hg changelog, I'm fairly certain basic cloud functions (evaporation/condensation) are working well, though I haven't time yet to test the other functionalities.
I get the warnings that (parts of) the clouds system are not in #strict (2) syntax.
Powered by mwForum 2.29.7 © 1999-2015 Markus Wichitill
