Ma-Shell

I guess, chroot would be apropriate here? I don't really know much about it but as it allows you to limit the folders a program can see, it sounds like it could be of use here.

You're welcome. Nice to know, I could help. Just two minor things: - At the end of GetForwardVector, you can just return ret without assigning it to forward_vec first (I did this originally because I first had it in a separate function but then I noticed, I wasn't really familiar with some LUA-specific function-things (like e.g. when the first parameter is interpreted as self etc.). So I just took the whole chunk and decided to not put it in a separate function.) - The comment "--The following should actually be done for all entities, not just self.ent" doesn't hold any more.

You can work around this by saving the key's state of the previous frame (KeyDown) and then acting, if the current state is "not down" and the previous one was "down".

Well... "if(angle < angle)"

Well, acutally the part that's responsible for getting the forward-vector is just a matrix multiplication with a vector. I was a bit surprised that LE didn't offer a way to do that but well... I can run through loops myself You are right. This is a 35 degree universal angle

It principally works. There is only one thing: I don't know how to iterate over all entities in LUA, so I only tested against one entity, which I assigned via the editor (self.ent). Here is the code: local forward_vec4 = Vec4(0,0,1,0) local mat = self.entity:GetMatrix():Transpose() --transform ret = Vec4(0) --System:Print(forward_vec[0] .. "," .. forward_vec[1] .. "," .. forward_vec[2] .. "," .. forward_vec[3]) for i = 0,3,1 do ret[i] = 0 for j = 0,3,1 do ret[i] = ret[i] + mat[i][j] * forward_vec4[j] end end forward_vec4 = ret --The following should actually be done for all entities, not just self.ent local diff_vec = self.ent:GetPosition() - self.entity:GetPosition() local forward_vec = forward_vec4:xyz() --calculate angle local dot = diff_vec:Dot(forward_vec) local l1 = math.sqrt(diff_vec:Dot(diff_vec)) local l2 = math.sqrt(forward_vec:Dot(forward_vec)) local angle = Math:ACos(dot / (l1*l2)) if(angle < 35) then -- in cone self.ent:Show() else -- not in cone self.ent:Hide() end I might eventually polish it some time and put it on the workshop, when I find out, how to iterate over all entities

I'm currently trying Posting results, if I get some...

For the following let's call the "looking" object "A". You would have to perform checks for every other entity ("B"), whether the angle between the forward-vector of A and the vector from A to B is smaller than a certain threshold. You can get the angle between two vectors by the following: With "<a,b>" being the dot product of the vectors a and b, "c" being the angle between a and b, |a| being the length of vector a, the following holds: <a,b> = |a|*|b|*cos( c ) thus: c = acos(<a,b>/|a|*|b|) That's how you can get the angle between two vectors. Now there are two things left: - The vector from A to B is simply B.getPosition() - A.getPosition() - The forward-vector of A. I have to admit, I am not really sure, how to get this one. I would assume, you can get it by transforming the vector (0,0,1) with the transformation matrix of A (i.e. multiplying them).

What will work in LUA: Edit the drawimage.shader (the Pixel-Shader): On top add a uniform (don't name it "offset". That one is already used by the vertex-shader): uniform vec2 off change the line fragData0 = drawcolor * texture(texture0,vTexCoords0); to fragData0 = drawcolor * texture(texture0,vTexCoords0+off); Now in your LUA-Script just before the call to DrawImage set this value: imgshader = Shader:Load("Shaders/Drawing/drawimage.shader") if(not(imgshader:SetVec2("off", Vec2(0.1,0.1)))) then System:Print("Value could not be set.") end You will probably want to change the value back to (0,0) after you are done drawing. Edit: (The offset will be set in percent, I think)

I would guess as well that the LUA entity is not directly compatible with a C++-Entity (as Rick suggested). Your screenshot shows that the attributes have some rubbish values. So that object you are inspecting surely isn't a C++-Entity. Maybe there is a bit of an offset needed. I would try implementing the method Rick suggested and then looking at the different addresses the two methods yield and whether they are in any way coherent.

I just uploaded it to the workshop: http://steamcommunity.com/sharedfiles/filedetails/?id=372381915 This will hopefully make it more easy to integrate this into your project. All that has to be done now is the assignment of the script to the camera and the removal of the current render-code (as written on the workshop-page).

Oh, I see. I quickly translated it to LUA (and removed the reprojection-approach). You'll find Instructions on the README.txt included in the zip. At the moment, the rendering is done in the WorldUpdate-Function which is probably not optimal. Feel free to move it anywhere more suited Have Fun stereo_lua.zip

Also note that using the "real" mode will cause your fps to drastically go down which is by the nature of the thing since the world has to be rendered twice. The reprojected stereo followed a different approach which was meant as a pure post-processing-effect to recreate the two images from one image and its depth-image. This has a significant performance advantage against the former one. There are scientific papers out there that describe the approach, so it is possible to create decent looking 3d-images with that one, but at some point I just didn't have the time to continue that one and as it is now, it isn't really good.

Hi, I did this once for c++. You can find the files in the attached zip-folder. You can just add them to your c++-Project. What you have to do to make this work: Put the files StereoRender.cpp and StereoRender.h into the folder containing your Source-files and the shader-files into the Shaders/PostEffects - folder. In App.h: #include "StereoRender.h" In App.cpp: in App::Start() (Just put it at the end before the return statement): (Actually there are some more parameters to specify e.g. the nearplane and the farplane that have a default-value. If you want to play with those, you can find them in the StereoRender.h) StereoInterlaced::PrepareStereo(context, camera); in App::Loop() (Between "world->Update();" and "context->Sync(...);") StereoInterlaced::CheckStereoKeys(window); StereoInterlaced::RenderStereo(world, camera); StereoInterlaced::DrawStereoOffsetText(10, 220); CheckStereoKeys will check the numpad keys "-" and "+" which control the offset, "/" and "*", which control the angular offset. Also the Tab-Key is used to turn on/off stereo and F1 is used to reload the shaders (you shouldn't need this one if you don't modify the shaders). Shift is used to switch between the "real" 3d using two renderings and a (more or less failed) try of having a reprojected stereo. The latter one will most likely only cause headache but I included it because I was to lazy to cut it out now . It is quite a challenge to find the most suiting values for the offset and the angular offset so you will need to play around with these and find something that suits you. DrawStereoOffsetText will draw some info like the values for Angular Offset and Offset. Have Fun and please tell me what you think about it stereo_render.zip

There was no one who asked for a program to detect that. The only thing that was asked was that one could also get a chance to force the editor manually to include those files, which was implemented now by the option to not use the new selective inclusion

Maybe you didn't save your changes before running?

Whenever you change your code in C++, you have to recompile it in VS (Debug and Release) to see that changes. When you change things within your map in the LE-Editor, they should actually be loaded automatically. Maybe you forgot to save your map each time before you tried to run? If I remember correctly, the editor doesn't save automatically when you run, so you'll have to do that yourself.

Sometimes it isn't even possible to determine the resources loaded by code beforehand because the string containing the path is built up dynamically like the LOD-system I described earlier in this thread. You should definitely give the user a way to override the results of the automated process.

Wow . Multiple 500 GB-folders form up a 20 GB project... That's what I call compression

Although Aggror already answered the original question here is the reason, why your version didn't work. Your original formatstring said "nivel%03d.dat". The "0" means fill with zeros to the left, so it would have meant "nivel001.dat". For more info on Formatstrings refer to: http://www.cplusplus.com/reference/cstdio/printf/

Josh is the creator of the engine. I guess he put some absolute path there. Strange...

What I actually wanted to say is that I thought, your prompt ended with the path and the $-sign was somewhere in the middle and not in the end (otherwise there would be no sense in calling the program with "./". Nevermind^^ The backtrace also shows that this origins in fglxr_dri.so (the ATI-driver). Did you check, whether your card is supported? Also I know there is an issue with the current Windows-Drivers for ATI resulting in a pure virtual function call. Maybe they did the same mistake in the Linux-drivers? For more information on the Windows-Driver-Issue see: http://www.leadwerks.com/werkspace/topic/11181-r6025-pure-virtual-function-call

I would guess that is a permission issue. Maybe the files belong to root or anything different and you may not access them. btw. Is that path in the first row of your listing part of the prompt? I have never seen the $ anywhere inside the prompt. It should always be at the end... Just my thoughts

How are you trying to determine the position? Likely your problem is caused by the fact that all CSG gets collapsed unless they have a script attached or a mass.

Well, you could also load stuff by code which would be way harder to detect or sometimes even impossible (e.g. if there is no direct string to the path of the resource since you combine the path from multiple different strings. This could be the case, if you have some sort of a LOD-system, where you first have the name, then add the LOD-level and then the file extension, like barrel_lod2.mdl). I agree though, that there should be some kind of a dialog where you can choose what resources should be included and what shouldn't.