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/
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
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 :] )
but the clouds have a drawing bug - and they are moving away too fast.
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.
> If anyone knows of a method to search for water at X,Y
"if(GetMaterial(x, y) == Material("Water"))"
should do the trick.
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.
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.
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.
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.
You'll be able to pull it from the repository mentioned in the first post.
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
We should consider replacing the category sorting system with a simple sort order attribute.
+ 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.
>*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?
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
Powered by mwForum 2.29.7 © 1999-2015 Markus Wichitill