Grimrock

Skuggasveinn wrote:Material names that can be assigned shaders (like ocean_water) seems to be hardcoded (like water_surface_calm), simply cloning the material with another name messes the ocean_water shader up.
Keeping the original name works but overwrites the default assets, if for some reason materials need to be hardcoded perhaps (and I don't know anything about shaders mind you) include names that modders can use like water_surface_custom_1 , 2 and 3 etc.

Unfortunately the realm of shaders is unaccessible to mods, because they are quite platform dependent. We have tried to setup things so that mods work on Windows and other platforms without changes. Therefore some special materials with names "ocean_water", "water_surface_calm", "water_surface_underwater" are updated by the game engine and can't be accessed by mods.

petri wrote:

MrChoke wrote:Maybe a bigger enhancement but more flexible, is you allow us to create the "hitEffect" object, via a function call maybe. That is really the problem. We have no way to customize this object based on info from the Projectile that it came from.

Don't you already have this ability? You can implement custom onProjectileHit hook for the projectile?

I think ProjectileComponent:setCastByChampion() is bugged. The first parameter should be champion ordinal. It's just the arg type checker that is wrong, so this should be very easy to fix.

Yes, we do have a method on ProjectileComponent but the game is not passing this to the TileDamager unless we use a built-in spell. It is bigger than just mismatch of the data type between the two methods. Perhaps this is part of bug you are referring to.

Please see this thread for further details on what exactly the issue is.
viewtopic.php?f=22&t=9416

Both of my suggestions are already on the list; along with some I'd never heard of.

Well... Pushblocks do ignore collision with doors. I don't know if that's a bug or not.
https://www.dropbox.com/s/eqxha6c33awrr ... s.mp4?dl=0

petri wrote:Unfortunately the realm of shaders is unaccessible to mods, because they are quite platform dependent. We have tried to setup things so that mods work on Windows and other platforms without changes. Therefore some special materials with names "ocean_water", "water_surface_calm", "water_surface_underwater" are updated by the game engine and can't be accessed by mods.

Is this related to why the animated water surface mesh is always set/fixed to [slightly below] zero floor elevation? It's more of a feature question than a bug, but is it possible in the engine to move the water level ~that's safe for all platforms, and render settings?

*I ask because I notice that the water_surface_calm shader effect on the mesh seems to get scaled when the mesh is moved via script.

petri wrote:

Skuggasveinn wrote:Material names that can be assigned shaders (like ocean_water) seems to be hardcoded (like water_surface_calm), simply cloning the material with another name messes the ocean_water shader up.
Keeping the original name works but overwrites the default assets, if for some reason materials need to be hardcoded perhaps (and I don't know anything about shaders mind you) include names that modders can use like water_surface_custom_1 , 2 and 3 etc.

Unfortunately the realm of shaders is unaccessible to mods, because they are quite platform dependent. We have tried to setup things so that mods work on Windows and other platforms without changes. Therefore some special materials with names "ocean_water", "water_surface_calm", "water_surface_underwater" are updated by the game engine and can't be accessed by mods.

I think Skuggasveinn's complaint is that other materials with the "ocean_water" shader (also "water_underwater", "portal", "stars", and "sky", if I remember correctly) don't get updated this way. Changing that wouldn't cause any problems, since it's still the same shader, right?

Bug that I don't see on the list: PartyComponent.onTurn() doesn't get called for turns made with free-look.

I see that other people are posting feature requests here, so I will go ahead and add mine. But these are not bugs to be fixed by any stretch of the imagination. In descending order of how much I would value them:
- PartyComponent:setSpeed(number) method, to change the speed of movement and turning.
- PartyComponent:move(direction) and PartyComponent:turn(direction) methods that work as if the player pressed the movement/turning keys (for making custom party controls).
- The shader change mentioned above.
- Support for the "offset" property in CameraComponent, and a way to set the FOV of a CameraComponent after creation.
- I have seen a lot of scripting problems where a Component:getName() method and/or a way of iterating through all a GameObject's components would be very useful.
- FirearmAttackComponent.onHitMonster() seems like it should exist, since it does for other attacks, but there are easy workarounds.
- ExitComponent:setDirection() and ExitComponent:setTeleportTarget(), to match StairsComponent.

Isaac wrote:Is this related to why the animated water surface mesh is always set/fixed to [slightly below] zero floor elevation? It's more of a feature request than bug, but is it possible in the engine to move the water level ~that's safe for all platforms, and render settings?

Huh? I have had no problem moving the water surface mesh. Just change the offset on the WaterSurfaceMeshComponent, and change the PlaneY on the WaterSurfaceComponent to match (so that the reflection is in the right place).
Or do you mean how the elevation at which the party is considered "underwater" in an underater tile is fixed?

Oh I have recalled a [possible] bug... Alcoves no longer fail when their onInsertItem hooks return false; unlike in LoG1.

minmay wrote:

Isaac wrote:Is this related to why the animated water surface mesh is always set/fixed to [slightly below] zero floor elevation? It's more of a feature request than bug, but is it possible in the engine to move the water level ~that's safe for all platforms, and render settings?

Huh? I have had no problem moving the water surface mesh. Just change the offset on the WaterSurfaceMeshComponent, and change the PlaneY on the WaterSurfaceComponent to match (so that the reflection is in the right place).

Oh I've done it, but it creates problems. For one thing, If you lower the water height and then lower the party elevation [below zero], you lose the reflection effects on the water surface. I was wondering if it were possible [technically] to have the water mesh default to the water_surface object's user defined elevation, an d have everything still work. Obviously though, it's not a bug, because it wasn't a feature.

Or do you mean how the elevation at which the party is considered "underwater" in an underwater tile is fixed?

That too; I didn't mention, but indeed, when the water level is raised, the effect shaders work, but the party is not considered underwater.

MrChoke wrote:

petri wrote:

MrChoke wrote:Maybe a bigger enhancement but more flexible, is you allow us to create the "hitEffect" object, via a function call maybe. That is really the problem. We have no way to customize this object based on info from the Projectile that it came from.

Don't you already have this ability? You can implement custom onProjectileHit hook for the projectile?

I think ProjectileComponent:setCastByChampion() is bugged. The first parameter should be champion ordinal. It's just the arg type checker that is wrong, so this should be very easy to fix.

Yes, we do have a method on ProjectileComponent but the game is not passing this to the TileDamager unless we use a built-in spell. It is bigger than just mismatch of the data type between the two methods.

I'm not following... In your onProjectileHit hook you know which champion cast the spell and you can pass this to tile damager in your hook, right? Assuming of course Projectile:setCastByChampion() arg gets fixed.

EDIT: this is how built-in spells work. Projectile stores the caster ordinal and calls setCastByChampion on tile damager when the spell hits something.

minmay wrote:I think Skuggasveinn's complaint is that other materials with the "ocean_water" shader (also "water_underwater", "portal", "stars", and "sky", if I remember correctly) don't get updated this way. Changing that wouldn't cause any problems, since it's still the same shader, right?

Do you have some uses cases for this feature in mind? For example, I'm having hard time trying to imagine need for ocean_water variations, since you can't access the shader internals they would all look the same?

minmay wrote:- I have seen a lot of scripting problems where a Component:getName() method and/or a way of iterating through all a GameObject's components would be very useful.

Oops Component:getName() seems to be missing, I'll add it. btw. component iterator already exists, see crystal_shard_recharging definition for example.

[quote="petri] I'm not following... In your onProjectileHit hook you know which champion cast the spell and you can pass this to tile damager in your hook, right? Assuming of course Projectile:setCastByChampion() arg gets fixed.

EDIT: this is how built-in spells work. Projectile stores the caster ordinal and calls setCastByChampion on tile damager when the spell hits something.[/quote]

I think the bug fix you mention will fix what I am saying. As long as the game will start copying what we specify in ProjectileComponent::setCastByChampion(number) into TileDamager, getCastByChampion(), since we cannot create the hitEffect object and set it ourselves in ProjectileComponent.

petri wrote:

minmay wrote:I think Skuggasveinn's complaint is that other materials with the "ocean_water" shader (also "water_underwater", "portal", "stars", and "sky", if I remember correctly) don't get updated this way. Changing that wouldn't cause any problems, since it's still the same shader, right?

Do you have some uses cases for this feature in mind? For example, I'm having hard time trying to imagine need for ocean_water variations, since you can't access the shader internals they would all look the same?

The use case is if someone wants to use the same shader with several different textures/params at once. For example my mod uses both regular water and ice, which uses the water shader for reflection/refraction but has a different normal map. Currently I overwrite water_surface_calm to accomplish this, and use the onUpdate() hooks to change the wave intensity, texOffset speed, etc. of ocean_water and water_surface_underwater depending on the party's level.
If MaterialEx:setTexture() is fixed, then the use cases will indeed be very small, since users that want more water materials can just use the aforementioned onUpdate() hack for textures as well. The only way that wouldn't work is if someone needs to have several different materials with the same shader visible at once, and for the shaders where this issue applies, I can't think of many cases where anyone would need that - I certainly don't . So yeah, probably not worth changing.

petri wrote:btw. component iterator already exists, see crystal_shard_recharging definition for example.

Oh, sorry about that then.