LoG2 Editor features and modding

[Isaac]

The trick to this is that the material reference is located in the model itself. If you don't have the name(s) already defined, then you will need to define the exact material names that the model references. To find out what the name is, you need to open the model in the Grimrock Model Toolkit, and look at the material name(s) assigned. Then define those in the material.lua script.

[Mysterious]

Hi issac yes I can look in the assets pack from log1 and find the textures in the lua file, so I just copy the script bit and the texture to my new mod? I have tried and failed, is it because the new log2 does not recongise the texture names?

EDIT: Sorry about this here is what I did. I placed this code in the material lua file, edited the model in GMT replacing the the models textures and guess what, it take the texture from LOG 2 even though I put the new textures in the folder (textures) I thought it would use the textures that I have in the folder lol. It seems to be taking the texture from the LOG2 system lol. Do I have to change the asset pack in GMT to on Mods folder?

EDIT AGAIN: It's ok I got it to work now thxs for your time issac

Code: Select all

defineMaterial{
	name = "altar",
	diffuseMap = "assets/textures/env/dungeon_altar_dif.tga",
	specularMap = "assets/textures/env/dungeon_altar_spec.tga",
	normalMap = "assets/textures/env/dungeon_altar_normal.tga",
	doubleSided = false,
	lighting = true,
	alphaTest = false,
	blendMode = "Opaque",
	textureAddressMode = "Wrap",
	glossiness = 30,
	depthBias = 0,
}

[Isaac]

We don't know anything about the new assets; the old asset pack mirrors the [LoG1] internal file system... That may not be the same for LoG2... We need to wait for the official Asset Pack for LoG2 to find out.

You might be able to define the original materials manually, as temporary measure... but I don't know if you can distribute a mod using it... You would probably have to use the one in the LoG2 assets, unless AH says otherwise.

[whackangel]

Hello, I have a question that might do with scripting or something : I can't possibly understand why the "wall" items are not only coloured on only one of their 'faces' but that they also are 'collisionable' all the freaking time, even by monsters, even "in game"... do we have to script somehin to make them uncollisionable ?

[Isaac]

Hello, I have a question that might do with scripting or something : I can't possibly understand why the "wall" items are not only coloured on only one of their 'faces' but that they also are 'collisionable' all the freaking time, even by monsters, even "in game"... do we have to script somehin to make them uncollisionable ?

Just place a secret door, and uncheck the 'door' component.

[whackangel]

It's what I'm doing so far but I just don't understand the point of having items such as these walls if we can't use them properly :/

[Isaac]

It's what I'm doing so far but I just don't understand the point of having items such as these walls if we can't use them properly :/

What they are used for is for placing on the outermost walls of the map ~or not.

[whackangel]

Ok then.

I have yet another question (I'm that kind of guy...) : I want to script a deactivation of a force field through the use of torchholders, like this :

function DeactivateForceField()
if torchholder1:hasTorch() == false and
torchholder2:hasTorch() == false and
torchholder3:hastorch() == false then
forcefield:deactivate()
else
forcefield:activate()
end
end
(force some reason I can't make the tabulation appear, sorry for that)
But it doesn't work ! So I'm gessing it's the "deactivate" part that is not correct, I may have to use another term but I don't know which one...
Any idea ??

[Isaac]

function DeactivateForceField()
if torchholder1:hasTorch() == false and

• torchholder1.controller:getHasTorch()
• force_field_1.controller:activate()

[whackangel]

Well I see the specification I had forgot...

Yet, doesn't work quite properly yet :