reepblue

Try this, edit pivot.mat to load pivotupdate.tex and compare the two. It looks kind of dumb as the top is shorter than the rest. Ehh.. Looks fine.. I'll send the final final version to Josh, for now try that. Let me know how you like over the one that's in the build now.

Hi TJ, I've had a quick chat with Josh about this during the hangout before I had to go. Although this is only a slight annoyance, I'm kind of bothered by it myself. The issue is that where the three points meet doesn't line up to the center of the image. My first idea would be to add a dot/an x to represent the origin of the pivot. I'll take a look at this by the end of the weekend and I'll post alternates to address this, so stay tuned!

I do use the collision hook for adding objects to the touch list. It's removing the object from the volume is my issue. I tried the Enter/Exit trigger script on the old wiki, but it only detects if all objects are out. I'm also using list because vector doesn't seem to have a way or removing an object from it.

I think setting multisampling to 0 should fix the issue. But it's an "abandoned" implementation due to lack of support for post process effects. But if Josh didn't take that stuff out, you can use that for the time being.

Hey all, I've created a trigger class that on touch stores the entity in a list, and checks a listed entity left the bounds in UpdatePhysics. The code I have works fine, but I'm running into an issue that it seems that the extra padding for brushes are causing incorrect values. The entity has to leave the volume, plus a few centimeters for the onendTouch function to be called. Here is the UpdatePhysics code. void SimpleTrigger::UpdatePhysics() { if (!m_bEnabled) return; if (!m_bHadCollision) return; if (m_hTouchingEntities.size() <= 0) return; list<Entity*>::iterator iter = m_hTouchingEntities.begin(); for (iter; iter != m_hTouchingEntities.end(); iter++) { // zentity is the entity where looking for. Entity* zentity = *iter; if (zentity) { if (entity->GetDistance(zentity) > entity->GetAABB(Entity::GlobalAABB).size) { onendTouch(zentity); break; } } } While this works really well, again, I think the extra AABB padding is getting in the way. I also feel that the for loop is a bit over the top/expensive way of doing this. Any help to make this work better would be appreciated! Thanks.

Thanks man, If your interested in the newer project, please take a look at this blog. In the next version, I'll probably not be releasing a lot of scripts and such so the engine can continue to update without conflicts. Glad it helps.

Add: $(LeadwerksHeaderPath)\Libraries\glslang to the included directories listing.(C++ -> General)

Hopefully you can increase the hangout limit. I heard that some people couldn't join the last one cause it was full. I'll try to be there.

Fixed, When it comes to game assets, I don't see the word "cheap" negatively, but I see your point.

It's now on the workshop, hopefully this will help people with their water issues. http://steamcommunity.com/sharedfiles/filedetails/?id=699303085

Gonna convert this to C++, thanks. Mine acted like a editor camera so this should be better.

Here is a water material I've made. Apply it to a face of a box brush and set the collision type to trigger. You also need to add this script to it so it animates the normal map. This is based off an old script Shadmar made but it checks what face the water is on. Just make sure self.Material is the same as the material you've placed on your face. It uses probe reflections so it's very inexpensive when it comes to that. -- Make this the material you used on your face. Script.Material = ""--path function Script:Start() self.textures = { } -- Fetch workshop animated water normals for x=0,9,1 do local name = "water1_"..x..".tex" self.textures[x] = Texture:Load("Materials/Effects/Water/"..name) end for x=10,63,1 do local name = "water1_"..x..".tex" self.textures[x] = Texture:Load("Materials/Effects/Water/"..name) end -- Load material self.mat = Material:Load(self.Material) -- Only apply the water texture to the face where we've assigned it. if self.entity:GetClassName()=="Brush" then tolua.cast(self.entity, "Brush") System:Print(self.entity:GetFace(0):GetMaterial()) if self.entity:GetFace(0):GetMaterial() == self.Material then self.entity:SetMaterial(self.mat) end end self.index=0 end function Script:UpdateWorld() -- Animate normals for texture1 for material if self.index > 63 then self.index=0 end local count = 0 self.index=self.index+Time:GetSpeed()*0.25 count=math.floor(self.index) if self.mat ~= nil then self.mat:SetTexture(self.textures[count],1) end end cheepwater.zip

Thanks.

I remembered the only reason that the option would be grayed out would be if there was no probe. But after making a simple level, adding objects, etc, I can't rebuild GI at my will the option is grayed out. I've tried: Saving the map, and reloading it Moving the probe around Making a new probe Reloading the map after a restart of the editor. All I did was make a boxed room, add a skybox and a few props. It used to work fine before.

I gotta agree with xtom and Crazycarpet. I was stoked to see the banding issue fixed, but I still see banding with the spotlights, just less of it. So I might just remove banding in the point light and the directional light if I get to a point where the grain is very visible. But great update overall. Really happy we have reflections now.

Updating a game will probably never be painless. However, if we don't update our games, we get nagged by a dialog box to update our game until we do. That might mean a lot of work of reverting some script files, updating shaders, etc. Personally, I'd be happy with a flag to disable the dialog box in the cfg.

Why not include (or convert the common into) a skeleton project that just has the needed files to get the engine to run? C++ user's are most likely going to ignore the scripts and if you edit the existing ones, it might get overwritten in an update. You can make a template hierarchy system in the werk flie. This way you can have multiple templates installed in one project if you wanted too. Would allow much more flexibility for custom templates. Just allow the "Template" entry to read more than one value. Then you can split the core engine components (shaders, executables) in one template folder, and make a new folder (Called SDK maybe) and place the scripts, and vegetation models in that template. to make the current 'blank' template, in the werk file do: Template="Common|SDK" For the FPS template, it'll look like: Template="Common|SDK|Advanced First-Person Shooter" And if you just want the core elements: Template="Common" Just my suggestion. Another way is to just customize the templates folder to your needs, but official updates will cause conflicts. So you'll have to disable updates until you're ready to hand update it again.

I recommend this topic. Josh helped me save a big frame dip in this topic.

Close the window, or have a global bool set to true on start up, then have a script make it false. in Main.lua in the while loop: if running == false then return end Example: -- Quit the game! running = false

It's been over a year ago since I've released the Vectronic Demo using Leadwerks. The demo was composed of assets I've made ported from the Source Engine and my lack of understanding of the API and lua scripting at the time. (I'm used to coding everything in C++) As of writing, it has 1,221 subscribers on the Steam Workshop, 25 out of 26 positive ratings, and is the second most subscribed item! So there is sigh that this as a MVP (Minimum Viable Product) was a success. And again, the Game Launcher is in Beta.. Since the demo, the engine got a lot of improvements and features, and I've learned a lot more about game development in general. (Models, Texture making, etc.) Last summer, I sat down to develop a base application for my projects. I wanted the world, context, and window management to be out of the way while making the full game, and I was concerned about a UI as it was a sticking point when I did a Source branch change from the 2013 SDK to the Alien Swarm Branch in favor of better development tools. (That engine is really fragmented when it comes to things like that....) Once I finished that application; LEX, I then started over developing the game using that template. Two months went by, I've done some interesting puzzles in dev textures.but I felt that one element was taking over the vecball power elements. It was more fun to use that than fire balls at boxes. (And it was more work than the Vecballs) So, I paused development on that project to research if that 'thing I added' would be a better focusing point. I only spent a week on it. I didn't want to work on it too much, just enough to see if it'll work. It turned out, that minus some placement calculation, it was really fun. As you can see, I don't want to talk about it in-case I decide to go with it. November was approaching again, and it's a special time for me. In 2010, I released my Portal mod Blue Portals with mostly positive reviews. Every November, I like to do something to give a reason for people to revisit it. Last year (2014) I fixed the mod so it'd work with the steampipe update, and last November, I decided to put the mod on Steam as an "Anniversary Edition" Although we had massive support about Blue Portals on Steam, there was things I wasn't happy about, and prevented me from putting it on Steam earlier. Some things didn't age well and I've made some poor design choices. There was also some criticism over the difficulty curve (which is kind of common with Portal mods), and somethings just broke. I can spend a few months patching it up, or I can take the extra time and reevaluate the entire project, and have it be a quality mod on Steam. Plus, if the difficulty curve was adjusted, more people can actually play it! This first started as a revamp project, but slowly became it's separate entity with it's own needs. I'm learning a few new things I've haven't known before, and it's interesting how some concepts/techniques I've learned using Leadwerks came into play here. I was first very worried about Vectronic being on the back burner, but then I realized that it's actually a good thing I take a break from Vectronic for the following reasons: I can experiment with marketing, community management, updates with little to no risk. I can try something and see how it goes and decide what I did right and/or wrong with that decision and use it in the future. I can get used to Steamworks, and have an idea going into Steam Greenlight how it's gonna be, which is a plus over most indie devs who need to take time to learn that stuff. Blue Portals: Anniversary Edition can be/will be used as an advertising piece for future projects, I can comfort future consumers with an example of our work before they vote on Greenlight or purchase it on Steam. I was really unsure where to take the project, so coming back with a clear head would help. I have a bunch of ideas now, but not gonna jump into anything now. I see the Blue Portals: Anniversary Edition project (BPAE) as a stepping stone for marketing and consumer confidence. Since the mod can be downloaded with zero risk to a consumer, I feel better taking chances with it then I would a product I'd wish to sell. So what's the battle plan? Continue to develop BPAE. I'm aiming for a December release. Since most research and development have been conducted five years ago, I think if my team and I keep working at it, we can have a polished product on Steam which in return can help sales with Vectronic. I plan on starting to experiment with Marketing next month. I really want to find that "How Early is the right time to show?" mark. My first guess is "When the project has an established direction, but nothing is 100% final just yet.". Which for this project is short of 6 months of development. Continue to chip away at LEX2 as it's going be the new foundation. Unlike it's predecessor, the solution is very minimal and allows for easy C++ entity implementations. I want to participate in the next Tournament using it to make sure it's all solid and good. When BPAE is wrapping up, start programming the yucky gross parts like the player and some custom collision rules. Start thinking how everything will tie together and use the new things I learned with BPAE while making design and development choices. I think doing this while BPAE becomes a touch up project will allow me to not feel like I'm doing the same things on two projects. Start the true cycle of development for Vectronic once BPAE is submitted to be released on Steam. So that's the plan. Taking this one at a time. I'll keep you posted on what I'm doing like always. Although Blue Portals: Anniversary Edition isn't a Leadwerks project, I still think me writing my findings with it can benefit others while making their games. We're all learning here!

Pivot* pivot = Pivot::Create(); pivot->SetScript("Scripts/MyCoolScript.lua");

When will we be receiving these improvements? I noticed the lighting shaders where updating, but the banding still exists. EDIT: it seems that on the left wall of 02-FPS Controller, you can see the left wall, the banding isn't apparent, but the right wall, the banding is still noticeable. Weird part being is that the spotlight is centered, but only one side has the banding.

There is Entity->SetScript(string). I use it all the time, and the bulletdecal script uses it. You can also just make a "C++ Script" class too. Networking isn't officially supported, but a lot of people got Multiplayer games to work.

Different brand? I know when I switch from AMD and Nvidia, I always saw a brightness/contrast level difference in games.

For the past few months, (on top of working on my greenlit mod) I've been developing a new foundation for Vectronic that will take care of all the 'internal yucky bits' such as window/context/world management, and other features and functions. I really wasn't happy how the first implementation came out as I felt like I was taking too much from the developer, and it was messy and confusing to do something simple like adding a loading screen. LEX2 is more lua friendly, not bloated with scripts that you may or may not use, and has more comments than my Blue Portals 2 video in the code! You just need the executables, App.lua, and engine.pak which contains standard assets that the application will call if something is missing. You can play with it here. I've used the latest beta with probes so if you don't have the probe beta, don't load map 07 I guess. Here are somethings you might notice looking at scripts or general usage. Developer Console: LEX2 comes with a developer console for visually debugging your game while you play. Draw stats, show physics, show navigation, or change settings on the fly. All commands use the standard system properties. To access the console, the game must be started with -dev or launched from the editor. When the game is paused, it the tilde key (`) and start typing. Hit Enter to submit your command. You can use PageUp and PageDn to scroll through pass commands. You can type 'help' to report a list of current commands. There is no display box, so it's best used when the game is windowed with the log from the script editor visible. Asset Manager: self.sound = Sound:Load(AssetManager:Check("Sound/MySound.wav)) Never crash again because you moved something or mistyped an asset. AssetManager:Check() returns a error asset from engine.pak if what you've sent is not found. The game will not start at all unless the error assets are found at startup. You can also easily preload models for later use with AssetManager:Precache(string). You can also make a Precache list with AssetManager:PrecacheGlobal(string). This is great if you have a model or prefab that might spawn at anytime in any map. PostStart(): PostStart is a command fired after the level loads instead of during it like Start does. function Script:Start() self.source = Source:Create() self.source:SetVolume(self.volume/100) self.source:SetPitch(self.pitch) self.source:SetLoopMode(self.loop) self.source:SetRange(self.range) self.source:SetPosition(self.entity:GetPosition(true)) end function Script:PostStart() local sound = Sound:Load(AssetManager:Check(self.soundfile)) if sound~=nil then self.source:SetSound(sound) if self.playing==true and self.enabled==true then self.source:Play() end sound:Release() sound=nil end end Input System: if Input:Forward(true) then self.input[1]=self.input[1]+1 end if Input:Backward(true) then self.input[1]=self.input[1]-1 end if Input:Right(true) then self.input[0]=self.input[0]+1 end if Input:Left(true) then self.input[0]=self.input[0]-1 end You can now allow your player to change their controls. by calling a general function. Controls can be controlled with System:SetProperty or by editing settings.config. The control commands are based off of the default steam controller layout. I just need too add previous/next weapon, but wasn't 100% sure how I was gonna do that since it may be a scroll wheel. Basic UI System: Use Lua to create your own UI with LEX2's exposed UI classes. If you replace the app start and loop functions with this code, it'll make a square in the corner with a text button that says "Leadwerks". --This function will be called once when the program starts function App:Start() Rect = UIRectangle:Create(4,4,200,200) Rect:SetColor(40, 40, 40) Rect:SetBorderLineWidth(4) Rect:SetBorderColor(92, 92, 92) Rect:EnableBorder(true) Rect:Hide() local testfont = Font:Load(AssetManager:Check("Fonts/consola.ttf"), 20) Rect3 = UIText:Create(Rect:GetCenter().x, Rect:GetCenter().y, "Leadwerks", testfont, "Test"); Rect3:Center(); Rect3:SetShadowMode(false) Rect3:SetAsInteractive(true) Rect:AddChild(Rect3); return true end --This is our main program loop and will be called continuously until the program ends function App:Loop() context:SetBlendMode(Blend.Alpha) -- Here is code to darken the scene when the game is paused. if self:IsPaused() and self:IsConnected() then context:SetColor(0,0,0,0.5) context:DrawRect(0,0,context:GetWidth(),context:GetHeight()) end Rect:Update() if (Rect3:GetMouseEvent() == Rect3.MouseLeftUp) then System:Print("Pressed!") elseif(Rect3:GetMouseEvent() == Rect3.MouseOver) then Rect3:SetColor(100, 100, 100) elseif (Rect3:GetMouseEvent() == Rect3.MouseLeftDown) then Rect3:SetColor(80, 80, 80) else Rect3:SetColor(255, 255, 255) end if window:KeyHit(Key.F11) then if (Rect:IsVisible()) then Rect:FadeOut() else Rect:FadeIn() end end context:SetBlendMode(Blend.Solid) return true end I haven't really did much with the UI as it's a future feature of the engine, plus I've been playing with other stuff. But with UIRectangle and UIText is pretty much the foundation of buttons, sliders and other stuff anyway. Or you can use another UI library if you want. Again, you can play with it by downloading the project here: https://dl.dropboxusercontent.com/u/16218991/Requests/LEX2Test.7z I'm really stress testing it now making sure I don't have to touch anything when I'm ready to revist Vectronic. Speaking of Vectronic, it's almost been a year since I've released the demo. I might later this week write a blog about it and my battle plan for it.