Ask a simple question, get a simple answer

[minmay]

Apparently, removing the watersurface entity doesn't fix every debugdraw box.

SpoilerShow

The reflection in the image is on a material similar to watersurface. Becomes transparent and everything if you add a watersurface.
Removing this fountain (the only entity that uses the water material) still doesn't help.
This debugdraw box is part of the socket component, unlike the obelisks where its an itemconstraintbox.

The WaterSurfaceComponent is what makes the reflections and causes the debugDraw bug. Not the water material. You need to destroy all WaterSurfaceComponents on this level. (Also, you should never have more than one WaterSurfaceComponent on a level in the first place.)

There are no water surface components on the level, yet this gets reflected anyways.
What I said was that I've mapped the material used by watersurface to these faces on the model (the fountain under the armor)
And even removing the model doesn't change anything.
Even on a newly added level, it still doesn't display.

SocketComponent's debug draw doesn't even contain yellow. It's red, green and blue axes. It looks like this. The reflection in your new screenshot is something else. Sounds like your SocketComponent is inside a model so you can't see it.

The reflection in the image is on a material similar to watersurface. Becomes transparent and everything if you add a watersurface.

The reflection buffer shouldn't even be able to update if there isn't a WaterSurfaceComponent on the level; the reflection in your screenshot looks like the leftover buffer from an update that happened many frames ago. And what do you mean by "a material similar to watersurface"? The "water" shader and reflections only work properly on materials named "ocean_water", "water_underwater", or "water_surface_calm". There's no material called "watersurface" in the standard assets.

[zimberzimber]

Ah, I see. Thanks for clarifying.

About the water material, yes I posted the wrong name, its water_surface_calm.

[Isaac]

But there are several wall types, such as tomb walls, which have decorations and paintings that don't show up if I simply overlap a secret door with the wall I want; if I disable the door model, the shadow and collision goes with it.

You can change the model used by a secret door, via script; although... the best results are to be had with custom models, made to suit.

[minmay]

Hi, I have another question; after looking through the reference I haven't found a way to make this work.

What I want to do is create some outdoor buildings; using the tiles for walls doesn't work and besides, it makes them occupy a whole tile, while I would only want the walls to occupy the edge of tiles. There are wall elements I can place, but they don't project any shadow and do not block movement (they also are invisible from one side, though I can just mirror them to fix this). All except the secret doors, which behave exactly as I'd like and expect walls to work. But there are several wall types, such as tomb walls, which have decorations and paintings that don't show up if I simply overlap a secret door with the wall I want; if I disable the door model, the shadow and collision goes with it.
So my question is: is there a way to make wall elements solid? I've found the ModelComponent:setBoundBox(desc) method, but I don't know if that's what I'm looking for, nor what or how I'm supposed to populate "desc".

I think you are confused about the basics here.
All that tiles do is place GameObjects and set a few values: whether the tile is solid, whether the tile is underwater, whether the tile is diggable, the automap tile, and sometimes the heightmap material.
Most objects with "wall" in the name just have ModelComponents and OccluderComponents. To make a "wall" that actually blocks things, you need a DoorComponent (which needs a ModelComponent with a node named "gate"). Objects like tomb_wall_01 don't have DoorComponents because that would be an unnecessary drain on performance: the tiles behind them are already solid.

[zimberzimber]

I have a trait that should give bonus armor to the champion near/in front of the champion with the trait, but it doesn't seem to apply the bonus protection to them.
Here's what I have:

Code: Select all

defineTrait{
	name = "bulwark",
	uiName = "Bulwark",
	description = "After countless encounters, this champion learned to protect its allies\nGranting bonus protection based on your own",
	
	onRecomputeStats = function(giver, level)	-- Giver is the champion with the trait
		local receiver, pos						-- Receiver  is the champion who gets the bonus
		local bonus = giver:getProtection()
		for i = 1, 4 do if giver == party.party:getChampion(i) then pos = i end	end
		
		if pos == 1 or pos == 4 then
			receiver = party.party:getChampion(2)
			if receiver then receiver:addStatModifier("protection", bonus) end
			
		else
			receiver = party.party:getChampion(1)
			if receiver then receiver:addStatModifier("protection", bonus) end
		end
	end,
}

[AndakRainor]

I think it does not work because you are doing this in a onRecomputeStats function of another champion. It is too late to add modifiers to other champions each frame, they must have already run their own stats calculations. May be you could try to do the opposite, and check for nearby champions with this trait in the onRecomputeStats functions of all classes.

Edit: also, you can't be sure you will get the right value with getProtection() inside onRecomputeStats. You should avoid reading any stat inside this function. You could get it from a script entity where you keep the value updated with a timer (so the value comes from outside any onRecomputeStats call), use a fixed value, or a stat you are sure enough will have the right value, for example the champion's level.

[zimberzimber]

Edit: also, you can't be sure you will get the right value with getProtection() inside onRecomputeStats. You should avoid reading any stat inside this function. You could get it from a script entity where you keep the value updated with a timer (so the value comes from outside any onRecomputeStats call), use a fixed value, or a stat you are sure enough will have the right value, for example the champion's level.

recomputeStats in traits comes after heroes?
If so, I'm just gonna give every champion a hidden trait for all the stat sharing.

[Isaac]

Try having the trait give conditions to adjacent champions. The trait could also have a check for the condition, and not give it again if they have it.

* Consider if the giver get's killed; conditions expire on their own.

[zimberzimber]

Try having the trait give conditions to adjacent champions. The trait could also have a check for the condition, and not give it again if they have it.

* Consider if the giver get's killed; conditions expire on their own.

Thats what I tried doing with the Bulwark up there.
Instead, I'll give everyone a permanent trait that adds bonuses based on things.
Like checking if an adjacent champion has a trait. If so, give X Y and Z.

[AndakRainor]

recomputeStats in traits comes after heroes?
If so, I'm just gonna give every champion a hidden trait for all the stat sharing.

I am not sure what you mean there, but the various onRecomputeStats functions are called in some order, I don't know which one. I you want to know exactly this order, you could print some messages in all EquipmentItemComponent, skills and traits of champions, (in races, classes, ...) then see if they always appear in the same order.

But you can be nearly sure, when inside a onRecomputeStats function that you won't be in the last one to be executed, so the stats you can read from champions are not final, they are being built, you can't trust their current value. It is possible for example that your protection was still 0 at the time you read it.

All thoses functions are called every frame, before any timer component triggers, so you could use a timer to get the current value of a stat, but not while they are being calculated.