Ask a simple question, get a simple answer

[Isaac]

*and c:isAlive()*

This returns false for petrified PCs. Remove this check, and the spell works.

[THOM]

WOW... Hey Thom when you do the Trickster can you share with us ? I like the idea he is not Hypo lol.

I made two versions. And here are the links to the animation-files:

trickster_idle_slow.animation

trickster_idle_slowest.animation

Thanks, Isaac, for the help!

[AndakRainor]

I see this in the assets pack:

Code: Select all

defineTrait{
	name = "aggressive",
	uiName = "Aggressive",
	icon = 75,
	charGen = true,
	description = "You are full of rage. Damage +4",
	-- TODO!
}

Does anyone know the name of the stat that must be provided to Champion:addStatModifier(name, amount) to do the same thing as the aggressive trait?

[minmay]

There isn't one. Aggressive is hardcoded. You can't give a bonus to attack power with the user scripting interface.
Edit: All stats:

Code: Select all

health
energy
max_health
max_energy
strength
dexterity
vitality
willpower
max_load
exp_rate
food_rate
health_regeneration_rate
energy_regeneration_rate
cooldown_rate
protection
evasion
resist_fire
resist_cold
resist_shock
resist_poison

[AndakRainor]

Is it possible to make a model or a particle system visible through walls? I guess it is not, given the occlusion system of the game ? (I was thinking about the Detect Life spell of Skyrim.)

[minmay]

I don't think occlusion will be a problem. You can just give the model a gigantic bounding box to prevent it from being occluded.

There are a few things that are very big obstacles, however. For the moment, assume the only blend mode for materials is Opaque; I'll cover others later.
First, the renderer isn't designed to draw things in front of other things unless they're actually in front. The very hardware on your GPU is designed around this.
But sometimes you don't want that, and you want the further-away-from-the-camera thing to draw in front of the closer-to-the-camera thing. There are various ways to do this, but the relevant one here is depth bias, because it's the only one available in Grimrock. Every material and particle emitter has a "depthBias" property. If you're interested in its exact meaning, look up "Z-buffering". The short explanation of depth bias is that it makes the renderer treat the material/particle as if it's closer or further from the camera than it actually is. On materials, negative depthBias makes the material closer, and positive depthBias makes the material further away. Depth bias will NOT change the actual location of the model in the 3D view; it will appear in the exact same location, size, and perspective on the screen. All it does is potentially make it render in front of, or behind, things that it otherwise wouldn't.
For particle emitters, the effect of the depthBias property is totally different! The signs are inverted, so a higher depthBias means closer, instead of further away. Furthermore, instead of merely changing the z buffer position, it actually changes the location of the particles in 3D space to be closer to the camera. I assume there is some implementation detail (outside of my area of expertise) that makes traditional depthBias impractical to add to particles.
depthBias gets you past that first obstacle, but there are two more problems that appear.
The first one is that you don't get to set depthBias dynamically, and you don't get to set it per mesh or anything fancy like that, just per material. So you might be defining more materials than you wanted. And while you can seamlessly swap out materials thanks to ModelComponent:setMaterialOverrides(), you can't swap out particle emitter definitions. (You can stop a ParticleComponent and start a new one on the same frame, of course, but the particles created by the old particle system are still stuck with the old emitter's depthBias and other properties).
The second one is only relevant for materials, but it has a lot of potential to be a problem there. The thing with depthBias is that it doesn't just make the model render in front of/behind other models it normally wouldn't; it'll also make the model render in front of/behind parts of itself that it normally wouldn't. You'll find that this is a problem with a lot of models.

Now let's stop pretending that Opaque is the only blend mode. Everything I said about depthBias still applies to other blend modes; it works the exact same way there. Depth bias works for all blend modes. Maybe it doesn't work with all shaders (IIRC portal, water, and sky do some funny things), I haven't tested.
Obviously, the model rendering in front of parts of itself that it "shouldn't" is no longer a problem if you are using the Additive, Screen, Modulative, PremultipliedAlpha, or AdditiveSrcAlpha blend modes, since they are symmetric.
With that out of the way: blend modes other than Opaque offer an additional option for faking depth. ModelComponents and ParticleComponents have a "sortOffset" property that defaults to 0. When non-opaque blend modes cascade, they do so in order of sortOffset first, only using their actual depth if there is a tie. So if you have two ModelComponents with non-opaque blend modes, by default the closer one will render in front of the farther one (i.e. perform its pixel blends last), but if you give the farther one a lower sortOffset value, the farther one will perform its pixel blends last instead, as though it were actually in front.
EXCEPTION: If two sort offsets are the same, and the two blend modes being used are Translucent and [anything other than Translucent or Opaque], instead of blending the closer one last like you would expect, the order of the blending appears to be essentially undefined - it changes with the camera angle. So try to avoid that situation. (It's possible that you could get around it with the "ForceZWrite" or "DisableDepthTest" render hack? I don't actually know what any of the render hacks do.)

If you go into the ORRR3 source and search mod_assets/rooms/minmay/objects.lua for "sortOffset", it offers some decent examples (I'm aware the file is a goddamn mess in general, but if you just search for "sortOffset" that won't matter ).



I think we've abandoned all pretense of "simple" at this point.

[THOM]

I've encountered a strange thing:

I have a breakable object with a health component like this

Code: Select all

		{
			class = "Health",
			health = 80,
			immunities = { "poison", "cold", "physical"},
			spawnOnDeath = "hit_wood_object",
		},

But if I attack this object with a torch (damageType = "fire", like the original one) it doesn't get any damage. Why is this? Other fire-damage weapons (fireburst, damageTile "fire") are doing damage... ???

[AndakRainor]

I think I have something good enough, thank you for your infos about that Minmay. I used a model, the rune trap, I couldn't get anything done correctly with particles:

SpoilerShow

One problem remains that I did not think about; the far clip in an interior map is quite brutal for this spell, would there be a solution to change it without compromising the rendering performance of those maps?

[minmay]

Oh, yes, the far clip. You can't remove it without hurting performance - that's why it's there. You could recoup some of the loss by adding a 25x25x25 cubic OccluderComponent to the party, but that's about it. (yes, the party transform does not match the party camera's transform but this is unlikely to make a significant difference, if it does you can always make the occluder a bit bigger)

(Reminder on how to remove it:)

SpoilerShow

By the way, you might have noticed that on levels with no enabled SkyComponent or FogParamsComponent, if you're using the default camera, everything more than a 20 Chebyshev meters away from the party fades into black. This is because all levels have fog by default! The color of this fog is 0,0,0 and its range appears to be {20,25}. However, if you try to increase this fog range, or disable it, like:

Code: Select all

party:createComponent("FogParams"):setFogRange{50,100}

or

Code: Select all

party:createComponent("FogParams"):setFogRange{1,1}

you'll find that everything over 25 Chebyshev meters away is still completely solid color (whatever the appropriate fog color is for 25 meters, and by default that is of course 0,0,0) - and actually occluded, whereas fog itself does not occlude. Obviously, this is quite useful for performance, and possibly ambience, in indoor levels. But what if you want to get rid of this effect? You can't do it with FogParamsComponent, but adding a SkyComponent will do the job. If there's an enabled SkyComponent on the level, this occlusion behavior will disappear. An almost-minimal example:

Code: Select all

defineObject{
	name = "remove_indoor_fog",
	components = {
-- The choice of trap_rune.model is not important, it's just the smallest model file in the standard assets. If you have a "null" model, using that instead would be slightly better.
-- All of these components are mandatory, the sky will crash if any are removed.
-- The game actually re-enables the ModelComponents on its own but since the models have no vertices or triangles this shouldn't matter.
		{
			class = "Model",
			model = "mod_assets/null.fbx",
			enabled = false,
		},
		{
			class = "Model",
			name = "nightSky",
			model = "mod_assets/null.fbx",
			enabled = false,
		},
		{
			class = "Model",
			name = "stars",
			model = "mod_assets/null.fbx",
			enabled = false,
		},
		{
			class = "Light",
			enabled = false,
		},
		{
			class = "Light",
			name = "ambient",
			enabled = false,
		},
		{
			class = "Sky",
			farClip = 4096,
			fogRange = {1, 1},
			fogColor1 = vec(0,0,0),
			fogColor2 = vec(0,0,0),
			fogColor3 = vec(0,0,0),
		},
	},
	placement = "floor",
	editorIcon = 100,
	reflectionMode = "always",
}

Download null.model here (right click and "save link as"). This is just a model with no vertices or triangles, for use when a ModelComponent is required (like it is here) but you don't actually want to draw a model. It has a "gate" node so that it can be used as a dummy model for DoorComponent. Of course, you could use sky.model and it would be fine, but why make the game render all those triangles when it doesn't have to?
There are a few things to be aware of if you're doing this to get rid of the default indoor fog:
1. By removing that default 25 meter occlusion, you are obviously going to hurt performance. This will be an especially awful performance hit if your wallset is missing occluders (i.e. it was built incorrectly, in which case you should fix it anyway nobody likes broken wallsets). A very easy way to still get some occlusion is to change the farClip to your desired draw distance, and use fogRange to make a smooth fade to black (or any other fog color you desire), e.g. farClip = 48 and fogRange = {24,48}. But remember what I said above: that will only occlude while the default camera is the active one. It won't help performance with custom cameras.
2. The default static shadow distance for LightComponents is not infinity. It's about...25! So shadow detail level changes will become apparent in your indoor levels when they previously weren't.
3. If your level has water, the reflection will use the fogColor of the sky in any pixels where it can't find anything to reflect. The sky models themselves don't appear to count as something to reflect for this purpose (but the clouds do, or at least appear to????). This is why I set the fogColor to 0,0,0 in the example object. If you set it to 1,0,1, your water meshes will seem to have magenta edges.

I couldn't get anything done correctly with particles

I probably should have mentioned this in the first place, but I think there are some GPUs/drivers that don't like Grimrock's implementation of particle depth bias for some reason. When testing my Grimrock 1 dungeon, I found that on one of my computers, particles with depth bias would often fail to render at all.

[minmay]

But if I attack this object with a torch (damageType = "fire", like the original one) it doesn't get any damage. Why is this? Other fire-damage weapons (fireburst, damageTile "fire") are doing damage... ???

Due to an implementation detail you'd rather not know about, if a HealthComponent has immunity to the "physical" damage type, it effectively becomes immune to all melee attacks, ProjectileComponent attacks (like crossbow quarrels and thrown items), and firearm attacks. TileDamagerComponent-based attacks, like fireburst, fireball, etc. will still work fine.