Rick

Wouldn't you run into the same issues with LE that Unity has in that creating entities on a thread other than the main thread won't work? I seem to recall others running into this issue with LE.

With Lua you can use coroutines to simulate threads. Basically you can split out the task of generating all these things over a longer period of time without blocking the main game. If you aren't familiar with coroutines, they maintain state inside a function that you can yield out of and resume back into. So basically if you were looping through some list you can yield out after a set amount of time is reached and when you resume back in you'll start where it left off. Of course Unity has coroutines also so maybe you deemed them not good for this?

Please provide the error.

Would it help if you stood up and simulated walking at all?

[ and ] keys change the units of the grid for csg.

Your 2D drawing functions have to be after world->Render() and before context->Sync(). world->Render() draws the 3D world so if you draw 2D text before that the 3D world drawn gets drawn over your 2D text so it's gone. What you want is to render the 3D world first and then draw the 2D on top of that.

Random wandering can be tricky to get right and make it look good/real. You can either place waypoints around your map and have the monster walk to a waypoint in which you randomly picked which waypoint for him to go to. Or you can randomly pick a point above the world and raycast downward until it hits something that is reachable by the monster and then have him walk there. The first method you know will work without issues. The second method has more checks to make sure you are picking places the monster can actually get to and while less setup work (no need to define waypoints (pivots)) could lead to unknown bugs.

Maybe try playing around with the material of that torch. Open it in the material editor and you have colors and stuff there that you can also play with.

I offer Lua training that would help you get to understand how this stuff is working. $10 USD/hour. Send me a PM if interested and we could setup some time. Even 1 lesson often helps people understand how things are setup and how things work.

I vote these should be 2 drink min from now on.

I was thinking if you have 3 moving speeds and know those speeds and what speed a character is in you can just hardcode the jump boost based on those 3 speeds. speed 1 = 5 boost, speed 2 = 7 boost, speed 3 = 10 boost or something.

Not much is safe in the world of interpretation. People can easily decompile Unity 3D code. I knew nothing about how to do it and in about 5 mins I did it with The Forest game on Steam. Not much can be hidden.

Yeah, I've used that before. Was trying google drive to get a more real time feel and less steps (as in none), but we'll probably have to switch over since LE does some funky things even though we aren't colliding in the maps.

We're using GoogleDrive and it totally screws the maps up. It constantly copies maps with (1) or [conflict] in the name. It's a pain.

The editor crashed on us from some prefab and now the lighting is wrong. So in this map there is a csg box with the inside hallow. The ambient light has been turned to 0. Inside the box should be completely dark and it was before the crash. I have 3 directional lights in the scene but this doesn't matter in a new project. The light shouldn't be penetrating inside. If I disable 2 of the directional lights we then we it 100% dark inside, but this shouldn't matter. What is going on? The crash clearly broke something. rick_test.rar

I'm not seeing this issue.

When I unsubscribe workshop items under AddOns the folder stays but the stuff inside is gone. When I try to delete the folder from LE editor it says it failed to delete the folder.

So with this shader code: tileselect.x = tileselect.x * 255.0; tileselect.y = tileselect.y * 255.0; tileselect.z = 1.0 / (tileselect.z * 255.0); outcolor *= texture2D(texture0,vec2(ex_texcoords0.x*tileselect.z+tileselect.z*tileselect.x,ex_texcoords0.y*tileselect.z+tileselect.z*tileselect.y)); With the model Appearance->Diffuse of (1, 1, 2, 255) (alpha ignored anyway) and brightness set to 1 it looks like:

Ah OK, so that answers that mystery. They weren't all 255 in the material editor for some reason. Change that makes it work correctly when I attach a script to the model and call self.entity:SetColor(). However, from Appearance->Diffuse it still doesn't seem to work with values like (1, 1, 2).

The way I originally used it a year ago was via entity:SetColor(). This time I need to use it via the editor. My assumption is that entity:SetColor() = Appearance Diffuse color via the editor when a model is selected. So today since I'm trying to use the Appearance Diffuse color of a model I'm converting back from 255 since my assumption is the editor is taking whatever value is in those fields and dividing by 255 and that's what's getting sent to the shader. Doing it via the level editor Appearance->Diffuse setting doesn't produce the correct results. Why would that be?

So if I just isolate this to the z value I find it interesting. If the blue (z) value in the diffuse editor is set to 2 then in the shader tileselect.z = 1.0 / (tileselect.z * 255.0); produces the same result as if I did tileselect.z = 1; In that I see both textures in the first column in the atlas on the model Somehow the formula is setting z to 1 instead of 0.5. I must be missing something basic here. What do you mean material editor? I need to do this via the model color in the level editor (SetColor()). I thought that is how I did it before. If not is there a way to get the model color data into the shader? Looking at my old code I'm calling SetColor() on the model itself not the material as the changes need to be done via model level. In the level editor when I have the model selected under the Appearance tab in the Diffuse section is where I'm modifying my values for testing and the blue value does change the scale (not to what I'm expecting though) but red & green don't seem to be doing anything.

That didn't seem to make any difference when I made the change.

There is no comparison being done. The value is just used for offsetting the giant texture so although 1.99 isn't 2 it's close enough for the texture offset.That's my understanding anyway. // save off the color values as they really are used for texture offset vec4 tileselect = ex_color; vec4 outcolor = ex_color; // set everything to 1 for color, which means we lose SetColor() functionality but I never use that anyway outcolor.x = 1.0; outcolor.y = 1.0; outcolor.z = 1.0; // testing purposes //tileselect.x = 0.0; //tileselect.y = 1.0; //tileselect.z = 0.5; // the editor divides the diffuse color by 255 so we'll multiply it back out to allow us to enter valid row/col values tileselect.x = tileselect.x * 255; tileselect.y = tileselect.y * 255; tileselect.z = 1 / (tileselect.z * 255); vec4 color_specular = materialcolorspecular; //Modulate blend with diffuse map //outcolor *= texture(texture0,ex_texcoords0); outcolor *= texture2D(texture0,vec2(ex_texcoords0.x*tileselect.z+tileselect.z*tileselect.x,ex_texcoords0.y*tileselect.z+tileselect.z*tileselect.y)); But again, entering a value of 0 or 1 in the editor doesn't change the visual of the model texture. If I comment the multiply by 255 code above and uncomment the texting code where I hardcode 0 or 1 then it works, but of course then it's not by model which is the requirement. This leads me to believe something about the x, y, & z values is not what I'm expecting. Below is the entire frag shader. #version 400 #define BFN_ENABLED 1 //Uniforms uniform sampler2D texture0;//diffuse map uniform sampler2D texture1;//light map uniform vec4 materialcolorspecular; uniform vec4 lighting_ambient; uniform samplerCube texture15; //Inputs in vec2 ex_texcoords0; in vec4 ex_color; in float ex_selectionstate; in vec3 ex_VertexCameraPosition; in vec3 ex_normal; in vec3 ex_tangent; in vec3 ex_binormal; out vec4 fragData0; out vec4 fragData1; out vec4 fragData2; out vec4 fragData3; void main(void) { // save off the color values as they really are used for texture offset vec4 tileselect = ex_color; vec4 outcolor = ex_color; // set everything to 1 for color, which means we lose SetColor() functionality but I never use that anyway outcolor.x = 1.0; outcolor.y = 1.0; outcolor.z = 1.0; // testing purposes //tileselect.x = 0.0; //tileselect.y = 1.0; //tileselect.z = 0.5; // the editor divides the diffuse color by 255 so we'll multiply it back out to allow us to enter valid row/col values tileselect.x = tileselect.x * 255; tileselect.y = tileselect.y * 255; tileselect.z = 1 / (tileselect.z * 255); vec4 color_specular = materialcolorspecular; //Modulate blend with diffuse map //outcolor *= texture(texture0,ex_texcoords0); outcolor *= texture2D(texture0,vec2(ex_texcoords0.x*tileselect.z+tileselect.z*tileselect.x,ex_texcoords0.y*tileselect.z+tileselect.z*tileselect.y)); //Normal map vec3 normal = ex_normal; //normal = texture(texture1,ex_texcoords0).xyz * 2.0 - 1.0; normal = texture(texture1,vec2(ex_texcoords0.x*tileselect.z+tileselect.z*tileselect.x,ex_texcoords0.y*tileselect.z+tileselect.z*tileselect.y)).wyz * 2.0 - 1.0; float ao = normal.z; normal = ex_tangent*normal.x + ex_binormal*normal.y + ex_normal*normal.z; normal=normalize(normal); //Calculate lighting vec4 lighting_diffuse = vec4(0); vec4 lighting_specular = vec4(0); float attenuation=1.0; vec3 lightdir; vec3 lightreflection; int i; float anglecos; float diffspotangle; float denom; //One equation, three light types /*for (i=0; i<MAXLIGHTS; i++) { attenuation=1.0; //Get light direction to this pixel lightdir = normalize(ex_VertexCameraPosition - lightposition[i].xyz) * lightposition[i].w + lightdirection[i] * (1.0 - lightposition[i].w); //Distance attenuation attenuation = lightposition[i].w * max(0.0, 1.0 - distance(lightposition[i].xyz,ex_VertexCameraPosition) / lightrange[i]) + (1.0 - lightposition[i].w); //Normal attenuation attenuation *= max(0.0,dot(normal,-lightdir)); //Spot cone attenuation denom = lightingconeanglescos[i].y-lightingconeanglescos[i].x; if (denom>-1.0) { anglecos = max(0.0,dot(lightdirection[i],lightdir)); attenuation *= 1.0 - clamp((lightingconeanglescos[i].y-anglecos)/denom,0.0,1.0); } lighting_diffuse += lightcolor[i] * attenuation; }*/ //outcolor = (lighting_diffuse + lighting_ambient) * outcolor; //Blend with selection color if selected fragData0 = outcolor;// * (1.0-ex_selectionstate) + ex_selectionstate * (outcolor*0.5+vec4(0.5,0.0,0.0,0.0)); //fragData0.xyz = normal*0.5+0.5; #if BFN_ENABLED==1 //Best-fit normals fragData1 = texture(texture15,normalize(vec3(normal.x,-normal.y,normal.z))); fragData1.a = fragData0.a; #else //Low-res normals fragData1 = vec4(normalize(normal)*0.5+0.5,fragData0.a); #endif fragData1.a = materialcolorspecular.r * 0.299 + materialcolorspecular.g * 0.587 + materialcolorspecular.b * 0.114; int materialflags=1; if (ex_selectionstate>0.0) materialflags += 2; fragData2 = vec4(0.0,0.0,0.0,materialflags/255.0); }

I'm trying to figure out what diffuse color values are coming from the editor to the Fragment shader. My assumption is that the editor is dividing whatever value is put in by 255 to get a value between 0 and 1. So I would think if I multiply by 255 in the shader I cold get the original value. ie. if I put 2 in the editor for red then the editor is doing 2 / 255 and then sending .0078 to the shader. Then if I multiply that by 255 I should end back up with 2. However this doesn't seem to be the case in the expected result I'm seeing (doing an atlas shader) vs when I just hardcode the red value of 2 in the shader itself. So was hoping to see these values in order to see what is going on. Unless anyone with shader experience has an idea on what is happening off the top of their head. Maybe the precision getting sent to the shader can't handle such low values so maybe 1/255 is just getting sent as 0 and so multiplying it by anything obviously isn't going to do anything.

Is there a way to print out values inside a shader to the output window? I'm curious to see some values in the fragment shader.