reepblue

The only difference here is the exe itself. I never noticed that the exe's are two totally different sizes. It seems to only be noticeable with busy scenes rather than simple games/prototypes. Hence why I waited till I released the demo to ask about this issue. So it must be within the project files. I might try rebuilding an exe from scratch and see if there is any hiccups.

Before I released Vectronic's Demo, I've noticed that when recompiling the project even with the stock code, the game runs at a much slower framerate than the exe generated by the project manager. But now since the demo is out, and there is something to test it with I'd thought I would share this issue with the community, and hopefully find a fix. Please download the Vectronic Demo if you don't have it already, then download this 7z file which contains two exe's. One recompiled titles "Vectronic_Recompiled" (Recompiled by me.) and the other "Vectronic_Stock" (Straight from the project manager). It also contains the Source and Project Folder. This should work regardless if you have the latest beta or not. I tried the exe's on the current standard release. You'll notice that the stock executable runs at a higher framerate than the recompiled executable. I've not changed a single thing within the projects nor source code. What makes this different than the ones generated by the stock builds of the executables? Thanks.

Strangely enough, with the Linux version of the editor this defaults to true, and in Windows, it defaults to false. I can't recall if I checked it or a 3.5 beta build automatically did this. Ether way, I force my elements to set it to be false in the start functions as it fixes the issues with AMD GPU's and the statement above. I wish to update the demo with this fix and the crouching fix for Linux players.

I think you should do something in the scene tree/name field when 2 entities are sharing a name. A little warning icon or how Hammer does this is by bolding the name if 2 entities share a name. (Although may be less obvious.) I welcome this approach. Yeah, I'm use to typing/copy and pasting names into fields, but I really dislike how the scene tree functions. But that's just me.

Again, I made a character that can go under stuff. If you play Vectronic use the 0g and ghost box combo to make a ghost box float around half the player's height, they player will go under it and there is a picker test to tell the player not to get up if they are under an object...

This seemed to fix it. Hopefully doing this on all props will not impact on performance too much. I might have the actual maps be small (A one puzzle per map rule, sorta like Portal 2.)

On my AMD Linux machine, (A 5770 HD), I tried the AI and events SDK map even though it's a smaller map, and the only animated models are the crawlers. Trying to figure out if this is my models and how they are rigged, or AMD with Leadwerks. So far the reports are coming from AMD users. Don't think it's the fact it's on linux as I tried it with my machine with Mint, and it ran like it should.

I'm aware of the flickering issue, so far my findings have been that it's something to do with animated models and AMD gpus. From your profile it seems you have an integrated chip. Do models flicker in other LE games? Gonna test the Advanced Shooter template now.

With the Unity desktop, it's fine. What desktop are you using? Also what distribution you are using because Ubuntu is the only distro officially supported.

Great information. I just thought adding a quick how to for Linux newbies like myself. Thanks for the tip, your knowledge is very helpful.

Note: This is pretty much a copy and paste from this post here with a few tweaks. After 3 years of planning, modeling, texturing, and a lot of engine hopping, I was able to create a playable demo in the Leadwerks Engine for Windows and Linux (Debian/Ubuntu/Mint). You can download the demo from this page. A small demo was created not only to test the basic elements of the game in the new engine, but to also give back to those who have been supporting this project since I started talking about it. I'm also announcing that from here on out that the development will be more open. How open? Well first you can always check the Trello page to see the progress at any time, If you wish to help, drop me an e-mail. Feed back is welcomed with opened arms. You can do this simply by e-mail or twitter @reepblue. I'll do my best to respond if necessary. About Vectronic Vectronic is a first-person environmental puzzle game inspired other games of the same genre such as Portal, Quadrum Conundrum, and Q.U.B.E. Players must solve puzzles using special power balls that effect boxes that changes their behavior in the world. For more information, please visit the Q&A. For additional help, click here. Please let me know what you think. Although a short primitive demo, this is a big milestone for the project in the indie path.

Found the issue: The Linux executable does not set it's permissions to execute as a program. I'll copy over the executable with it's permissions set and post a quick "how to" on the blog in case it get's lost.

So I built recently built a "garbage-PC" (A term I use to describe building a new PC out of older usable parts.) and slapped in my old Radeon 5770 and a drive running Ubuntu 14.04 LTS in it to see if Leadwerks would work at all. Also, wanted to see if Vectronic would run out of the box if a Linux user downloaded the demo. I put the Vectronic Demo (Stand-alone Packaged) on the machine and when I tried to run it, it asked to install various packages. However, when I launched Leadwerks in Ubuntu, and created a new game, that executable launched fine. So I took that executable, renamed it "Vectronic", and boom it launched. So my question is why does a linux executable generated from the project manager off of a Windows machine need additional packages while one generated on linux just works? Should I ship the working executable or should I just install the list of packages it wants? And to be clear, I'm not running the Window's .exe executable.

I guess it was something in the player code. Mine is not the stock FPSPlayer so it may be why mine worked fine. (also it's a bit harder to notice in first person.) My lua script solves that problem. The issue was updating the player while it was moving.

I had this issue (But it strangely went away). You can try parenting a pushing trigger upwards or add this: function Script:Collision(entity, position, normal, speed) if self.move then if entity:GetKeyValue("type") == "player" then System:Print("Entity Touching") self.currentPushForceDir = self.PushForceDir entity:SetVelocity(self.PushForceDir, true) end end end At the top of the script, add: Script.PushForceDir=Vec3(0,0,0) --Vec3 "Force Direction" Script.currentPushForceDir=Vec3(0,0,0) The goal is to keep the player moving. Experiment with self.PushForceDir on the y axis. I accidentally found this trying to push the player off of moving platforms. If the collision function is not spiting it's print, then move the pushing to a trigger volume.

No. You don't want to use the sliding door script as boxes and players would weigh it down. I had the same issue in my game. You need a non-physics based object that moves. (No mass, no joints). This is my script that I used in Vectronic. Feel free to use it.: import "Scripts/Functions/ReleaseTableObjects.lua" Script.restinglocation=nil Script.move=false Script.movedistance=0 --float "Move Distance" Script.movespeed=1 --float "Move Speed" Script.startopened=false --bool "Start Opened" Script.negitive=false --bool "dev" -- Sound 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.stopsoundfile=""--path "Stop Sound" "Wav File (*wav):wav|Sound" function Script:Start() self.restinglocation = self.entity:GetPosition() self.iy = self.restinglocation.y self.targetlocation = Vec3(self.restinglocation.x,self.restinglocation.y + self.movedistance / 100,self.restinglocation.z) if self.startopened then self.entity:SetPosition(self.targetlocation) self.opened=true end self.sound={} 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.stopsoundfile~="" then self.sound.stop = Sound:Load(self.stopsoundfile) 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 -- Should always use a dynamic shadow. self.entity:SetShadowMode(2) local e = self.entity:CountChildren() for n=1,e do --System:Print(n) cl = n - 1 local c = self.entity:GetChild(cl) c:SetShadowMode(2) end end function Script:UpdateWorld() if self.movedistance >= 0 then self:NormalToggle() else self:NegitiveToggle() end end function Script:NormalToggle() if self.move then if not self.opened then if self.iy < self.targetlocation.y then self.entity:SetPosition(self.restinglocation.x,self.iy,self.restinglocation.z) self.iy=self.iy + self.movespeed * Time:GetSpeed()/100 elseif self.iy >= self.targetlocation.y then self.iy = self.targetlocation.y self.move = false self.opened=true self:StopSound() self.component:CallOutputs("OnOpened") end else if self.iy > self.restinglocation.y then self.entity:SetPosition(self.restinglocation.x,self.iy,self.restinglocation.z) self.iy=self.iy - self.movespeed * Time:GetSpeed()/100 elseif self.iy <= self.restinglocation.y then self.iy = self.restinglocation.y self.move = false self.opened=false self:StopSound() self.component:CallOutputs("OnClosed") end end end end function Script:NegitiveToggle() if self.move then if not self.opened then if self.iy > self.targetlocation.y then self.entity:SetPosition(self.restinglocation.x,self.iy,self.restinglocation.z) self.iy=self.iy - self.movespeed * Time:GetSpeed()/100 elseif self.iy <= self.targetlocation.y then self.iy = self.targetlocation.y self.move = false self.opened=true self:StopSound() self.component:CallOutputs("OnOpened") end else if self.iy < self.restinglocation.y then self.entity:SetPosition(self.restinglocation.x,self.iy,self.restinglocation.z) self.iy=self.iy + self.movespeed * Time:GetSpeed()/100 elseif self.iy >= self.restinglocation.y then self.iy = self.restinglocation.y self.move = false self.opened=false self:StopSound() self.component:CallOutputs("OnClosed") end end end end function Script:StartLoopSound() 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 function Script:StopSound() if self.sound.stop ~= nil then self.entity:EmitSound(self.sound.stop) end if self.loopsource~=nil then self.loopsource:Stop() end end function Script:Open()--in self.opened=false if not self.opened then --if not self.move then self.move = true self:StartLoopSound() if self.sound.open then self.entity:EmitSound(self.sound.open) end self.component:CallOutputs("Open") --end end end function Script:Close()--in self.opened=true if self.opened then --if not self.move then self.move = true self:StartLoopSound() if self.sound.close then self.entity:EmitSound(self.sound.close) end self.component:CallOutputs("Close") --end end end I put the move code in UpdateWorld than UpdatePhysics because the platform goes closer back to it's original resting point better with UpdateWorld.

Interesting. I tried it with my doors and although the actual model did not rotate, the bones of the models did. Any idea how it relates to it being fine for a few days/weeks then suddenly everything is off? Yeah, I'm a fan of CTRL+Draging so this makes sense why it was happening to me. Oddly enough, my trusses, and CSG were made by me copying and pasting, and they seem not to be effected.

If it stayed at for example -89.98, I would have been like "whatever, looks fine to me". But it slowly becomes -88, -87, -85, etc. Issue does not really pop up unless you are editing the same map over and over again, switching projects, and just general use of the editor. If there is anything we can do to help, let us know.

I thought it was only me too. I actually noticed it first with my boxshoot door. But I thought it was just the model and the fact I was loading the map on a different OS. It seems to be that when an entity (or CSG) get rotated, the rotation does not get saved properly. Keep a entity as Rotation 0,0,0, nothing will happen. (maybe some of the 0's will become negative. (-0.0). It also has something to to if a script is attached, and/or is parented to another entity in the scene tree. This issue is annoying and frustrating as things slowly move on their own and one day you'll find all your objects not how you want them.

I first noticed this with my indicators for Vectronic when after a while the indicators would tend to Z-clip with the wall. Today after I went to a different project, I came back to Vectronic to do a few more changes. In the demo map, I noticed that my doors where not in the tracks anymore, and some indicator panels were oddly rotated. I was able to quickly rotate them back into place (both models and bones) and I only have these screenshots right now. And here is a physics model I forgot to rotate back. After fixing all the models, I closed the editor, and relaunched it. I went back to one of the entities I had to rotate and it's rotation on one of the axis was 89.98 rather then the 90.00 I set it at. It happens to both models with and without bones/animations..

When I read this, I took it as "Don't use our libraries to make something totally different then intended such as a new game engine/tools." I think making tools for your game (e.g An application that's just meant to go in your maps and help generate cubemaps to make life easier) is ok, but taking the libraries and developing a branch engine goes against it. Ether way, if you just want to make games, you should not worry about this.

Same goes for their Source SDK department. That's Valve for ya.

Did you rebuild the C++ solution? I have frame dipping issues when I use the exe I built instead of the pre-made application. I was gonna post my issue once I had a demo out. I would delete the "My Game" project and replace it with a fresh Project that uses the Advanced First Person Shooter Template. They are the same thing, but it's best to make sure everything is up-to date and clean.

Yeah, and the best part is that the shadows are all static so they are not expensive! Also, a big shout out goes to Shadmar for the bloom and fog shaders. It really gives the maps the atmosphere I want.

Definitely Next Week! I wish I can release sooner, but I'm waiting on sounds and there are still a little bit more tweaks I wish to do.