UFO:Alien Invasion
Technical support => Feature Requests => Topic started by: RedMage on May 17, 2007, 05:57:14 am
-
I wish that later versions will have destructibale objects. And make the mechanics like XCOM: Apocalyse. Where a destroyed lower wall will slowly make the upper floors collapse.
-
Yup, nice idea, feel free to prepare and send a patch.
-
Nival's Silent Storm had a very good physical engine, but I have no clue whether it's available or not (I don't think it is).
What's more, I think I've understood that no engine change is planned in the near or not-so-near future. :)
-
Yup, nice idea, feel free to prepare and send a patch.
To be honest I don't really think that a patch would be enough for that :shock:
-
I guess that's Zenerka's way of saying "Why don't you GET INVOLVED into doing/helping us do it ?" :)
-
Yep, exactly, breversa.
-
i agree that Silent Storm and Hammer&Sickle got some great features like ability to climb up on objects then thru holes in ceiling etc ...
-
i just realized you can shoot thru windows ... in
if rocket projectile hits woodenwall then swap the woodednwall for woodenwall with 'windows' like properties and hole texture ...
windows with glass which can be shoot off should be possible in Q2
http://www.gamedesign.net/node/20/#18
btw. is there will to utilize most of changes done to Q2 engine by others Q2engine mods ?
especially Qfusion http://sourceforge.net/projects/l33t/
http://hkitchen.quakesrc.org/
and EGL http://egl.quakedev.com/files/egl-v0.3.1-stable-src.zip
http://egl.quakedev.com/about/
and if You need theirs authors may help You to solve some issues ...
-
i just realized you can shoot thru windows
you have destroyable windows - or did i get you wrong?
btw. is there will to utilize most of changes done to Q2 engine by others Q2engine mods ?
yes - and we did that already for some changes
-
yes i said i realized it ;) (improvements against old techdemo version is outstanding :)
anyway i was only saying it because of similarity with destroyable walls (single square or it's surrounding)...
(ofc colapsing stuff after etc is totally different story)
-
Is it really so difficult to add the ability to punch a hole through a wall? I can't imagine it'd be that tough.
Off the top of my head I'd imagine what you'd need to do to add support for knocking a hole in a wall...
1) Add "min_damage_to_destroy" variable to all barriers
- eg, 10 on a fence, 100 on wooden wall, 250 on concrete wall (arbitrary numbers, not real game values)
- In that way, if a rifle has a damage range of 5-50, it *may* knock a hole in a fence, a grenade with a damage range of 50-300 will always knock a hole in a fence, typically in a wood wall, and occassionally in a concrete wall
2) When the barrier registers a hit (which is something I imagine already happens in the game... when aiming through a fence the target path line shows green to the fence, but red beyond it, and attempting to fire through the fence registers shots striking the wall), then perform a compare on each damage event to min_damage_to_destroy for the barrier
3) Whenever an object is destroyed, then swap out the tile with the destroyed version. eg, "wooden_fence_a" is swapped out with "wooden_fence_a_destroyed". As a stop gap all destroyed barriers can be swapped to a single generic "rubble" object, so that every barrier texture doesn't need to have a new sister texture generated.
The only question I have is I don't know if there is a problem coding the ability to allow characters to walk through a destroyed barrier? I don't know if the tile is flagged as "impassable", so that even if you can SEE through it, you can't walk through it. If true, then I don't see this as a stop-issue, just a limitation
If this feature is added, you could even expand it out to destroy large objects. For example, each tile which comprises a car has a min_damage_to_destroy set to 1000 (again, arbitrary value), and if it's surpassed then the entire car model / tiles are swapped out with a corresponding "blown up" car.
Anyhow, back on topic...
One thing to note, my comments are coming from about... hmm... I'd say maybe 20 minutes of actually playing the game, and 0 minutes of looking at any of the soruce code. I may be way off base.
But is this something scheduled for a future release? Is anyone already working on it? Is there a list of potential / planned future features? The sourceforge tasklist is pretty slim.
I don't really have much time now, but I may take an interest in adding the feature. It's been a few years since I've coded anything, and it could be a fun side-project.
-
Is it really so difficult to add the ability to punch a hole through a wall? I can't imagine it'd be that tough.
<SNIP>
I don't really have much time now, but I may take an interest in adding the feature. It's been a few years since I've coded anything, and it could be a fun side-project.
See the wiki, func_breakable.
-
Is it really so difficult to add the ability to punch a hole through a wall? I can't imagine it'd be that tough.
No. I can provide detail description what should be done and in what way. Care to do this for our maps?
But is this something scheduled for a future release? Is anyone already working on it? Is there a list of potential / planned future features? The sourceforge tasklist is pretty slim.
Take a look at our wiki at http://ufoai.ninex.info/wiki/ at TODO section.
-
Fascinating info. Actually Zenerka, if you don't mind, could you provide a very high level overview of what would be required to add this feature? Or a list of limitations for why it's problematic?
I would like to start poking at a few different parts of the code. Although in all likelihood I'd start with a lot smaller and less daunting tasks. ;)
-
It is not problematic at all. It just needs to be done.
Lets say we want to break a wooden fence. One must
1) create a particle for breaking wooden fence, so when one shoot at it, the user sees "exploding" wood
2) create and enable a sound for this event (cl_parse.c/CL_ParseStartBreakSoundPacket())
3) open a map, select desired brush beeing wooden fence, mark it as func_breakable
4) go to step 1. and repeat for every type of breakable thing you want to introduce
5) go to step 1. and repeat for every map.
HTH, HAND :->
-
Fascinating info. Actually Zenerka, if you don't mind, could you provide a very high level overview of what would be required to add this feature? Or a list of limitations for why it's problematic?
* There is an upper limit for server entities - it should not be exceeded
* as Zenerka stated - manpower is missing - as always
-
According to what Zenerka said, we just need particles and sound, the rest is up to the person mapping. So not much to code here, is there?
The problem I see with destroyable objects is that its a "property" assigned to a brush - so you would have to split up e. g. a fence in a lot of small brushes that are func_breakables so the damage seen will be any near the impact position. That results in a lot of brushes, and a lot of entities - which have an upper limit as Mattn just stated, not to mention performance costs.
Its probably the best to have a few brushes that are destroyable - which the player can guess - like windows, that fence, an already cracked wall, chairs.
At least with the current 'break-system' thats more suitable than having the goal of a even nearly realistic breaking behaviour of most map pieces.
-
* There is an upper limit for server entities - it should not be exceeded
What would this value be?
-
1024 is the upper entity (edict) limit (MAX_EDICTS)
-
According to what Zenerka said, we just need particles and sound, the rest is up to the person mapping. So not much to code here, is there?
Particles, sounds AND code support for every type of breakable material (which is needed to calculate particle and sound type). That is if you break a window, you want to hear breaking glass sound and see breaking window particle, etc.
-
1024 is the upper entity (edict) limit (MAX_EDICTS)
And to confirm, Server Entities are Spawn points, Func_breaks, Misc_models, lights, and func_groups?
-
func_group is only for editor usage - the others, yes