This is really important, we need basements, preferably scalable to any length, and somewhere around 8 pixels high.
Should not be that hard to make, but what do I know. This should really go into the 5.3 release imo, so if someone could do
this within the next few weeks, I and also some other people working on settlement would be grateful.
Should not be that hard to make, but what do I know. This should really go into the 5.3 release imo, so if someone could do
this within the next few weeks, I and also some other people working on settlement would be grateful.
Compose it from parts, so you can blow it partially like in C4!
I'd pretty much prefer something that cannot be destroyed. Meaning the basements delivers any damage to the building and the building is always destroyed before anything happens to the basement. Because then we need not to bother us with buildings falling down.
Because you have to cover this in the scripting. It's not particularly bad but extra work. Extra work we did not do so far. The two cases coming spontanously into my mind are:
Flagpoles. These have to redraw their radius once they stopped falling.
Elevators. A little twist in the elevator will look ridiculous because the rope ends somewhere in the air, also at some part the case should fall down.
You can only cover this by constantly checking all movement in buildings, so a timer with GetX() == old_x && GetY() == old_y
/e
One additional weirdness:
Gather some chopped trees below a sawmill, let the sawmill fall down, the sawmill will catch the trees will in mid-air. Cover this with a GetXDir() / GetYDir() check.
Flagpoles. These have to redraw their radius once they stopped falling.
Elevators. A little twist in the elevator will look ridiculous because the rope ends somewhere in the air, also at some part the case should fall down.
You can only cover this by constantly checking all movement in buildings, so a timer with GetX() == old_x && GetY() == old_y
/e
One additional weirdness:
Gather some chopped trees below a sawmill, let the sawmill fall down, the sawmill will catch the trees will in mid-air. Cover this with a GetXDir() / GetYDir() check.
>You can only cover this by constantly checking all movement in buildings, so a timer with GetX() == old_x && GetY() == old_y
That would really be worth an engine callback.
Yeah, it's more or less possible to check all corner cases. The question is, is it worth it? Just to have buildings that can fall down? Personally, I'd say 'no' and therefore rather have 'indestructible' (until the building is destroyed) basements.
If BlastToMaterial is not enough, I'd suggest to finally implement the often mentioned Hardness property for materials which changes an explosion's blast radius in that material. I know that there is at least one bugtracker entry assigned to Sven2 for that.
If partially blown up basements are not wished for but should be destroyed up together with the building, I have an idea that would require no extra graphics and objects, would blend well into the landscape and is absolutely dynamic regarding it's size:
Create a new indestructible material Basement (or better: use the indestructible bricks material). Then, on completion of the building, the basement is drawn as a material quad and on destruction, it is cleared again (replaced with earth or something).
Create a new indestructible material Basement (or better: use the indestructible bricks material). Then, on completion of the building, the basement is drawn as a material quad and on destruction, it is cleared again (replaced with earth or something).
The only advantage I see is that the landscape lighting is applied to that material.
Cutting a texture to a certain size is perfectly fine with an object (as long as basement length is < graphics length), cutting solid mask is fine and you don't have to bother with replacement because the material is not removed.
Also with your idea it's not possible to damage a building from below.
If it's just for the lightning we should rather see how we can apply this to an object.
Cutting a texture to a certain size is perfectly fine with an object (as long as basement length is < graphics length), cutting solid mask is fine and you don't have to bother with replacement because the material is not removed.
Also with your idea it's not possible to damage a building from below.
If it's just for the lightning we should rather see how we can apply this to an object.
>Also with your idea it's not possible to damage a building from below.
No? Wouldn't the explosion damage go through the bricks if the explosion radius exceeds it?
Yes, if the explosion is big enough. I don't know though if the regular flint is strong enough. But you'd have significant difference between explosion from below and from above.
Actually no. Not at the moment.
Livings in the radius are damaged, that is true. For buildings etc. only the mid-point of the explosion is relevant. That means you can make a Flint explode with a strength of 10000 directly in your base but it will only destroy the building it was in front.
At least that's how it worked in Clonk Rage. Would be worth changing, I guess. It was sooo annoying when trying to destroy drawbridges anyway :)
Livings in the radius are damaged, that is true. For buildings etc. only the mid-point of the explosion is relevant. That means you can make a Flint explode with a strength of 10000 directly in your base but it will only destroy the building it was in front.
At least that's how it worked in Clonk Rage. Would be worth changing, I guess. It was sooo annoying when trying to destroy drawbridges anyway :)
Alright, so in my opinion we should change the Find_AtPoint to Find_AtRect (or how it is called) for explosions. Any explosion of a flint has a bigger radius than a basement, so the only contra point would be fixed.
That would have the problem, that Find_AtRect or Find_Distance (which would be better here?) only find objects whose MIDDLE POINT (read: offset) lies inside the area. That'll never be the case here.
I think both, Find_InRect and Find_Distance use shapes rather than middle points.
Cheat sheet:
Find_InRect, Find_Distance -> middle point
Find_AtRect, Find_AtPoint -> shape
Find_InRect, Find_Distance -> middle point
Find_AtRect, Find_AtPoint -> shape
If we don't want our explosions to be rectangular, we need something like Find_AtDistance
Physics also dictates that the damage should go as 1/r, where r is the distance between the damaged object and the center of the explosion.
I thought about that too earlier today. But I came to the conclusion that I am not sure whether I like that :D
Just because it makes things more complicated for the player (hey, why did his building die in two flints and mine needed five?) and does not necessarily have any cool benefits
Just because it makes things more complicated for the player (hey, why did his building die in two flints and mine needed five?) and does not necessarily have any cool benefits
I'd propose using
While we're at it, one could do fun stuff here like what Maikel proposed - or try to calculate an overlap area between the explosion and the building, scaling damage accordingly.
AtRect
and then do further filtering in script. That's basically what the engine would do as well, and the few corner-case objects are unlikely to be a performance concern.While we're at it, one could do fun stuff here like what Maikel proposed - or try to calculate an overlap area between the explosion and the building, scaling damage accordingly.
Lightning isn't applied to Vehicle? (Does Object-Material even still work that way?)
Vehicle wasn't invisible in CR :/
At least not when I drew it manually in developers' mode
At least not when I drew it manually in developers' mode
Well, yes, but is manually drawing supported at all? If used as a solid mask, vehicle is invisible and a somewhat special case. But if drawn directly, it's some weird material that moves clonks(?) and most important overrides existing material. What is there to gain?
In CP, Vehicle had a brown-ish color. I think it turned invisible (i.e.: Sky color) at some point during GWE, so in CR it should already be transparent.
In CR, solidmasks are temporarily removed from the landscape during the transfer to the GPU. OC has largely the same solidmask behaviour. Otherwise, Vehicle is a material like any other. (Though the engine does make some assumptions about the behavior of Vehicle. We should probably hardcode it in the engine to avoid having to fix crashbugs.)
I'm a bit confused as to what the current state of the discussion is (are we now talking about basements on all buildings again?), but in general I'd rather like if we had more options for generating materials into the landscape. You could have "basements kits" that for a price gives you a flat stable ground - sort of like a bridge segment.
I generally don't like the ideas of indestructible materials - getting Vehicle to work properly has already been a major pain.
I generally don't like the ideas of indestructible materials - getting Vehicle to work properly has already been a major pain.
Well, I was making a suggestion on how to implement basements for buildings.
In general, I am also in favor of more options for generating materials into the landscape, especially when thinking about castles..
In general, I am also in favor of more options for generating materials into the landscape, especially when thinking about castles..
Hm. There's a number of things that come to mind here. Our current loam bridges don't really support doing straight bridges too well... Maybe we could "improve" this somehow? The current "drawing" mode has its charm, but I somehow can't bring myself to really like it. Maybe limit the angles the loam will go to multiples of 45?
Also a random idea: Could we enable the loam bridge to "reinforce" material? So if you have earth on the ground already and use a loam do build over it, this could give you "hardened earth" or something - which can't be dug anymore and might or might not be more resistant to explosions.
Also a random idea: Could we enable the loam bridge to "reinforce" material? So if you have earth on the ground already and use a loam do build over it, this could give you "hardened earth" or something - which can't be dug anymore and might or might not be more resistant to explosions.
>Our current loam bridges don't really support doing straight bridges too well... Maybe we could "improve" this somehow? The current "drawing" mode has its charm, but I somehow can't bring myself to really like it.
Same here. I've wondered if, maybe, we should draw straight if it's close enough to the line. Like, if mouse movement is minimal (position-change from the start of "drawing" is only a few pixels) we could draw it straight, instead of following the mouse exactly.
Limiting it to 45 or maybe even 30 or 15 degrees would make drawing straight lines already pretty easy I guess, and would still allow for fairly flexible use of loam.
>Maybe limit the angles the loam ..
When I implemented my magic stuff, I also had the idea that being able to cast arbitrary force fields (basically drawing them) would be a cool feature.
It turned out that limiting that severely was a lot more playable.. :)
So I implemented this with multiples of 30 degrees, please test it and see whether you like 30 or 45 more (just change some number in the loam script). In my opinion 30 is a little better, cause pushing lorries on 45 degree slope looks a little odd and you have a bit more freedom.
Powered by mwForum 2.29.7 © 1999-2015 Markus Wichitill