Acid, Fire, Drowning, Healing, Gravity, Friction

by solanus on 07/31/2008 14:41, 12 messages, last message: 08/02/2008 08:36, 1600 views, last view: 05/03/2024 06:28

I know these are big requests, but these functions have existed in other commercial games for years.
Acid: a water-like material that deals damage slowly (maybe in configurable amounts?)
Fire: a light-emitting material that deals damage slowly (maybe in configurable amounts?)
Drowning: adding a delayed temporary damage to underwater
Healing: Regenerate points over time
Gravity: Configurable, it would make all those space-type maps way more interesting!!
Friction: Ice, tar, etc.

Obviously not in the next release, but shouldn't we be shooting for these at least?

   Board Index   

#1: triggered material

by MisanthropX/Redon on 07/31/2008 15:52

that would be easy to create... and fire = (newent particles 9 259 1 1824)

there should be a material and you can declare in CFG how much dmg per sleep X

i dont know the command for damage but in SP its possible (trigger: sleep 2000[dmg 100] well actually theres no damage command.. i guess =P
"ice" is possible too (just spam lots of bug-cubes)
healing is also possible with a trigger but i guess theres no healing command too.. dont know.. gravity: possible too.. you have to change the physics.ccp but i dont know how

reply to this message

#2: ..

by Mr.Piddly 00000001 on 07/31/2008 19:50

I think that acid, fire, and drowning could basically be combined into a single damage ent. A damage ent would have a damage factor (decrease in health per second), size, and delay in milliseconds. Just combine a damage ent with some other ents to get the desired effect.

In the future, it would be better to have other shape besides a sphere that could act as the area affected by a damage ent.

reply to this message

#3: On the above

by R0b0t1 on 08/01/2008 21:25

Alternatively, how about just make the death material configurable? Almost like how water can be shaded a certain color.

reply to this message

#4: ..

by Max of S2D [Fr] on 08/01/2008 22:47

I highly approve this, but some of these "materials" shouldn't be classified as real materials.

The mapping view would get way too hardcore.

For example, two materials can already superpose themselves (clip and water). What if we add drowning/tweaked_death to this?

So I suggest that, if those ideas are implemented, to be able to switch between a "material on/off" and "damage zones on/off".

reply to this message

#5: subject

by }TeDy{Radial on 08/01/2008 23:13

Gravity is the one i would most like to see. cant be that hard. would need a new var for grav and something like setGrav for the map CFG.
Acid and frictions sound like great ideas too. i don\\\'t really know about the healing though. i dont really think they fit for saurbraten because most people dont stay alive that long anyways. drowning would be render maps like thor obsolete because they are mostly underwater. friction would be cool too but can be somewhat faked already. fire can also be made very nicely. friction should probally be a material but must be able to be sloped.

i think Gravity is the best point.

reply to this message

#6: Re: On the above

by Mr.Piddly 00000001 on 08/01/2008 23:13, refers to #3

I like that idea.

The main problem is that current commands would affect all of a material. For example, I do not believe you cannot display both green and red water at the same time. So, you either have to use a trigger system to control a material's properties or have instances of material with different properties.



For the second method, child materials that inherit and alter their parent's properties could be created.
These materials would be defined in the .cfg and then individually placed in edit mode. Or, some sort of ent could link to continuous areas of materials to create a child material. Properties are then sent to the material from the .cfg using the linked ent.

Each of my methods has its advantages and disadvantages and they do not take feasibility into account, only how to theoretically solve that problem.

reply to this message

#7: ..

by R0b0t1 on 08/02/2008 01:00

Like I said, it would just be easiest to be able to change the death materials properties, not adding any materials.

reply to this message

#8: Damage Entity

by tman_elite on 08/02/2008 03:47

Acid and Fire could be solved easily by:

/newent damage R D

where R is the radius and D is either the damage applied per second continuously, or if continuous damage doesn't work, it could apply D damage every half or quarter second.

Then you'd just have to have (green) water for acid or a particle for fire, and the problem is solved.

reply to this message

#9: Re: Damage Entity

by SheeEttin on 08/02/2008 06:24, refers to #8

Well, then there's the problem of having a spherical damage area (volume, if you wanna get all geometric on me) doing the damage for a cubic (or whatever the word is, as you might guess, I don't know that much about this field of math) volume.

I think it'd be better solved by setting things in the CFG, e.g. "damagerate D", where D is the amount of damage dealt per second.
This should probably be applied if the player's bounding box intersects the damage material, but I don't know how hard that'd be... Could always just keep the eyeheight method and just place the material higher than you'd think it'd be.

As usual, we're long on ideas and short on code. :P

reply to this message

#10: ..

by Quin on 08/02/2008 06:37

You realise it isn't that hard to give each material volume its own properties, if you're familiar enough with the code.

One of the first things I ever did while experimenting with Sauer was make "texturable materials" (in that I mean, you could Y+scroll to change it just like cubes, this was before reflections and envmaps mind you) and to make them individually colourable. I'd also setup secondary "volumes" which defined gravity and teleportation on a per cube level.

It was all a rather neat way to get to know the engine, and was actually what spurred me to seek out the community.

reply to this message

#11: Re: ..

by JadeMatrix on 08/02/2008 06:52, refers to #10

Yes, but the problem comes not from the ability to do it, but how easily it can be graphically represented. Cube's real-time editor is it's main feature, so the biggest stumbling block when this was last suggested was the displaying of tags for each material area, so you'd know what you were defining in the cfg.

reply to this message

#12: Re: ..

by Quin on 08/02/2008 08:36, refers to #11

I found using a particle text at the nearest most corner to the camera effective.

reply to this message

   Board Index