reepblue

Gonna go with 3 since the other two seem to modern, while the third set can take place at anytime.

Whether be Leadwerks or another OpenGL engine such as the Space Engine, I've always heard a lot of people having issues with Windows, AMD, and OpenGL.

Setting the collision type to Prop, or Debris should automatically turn on gravity and such. I mostly create my emitter's in script, so I need to confirm this myself.

No it wouldn't because I need both player's and objects to lift up. I made a strange script before that it's not pushing the object up that's the problem, it's getting the object to fall down with the platform when it goes down. Right now I'm thinking about porting my first platform code, and fully testing that. If it's only the player that's the issue, I think I can fix it.

Great to hear, I'm always excited to see what's next with the engine. Very interested to see what's in mind for LE4.

Can be an OpenGL problem with AMD as Unreal uses DirectX, and I think so does Unity.

Hi, For the last few days, I've been trying to make my platforms/lifts perfect for both the player, and physical objects. I've thought I solved the issue explained here, but upon further investigation, I noticed a few problems. When the platform goes down, the physical object is put to sleep, and does not wake up when the platform goes back down. I've tried a bunch of things to keep it awake, but the box reacted to violently, and the overall result was bad. In the demo, I made a non-physics based script which worked for the demo, but when I went to use it in levels, the physics update did not update the player, and the player would just "fall through" the platform. I would just keep using the standard sliding door script as it solves both problems, but the platform itself reacts to physical impact. So in a case, a box can be falling for a few meters, and when it crashes on the platform, it sinks below the floor brush. I've made a script that prevents this when the platform is resting, but it can still be offset when the platform is moving. Collision Rules: --------------------------------------------------- --[[Collsion Defines: Make new Collision Rules ]]-- --------------------------------------------------- Collision.CharacterBlocker = 9 Collision.PropBlocker = 10 Collision.Clip = 11 Collision.PickInfo = 12 Collision.PickedUpProp = 13 Collision.Item = 14 Collision.JointObject = 15 Collision.PickInfoCrouch = 23 -- Props can activate triggers. Collision:SetResponse(Collision.Prop, Collision.Trigger, Collision.Trigger) -- Comment me out if you don't want this! -- CSG Collisions Collision:SetResponse(Collision.CharacterBlocker, Collision.Character, Collision.Collide) Collision:SetResponse(Collision.PropBlocker, Collision.Prop, Collision.Collide) Collision:SetResponse(Collision.PropBlocker, Collision.PickedUpProp, Collision.Collide) Collision:SetResponse(Collision.PropBlocker, Collision.VecBox, Collision.Collide) Collision:SetResponse(Collision.Clip, Collision.Character, Collision.Collide) Collision:SetResponse(Collision.Clip, Collision.Prop, Collision.Collide) Collision:SetResponse(Collision.Clip, Collision.PickedUpProp, Collision.Collide) -- Picked up objects can still collide with triggers, but never characters. Collision:SetResponse(Collision.PickedUpProp, Collision.Character, Collision.Collide) Collision:SetResponse(Collision.PickedUpProp, Collision.Scene, Collision.Collide) Collision:SetResponse(Collision.PickedUpProp, Collision.Prop, Collision.Collide) Collision:SetResponse(Collision.PickedUpProp, Collision.Trigger, Collision.Trigger) Collision:SetResponse(Collision.PickedUpProp, Collision.PickedUpProp, Collision.None) -- Items Collision:SetResponse(Collision.Item, Collision.Character, Collision.Trigger) Collision:SetResponse(Collision.Item, Collision.Scene, Collision.Collide) Collision:SetResponse(Collision.Item, Collision.Prop, Collision.Collide) Collision:SetResponse(Collision.Item, Collision.Trigger, Collision.Trigger) Collision:SetResponse(Collision.Item, Collision.PickedUpProp, Collision.None) -- PickInfo Collision:SetResponse(Collision.PickInfo, Collision.Scene, Collision.Collide) Collision:SetResponse(Collision.PickInfo, Collision.Prop, Collision.Collide) Collision:SetResponse(Collision.PickInfo, Collision.PickedUpProp, Collision.Collide) Collision:SetResponse(Collision.PickInfo, Collision.Trigger, Collision.None) Collision:SetResponse(Collision.PickInfo, Collision.Item, Collision.Collide) Collision:SetResponse(Collision.PickInfo, Collision.JointObject, Collision.None) Collision:SetResponse(Collision.PickInfoCrouch, Collision.Scene, Collision.Collide) Collision:SetResponse(Collision.PickInfoCrouch, Collision.Prop, Collision.Collide) Collision:SetResponse(Collision.PickInfoCrouch, Collision.PickedUpProp, Collision.None) Collision:SetResponse(Collision.PickInfoCrouch, Collision.Trigger, Collision.None) Collision:SetResponse(Collision.PickInfoCrouch, Collision.Item, Collision.Collide) Collision:SetResponse(Collision.PickInfoCrouch, Collision.JointObject, Collision.None) --JointObject Collision:SetResponse(Collision.JointObject, Collision.Character, Collision.Collide) Collision:SetResponse(Collision.VecBox, Collision.JointObject, Collision.Collide) Now here is my current platform code based off the sliding door script. import "Scripts/Functions/ReleaseTableObjects.lua" Script.enabled=true--bool "Enabled" Script.openstate=false--bool "Start Open" Script.distance=Vec3(0,0,0)--Vec3 "Distance" Script.movespeed=1--float "Move speed" 0,100,3 Script.opensoundfile=""--path "Open Sound" "Wav File (*wav):wav|Sound" Script.closesoundfile=""--path "Close Sound" "Wav File (*wav):wav|Sound" Script.loopsoundfile=""--path "Loop Sound" "Wav File (*wav):wav|Sound" Script.closedelay=-1 Script.opened=false function Script:Start() self.entity:SetGravityMode(false) if self.entity:GetMass()==0 then self.entity:SetMass(10) end self.sound={} self.sound.stop01 = Sound:Load("Sound/Gameplay/VecPlatform/platform_stop01.wav") self.sound.stop02 = Sound:Load("Sound/Gameplay/VecPlatform/platform_stop02.wav") -- Collision Fix self.entity:SetCollisionType(Collision.JointObject) self.protector= Model:Box(1,1,1) self.protector:SetPosition(self.entity:GetPosition(true)) self.protector:SetRotation(self.entity:GetRotation(true)) self.protector:SetQuaternion(self.entity:GetQuaternion(true)) self.protector:SetShape(self.entity:GetShape()) self.protector:SetShadowMode(0) -- Fix the shadow mode for the platform self.protector:SetGravityMode(false) self.protector:SetCollisionType(Collision.PropBlocker) self.protector:SetParent(self.entity) local material = Material:Load("Materials/Effects/Invisible.mat") self.protector:SetMaterial(material) material:Release() if self.opensoundfile~="" then self.sound.open = Sound:Load(self.opensoundfile) end if self.loopsoundfile~="" then self.sound.loop = Sound:Load(self.loopsoundfile) end if self.closesoundfile~="" then self.sound.close = Sound:Load(self.closesoundfile) end if self.sound.loop~=nil then self.loopsource = Source:Create() self.loopsource:SetSound(self.sound.loop) self.loopsource:SetLoopMode(true) self.loopsource:SetRange(50) end self.opentime=0 --Create a motorized slider joint local position=self.entity:GetPosition(true) local pin=self.distance:Normalize() self.joint=Joint:Slider(position.x,position.y,position.z,pin.x,pin.y,pin.z,self.entity,nil) if self.openstate then self.openangle=0 self.closedangle=self.distance:Length() else self.openangle=self.distance:Length() self.closedangle=0 end self.joint:EnableMotor() self.joint:SetMotorSpeed(self.movespeed) local e = self.entity:CountChildren() for n=1,e do --System:Print(n) cl = n - 1 local c = self.entity:GetChild(cl) --c:SetColor(1,1,1,0) c:SetShadowMode(Light.Dynamic) end --This will move, so have the shadowmode dynamic. self.entity:SetShadowMode(Light.Dynamic) end function Script:Toggle()--in if self.enabled then if self.openstate then self:Close() else self:Open() end end end function Script:Open()--in if self.enabled then self.opentime = Time:GetCurrent() if self.openstate==false then if self.sound.open then self.entity:EmitSound(self.sound.open) end self.joint:EnableMotor() self.protector:Hide() self.joint:SetAngle(self.openangle) self.openstate=true self.component:CallOutputs("Open") if self.loopsource~=nil then self.loopsource:SetPosition(self.entity:GetPosition(true)) if self.loopsource:GetState()==Source.Stopped then self.loopsource:Play() end end end end end function Script:Close()--in if self.enabled then if self.openstate then if self.sound.close then self.entity:EmitSound(self.sound.close) end self.joint:EnableMotor() self.joint:SetAngle(self.closedangle) self.openstate=false if self.loopsource~=nil then self.loopsource:SetPosition(self.entity:GetPosition(true)) if self.loopsource:GetState()==Source.Stopped then self.loopsource:Play() end end self.component:CallOutputs("Close") end end end function Script:UpdatePhysics() end function Script:Disable()--in self.enabled=false self.joint:DisableMotor() self.component:CallOutputs("Disable") end function Script:Enable()--in self.enabled=true self.joint:EnableMotor() self.component:CallOutputs("Enable") end function Script:UpdatePhysics() --Disable loop sound local angle if self.openstate then angle = self.openangle else angle = self.closedangle end if math.abs(self.joint:GetAngle()-angle)<0.1 then if self.sound.loop~=nil then if self.loopsource:GetState()~=Source.Stopped then self.loopsource:Stop() end end if self.openstate==false then if self.opened==true then self.protector:Show() self.component:CallOutputs("OnFullyClosed") self.opened=false self.entity:EmitSound(self.sound.stop02) System:Print("Fully Closed") end else if self.opened==false then self.component:CallOutputs("OnFullyOpened") System:Print("Fully Opened") self.entity:EmitSound(self.sound.stop01) self.opened=true end end else if self.sound.loop~=nil then if self.loopsource:GetState()==Source.Stopped then self.loopsource:Resume() end end self.component:CallOutputs("onresume") end if self.sound.loop~=nil then if self.loopsource:GetState()==Source.Playing then self.loopsource:SetPosition(self.entity:GetPosition(true)) end end --Automatically close the door after a delay if self.closedelay>0 then if self.openstate then local time = Time:GetCurrent() if time-self.opentime>self.closedelay then self:Close() end end end end function Script:Release() ReleaseTableObjects(self.sound) if self.loopsource then self.loopsource:Release() self.loopsource=nil end self.sound=nil end Is there a better way of making a platform that updates physics and the player but does not react to heavy objects, or objects with momentum? I really don't want to take any shortcuts as I don't want any puzzles to be limited/gimped depending on platforms. If you need/want any more of my attempts/code, I'll happy supply it. Thanks.

If you have the standard edition, if you look at the header files, you can see what functions are exposed to lua, and I think you can expose a functions yourself with tolua++ if they are not already. Not every function that's accessible in lua scripts is documented.

This is because dofile() is not apart of the Leadwerks Filesystem. I've had similar issues loading xml files. Did you try using Execute file of the interpreter? Interpreter:ExecuteFile("Scripts/myscript.lua")

Doesn't setting the Collision Type under Physics do the trick?

Besides fixing the UV's for the VecDispenser, Adding in the box model, and some added sounds thanks to ThirstyPanther, most of the work this week was done with adjusting scripts so that the game as a whole plays better. Picking Up Objects Last week, I mention that I adjusted the pickup system so that it will auto center the object when it's picked up. While the stock code for the pickup system is good for occasionally picking up objects, in Vectronic, you're gonna be picking up boxes a lot. Not only that, but some puzzles require you to throw the boxes straight a head. The stock code locks the position and of the pickup with the picker position point which produces results like this. The pickup system needed to feel natural as possible. I wanted the object to tween from the current location to the center of the player's crosshair, much how the pickup system is in Source. It only took an additional transformed point from the camera, and using Math:Curve to translate the two positions together. The box position will always now be centered with the crosshair when picked up. This fix caused a few more problems which I'm still tweaking, I've added collision back to the picked up object, prevented the player picking up the object if they are standing on it, and also made the player auto drop it if the speed of the object is going too fast due to movement speed or violent collisions. It's not perfect now, but I feel that it's better than the stock pickup system, at least for this game. Platforms Another fix I've made is with the moving platforms. One major I've found with the sliding door script is that if a heavy object is on the joint object, the joint will fail, and fall through the floor. Since the boxes need to be heavy so they don't bounce really high, I felt like this was not a good system for the platforms. In the demo, I've made a script that just moves the model's position over time, but further playing with this script showed me that there was issues actually pushing the player up, while jointed objects did not have this issue. So I went back to the sliding door script with the problem of heavy objects effecting them, but lifting the player is fine. I solved this by making the joint object invisible and it's collision set to only collide with the player, and nothing else. Then, have the platform model as it's child which collides with everything else. This solved both problems as heavy boxes don't screw up the platforms as it's not colliding with the platform, but the player and objects can ride with the lifts without any issues! I still need to work on a better way to set the distance, as right now you have to guess and tweak the distance values which I don't seem to like very much. I plan on switching it to a location point instead. Overall, the platforms need to be more user friendly as right now it's just a modded version of the sliding door script. I might work a bit on that this week. I'll continue to work little by little to get everything as solid as I can. There is also a map in this set that I feel that's not as fun, informative or needed that I want to adjust or replace before working on any new maps. The goal is to get all this basic stuff perfect before continuing.

I was gonna write one for my LEX template, but I did not know how basic I should have made it. Should it just be a simple player that can just walk around, jump, and crouch, or have life, and weapon support too?

You can change the refraction amount in the shader so it's less of a direct reflection.

Very nice tutorial. Only criticism I have is that the 3rd party software you need costs more than the engine itself. I think for the future, it's best to recommend free/open source and multi platform applications if you plan to do any more. I get it that Vue is a professional skybox program, and there is prob not a good way to do it in Paint.Net or Gimp. I recommend tutorials on how to get a model from Blender into Leadwerks with the correct rotation and scale. It also be nice to document how animation files should be written, and how to load it. It does not seem to be talked about in the models and animations tutorial. You did a good explanation , but it's buried within the Leadwerks Youtube channel.

@Olby. Although looking at blender files might not make you a better modeler, It sure helped me on how to properly rig a model to work. But allowing the end user to take a model and let them be able to modify it can be a learning tool. Everyone learns differently.

If Josh actually release the raw content, it will give people a "Ohhh, so that's how I do it" moment. I've learned a lot looking at decompiled models before, and they are always nice to have. But if the new models are just "Ok guys, new models" without any sources, then yes, nothing can really be learned from it. I really hope the vertex tools and slicing are on the To-Do list, but there is a lot of issues with that. For example, creating invalid shapes, probably why Josh just added carving. Since I'm so used to not carving because it was seen as a sin with GoldSrc/Source, I don't use it as much. Hopefully someday it will be implemented. Importing a model or texture to Source is A LOT more confusing than it is for LE3. Again with the source engine, people are generally making mods, and have the entire resource library of 3 Half-Life games, and if you know how, you can port models from Left 4 Dead, and other games. This is where I think if Leadwerks had it's own set of content, it will give new users a starting point, or at least a better one then they have now. Overall, I think if Josh does release the sources of new content (both models and textures) and with that, having more in-depth tutorials about creating the such content for Leadwerks, I think this issue will be better addressed.

I was gonna say, if this is your work, make it apart of the official toolset. Making cubemaps/skyboxes are very frustrating at first.

Sprites are using Light and particle materials use Alpha. I think it's because this map is not using a bloom shader that the sprites don't pop as they should.

I know from personal experience that Games run fine on Linux Mint 17.1 Cinnamon. The editor however, you need stock Ubuntu. However It would still launch, but unusable.

I don't have a fast enough connection for that because of my location. Right now, I'm only working close with people who know about game development and are very good on feedback. For causal testing, I have to do the dinosaur way and ask local people to play the game on my machine while I stand back and take notes. Luckly, I have a 1080p TV, and I integrated the Xbox360 controller so people can use that until I grab a Steam Controller. Something I'm not too worried about until the game looks more like a game. I want to atleast replace brush models with actual models before I ask causal players to test it.

Another week, another weekly report. Vectronic is going more smoothly then ever before taking things one at a time, and just shelling out maps and ideas quickly. Last week, I did a few improvements with how the player picks up objects, and fixing the issue of shooting projectiles through objects. I did not shell any more maps because I thought it would be better to focus on a small amount of puzzles at a time, perfecting them before making more maps. For this, I needed help. As of this week, I quietly put the first test build on in the Dropbox folder which used to host the Source build, and asked a small number of people to test out movement, mouse control, and if everything feels right before I make things more complex. From the first week of testing, I'm confident that the project is moving in the right direction. From one tester who has played all other builds of Vectronic told me that this current build has better puzzle direction and clarity, and full of gameplay unlike previous builds that was just a bunch of mechanics, pretty rooms, but no gameplay at all. I got recommended a few changes I should make, like making the box heavier so when it crashes to the floor after floating in the air, it does not bounce off a button, or adding a plane of glass to block a more frustrating solution. A few tweaks still need to be made, solutions should just work, and not fully relying on the physics engine. I recall this being a problem with Quadrum Conundrum. Word of advice though, I learned that play testers hate fully ambient lit rooms, so before you release for testing, atleast put fill lights in. One tester told me it was hard to perceive the room with a full ambient light. I have one map with fill lights as a test, and he reported that when he got to that map, he had a better experience. I also found out that this method on leak protection didn't work when you packaged your games. It failed to initialize Steamworks although Steam was running. Not sure if this has to do with how packaged games work, or something I did wrong. I could of just uploaded the raw project, but that's a difference of 88MB vs 18MB. I'll work on this for the next build which I plan on posting a new test build biweekly. VecBall Design Yesterday, instead of writing this blog post, I was in an art mood, and wanted to put something back online with a model and sounds. I was using the old ball sprite and particle effects from the Demo, and I was really unhappy on how the dispenser looked in Leadwerks compared to how it was in Source. I decided if I was gonna touch anything art related, it was gonna be the basic foundation of the Vecballs themselves. I already had an idea of how I wanted my balls to look in the previous build. I'm a huge fan of how the Portals where in Portal in pre-release builds, and I wanted to reference that. This portal design required a large amount of textures for the mask, overlay, and other things that portals need. These portals took a whopping 174MB of VRAM PER PORTAL. and this was 2006/2007. I'm told that Valve cut it only because they ran out of memory on the Xbox360. Besides them being memory hoggers, I'm happy that I have them in a mod where they work exactly like how they did in previous builds. Unlike Portals, I can do a sprial/swirl effect with my vecballs without going over budget. I really liked the idea of the balls being a swirling ball of energy, so this could work. I made a quick texture and effect before I focused more on LEX. I later put what I've did in the Vectronic Demo. I pretty much just copy and pasted my swirl edits I had before into this build with a few changes. It still needs work, but it's pretty much the same as it is in the Demo, at least for now. Now to the dispenser. What makes Vectronic diffrent from Portal is that you loose your vecballs after each level, requiring you to recollect them in the next map. When I first sat down for the design of the dispensers, I sorta saw them as the item pickup bases in multiplayer games like Unreal Tournament. In Source, the particles stood tall and really stood out. But when I was transferring the design to Leadwerks, no matter what, they appeared washed out. This might be because of the colors, but I could not replicate how they appeared in Source. So I decided to take the dispenser back to the drawing board. I felt that the bases were too small, and needed a face lift. I quickly made this out of a cylinder in blender, added some base colors, and called it a day. UV sheet is still bad though, something I always have problems with. Attached a few emitters and sprites to it and got this in-engine. This is still not final as the ball sprite can still get washed out in the environment. I'm not gonna worry about it until I start messing with post processing effects and the overall look of the maps. I'm also open to suggestions. It's good for now, and it's a hell of a lot better then how they are in the demo! So that wraps this weeks report up. I guess this weeks goal is to ask more people to test the seven maps I have and seeing how I can improve those and other things before moving forward.

Oh, so THAT's how you do it. If I knew how to do that, I would not pass classes along as pointers in LEX. (Gotta remember, only C++ coding I did before was for Source.) If I ever make a LEX2, I'm using this for classes. Thanks!

I really enjoy the revamped script editor. I can't seem to get the auto complete to work though. Also, please no Skyboxes with suns. Sometimes the sun in the skybox will be in the wrong spot in how you want to light your scene.

I really need to look more into this in the future, Is it possible you could write a few blog entries walking through how to make a C++ class fully communicable with other lua scripts? That would be cool, as I'm not following you when you said:

Starting as a modder, and starting as a indie developer are two different things. When you find a game that you love and want to make more content for it, the developer would have a sample pack of raw maps and models for you to go off of, or the community would make decompiling tools so you can look at these raw maps and models. People tend to learn better if they have examples to go by, rather then starting from complete scratch when they start their indie game. The AI and Events map is a "almost good" sample map. Yes, it demonstrates how bsp geometry, flowgraph and AI can be used in maps, but I recall the textures not being their default scale on brushes, the wall height was around 320cm tall than the 256cm that is stated in the recommended mapping standards. It would also help if the map was released in various forms showing how maps are traditionally made showing that all maps start as blocks of dev textures first, THEN it gets the art treatment when gameplay is established. Many people tend to think that the map is made with the assets from the start. So in conclusion, I recommend you release all the raw sources of models and such you tend to redo. Doing this will allow people to study it, mod it, and learn from it. For instance, I really want a viewmodel sample model to help figure out how to make my own. I learned most of my knowledge from pre-made models and maps, and I feel it's a great way of demonstration.