Haydenmango

I am having this issue with a new project I am working on as well. It seems like this was a recent change because I remember being able to rotate without using movement in the past. Side note: I wish there was more detailed documentation on the Character Controller. It is one of the features of leadwerks that I use the most and have the most trouble with. Learning about the character controller is through trial and error or hunting down information as the tutorial for it doesn't mention detailed information about all of its perks and quirks. Things like the x and z rotation being locked, physics shape being preset and unable to be changed, a list of all of the script functions that work/don't work character controllers, etc. would be useful information to have all presented in one place.

Steps to reproduce: Create Project Place heathaze.pfb, smoke.pfb, and softsmoke.pfb into the map with heathaze.pfb in front of the smoke and softsmoke particle emitters. Turn on Realtime Rendering

I found that my character controller slows down drastically (almost to a complete stop sometimes - seems to be dependent on how fast I am moving) when moving on slopes above 30 degrees. I understand the character controller can't move on slopes>=45 degrees but slowing down > 30 degrees seems like a major bug. For example when moving down a steep slope I move slower! I can provide more information/my project and could make a video showing the behavior if it's needed.

Yeah, I thought that re-using the vegetation billboard system would be good enough for a lot of cases. I do think a new LOD system that uses 3d models would be great as well because as gamecreator pointed out a lot of vendors sell LOD versions of their models but I'm not sure how to go about setting that up (maybe add LOD model versions directly into the .mdl files and use them when necessary).

Almost every game these days uses LOD in open environments to keep performance steady and reduce pop-ins. I would like an LOD system (similar to the current system in use by the vegetation system) that can be easily applied to any entity. I suggest adding a 'Enable LOD' checkbox as well as 'View Range' and 'Billboard' sliders to the appearance tab. When the 'Enable LOD' checkbox is checked an LOD texture should be generated and LOD shaders applied to the specific entity (similar to how adding new vegetation to the vegetation tab works) and the entity should be affected by the LOD system. When unchecked the LOD texture can be deleted, LOD shaders removed from the entity, and the entity should no longer be affected by the LOD system. 'View Range' and 'Billboard' should affect LOD viewing distance just like the vegetation system.

I completely agree. I have never understood why the official bloom+godrays shader looks so over the top (it's completely ridiculous unless you turn the values waaayyy down) but it seems shaders have never really been the focus judging by how people need to create custom shaders just to have alpha in an animation shader. Hoping to see shadmars shader pack back up soon as it has become a very important addition to leadwerks to me!

Macklebee helped me figure this one out. I had this as my window creation line - self.window = Window:Create(self.title, 0,0,self.resolutions[self.rescounter].x,self.resolutions[self.rescounter].y,64) then I changed it to this and now it works! - local windowstyle=window.Titlebar windowstyle=windowstyle+window.FullScreen self.window = Window:Create(self.title, 0,0,self.resolutions[self.rescounter].x,self.resolutions[self.rescounter].y,windowstyle)

Yeah, I just checked and it is still happening.

lol I totally forgot about that! Thanks for reminding me Genebris, disregard this suggestion.

I would like to have an option on the vegetation tab in the editor to change pick mode of a specific vegetation layer on or off. Right now vegetation seems to always have their pick mode set to PolygonPick which means that even transparent vegetation will be in the way of anything obscured by it. This can create bad situations where usable items that end up in bushes are stuck because the player can't pick them up.

Ever since a recent beta update my games window will not render. http://www.leadwerks.com/werkspace/blog/1/entry-1746-beta-update-available/ I saw that this was an issue others were having as well and that it has been supposedly fixed. http://www.leadwerks.com/werkspace/topic/14952-contextgetwidth-contextgetheight-no-longer-return-valid-info/ My game window still will not render if I use the beta and I can't seem to find out why. I can revert to the current build and my game window renders correctly. There are no errors being shown and everything is loading the same way as far as I can tell. I am using the Indie Edition and I can provide my project if needed. Link to a video I made to show my issue -

Looking forward to checking out the increased animation performance but my game isn't starting up correctly, probably due to the context bug others are experiencing. I'm always trying to improve performance in my games so I love seeing updates like this!

Thought this would be easy enough to reproduce, took me 5 minutes to set this all up. Anyways here is a link to a video I made demonstrating how to recreate the water reflection bug - and here is a link to download the map I used in the video - https://www.dropbox.com/s/iexvfor1bki658v/vegetationtestmap.map?dl=0 note: you will need your own vegetation objects. edit: my gpu is a geforce gtx 960m

I posted this a long time ago - http://www.leadwerks.com/werkspace/topic/13879-bad-water-reflections-with-vegetation-system/ Same issue is still prevalent.

Out of the two options I personally would move out to the midwest. I found being in a relaxed atmosphere makes me more productive because I don't get burnt out from all of the stress surrounding me. You do need to be proactive to make sure you don't fall into a lull though. I hope you find a place that feels like home!

Hey Angelwolf, sorry for the delayed response. This is a pretty old script so there may be something else wrong but did you add: Script.maxammo=200 --int "Max Ammo" into the FPSgun.lua? I have a feeling the crash is because the max ammo value is nil until you add that in.

You could be limited to 60 fps due to V-sync being enabled. You can change this through code using the context:Sync() command. More info - http://www.leadwerks.com/werkspace/page/api-reference/_/context/contextsync-r48 You will find the Sync() command somewhere in the Main.lua by default. If you find context:Sync(true) then change it to context:Sync(false) to disable v-sync and then you should be able to get above 60 fps if your scene isn't to complex.

Does your game crash immediately when GetPosition() is called or does it happen after some time? I am curious because I am using GetPosition() in my UpdateWorld() function and my game doesn't crash immediately but I have been getting inconsistent crashes when playing my game lately. Anyhow, I switched back to the 2015-12 build of leadwerks to see if I still get inconsistent crashes and I need to do more testing to see if switching the build makes any difference in my case.

Try un-checking "Only include used files" when you publish your game.

Hey everyone I had an idea this morning and it seems like it worked! What I did to the ssao shader was very simple and it seems to work as intended. I just thought I would share this because I found it useful. If there are any issues let me know. Credit for the original ssao.shader goes to Igor as well as Josh and Shadmar. The original ssao.shader can be found here - http://www.leadwerks.com/werkspace/page/viewitem?fileid=393925036 Also, before doing this I recommend saving a back up of your ssao.shader just in case. In the Fragment section of the ssao.shader replace the main loop with this - void main(void) { float depth; float lineardepth; vec2 pixelsize = 1.0 / buffersize; vec2 texcoord = GetTexCoord(); depth = texelFetch(texture1, ivec2(texcoord * buffersize), 0).x; if(depth < 1.0) { lineardepth = DepthToZPosition(depth); if(lineardepth < 62.5) { vec2 rotationTC=(texcoord*buffersize)/4.0; vec3 vRotation=normalize((texture(texture10, rotationTC).xyz * 2.0) - 1.0); mat3 rotMat=vec3tomat3(vRotation); float fSceneDepthP = DepthToZPosition(depth); float offsetScale = aoscale; float offsetScaleStep = 1.0 + 1.5 / samples; float ao = 0.0; for(int i = 0; i < (samples / 8); i++) for(int x = -1; x <= 1; x += 2) for(int y = -1; y <= 1; y += 2) for(int z = -1; z <= 1; z += 2) { vec3 vOffset = normalize (vec3(x, y, z)) * (offsetScale *= offsetScaleStep); vec3 vRotatedOffset = rotMat * vOffset; vec3 vSamplePos = vec3(texcoord, fSceneDepthP); vSamplePos += vec3(vRotatedOffset.xy, vRotatedOffset.z * fSceneDepthP*raycasts); float fSceneDepthS = DepthToZPosition(texelFetch(texture1, ivec2(vSamplePos.xy * buffersize), 0).x); float fRangeIsInvalid = clamp(((fSceneDepthP - fSceneDepthS) / fSceneDepthS), 0.0, 1.0); ao += mix(clamp(ceil(fSceneDepthS - vSamplePos.z), 0.0, 1.0), 0.5, fRangeIsInvalid); } ao /= samples * 1.5; fragData0 = vec4(clamp(ao + ao + ao * 1.22, 0.0, 1.0)); } else { fragData0 = vec4(1.0); } } else { fragData0 = vec4(1.0); } } To edit the distance cutoff range just change 62.5 in lineardepth < 62.5 to a different float value.

Thank you all! Staying motivated has been extremely hard being alone in development. All I do everyday is code, plan, and research for my game. I dream about what I am going to be working on the next day or how to fix certain bugs. I don't leave my house very often and don't give myself social time. I get very little feedback so I really have to push myself to do anything. The only thing that keeps me productive and sane is listening to music. haha

I will share a bit of the past of Hunt For Food before going on to the future. Hunt For Food has been an ongoing project that I have worked on for nearly two years now. I started with the idea of making a survival game and realized I was biting off more than I could chew pretty quickly. Instead of giving up and working on smaller games I decided I would use this one project for my game development education. The main reasons why I decided to work on one big project were: - I had no money or skill to get game assets to make multiple unique games. - I had time to focus on a long term project. - I had dedication to my idea and education. Now onto the Future! After coming up with a recent concept for Hunt For Food I started changing, adding, and removing things like I always do but this time I really felt my ideal game coming together. So I punched into overdrive working at least 10 hours a day on the game for the past two or three weeks. The game is much more developed now and I really can't wait to share it with everyone. The future of Hunt For Food is looking good and it feels great. I am working on getting this epic update onto the game launcher as soon as possible; there are just a few more details to work out. I will also be making some videos to show how everything works. The next step is to get Hunt For Food Greenlit on Steam which would just be unreal. It's been a long development but there has been a lot of progress so things even out I suppose. Thanks for reading! Keep an eye on Hunt For Foods development here - https://trello.com/b/mQ8xjWgN/hunt-for-food-development-board Hunt For Food on the Leadwerks Game Launcher - http://www.leadwerks.com/werkspace/page/viewitem?fileid=507073173

Strange, it seems to be loading fine for me and I am in the beta. Was there a fix or am I lucky?

I really like the idea of easy to use networking. Also, making Leadwerks like a moddable game is great! It would be awesome to see everyone modding each others games. Some things I would like to see in the future are improvements to water (allow multiple planes of any size, easier to tweak graphic values, rivers!), physics improvements, LOD support for normal entities (animated characters,buildings, etc.), and more shader tutorials. I've been really impressed and happy with the new features, keep up the great work Josh!

@xtom That is a very valid concern. Making it an option on each entity (like the hidden option) to disable physics when hidden/out of view range may be the best idea then to avoid all the checks. Then if you have an object that relies on physics always being active you can keep it that way.