Jump to content

bansama

Members
  • Posts

    64
  • Joined

  • Last visited

Everything posted by bansama

  1. I mean both of the run options offered in Leadwerks while it's running. They're represented by a full green arrow and an outline green arrow. Doesn't matter which I use, both will cap at 30 fps when sync is set to true. Only when the project is published through the project manager does sync then cap at 60 fps (which would be right for my monitor).
  2. That appears to be it. The old app.lua has that set to false. Still unsure why it only gives 30 fps when run through Leadwerks though. Thanks for helping to clear this up.
  3. Nope. Then I wonder what's going on. My hardware has not changed. They only thing that has is Leadwerks though the normal non-beta updates =/ I've also just tried building a new copy of my old project and that is now capped at 60 fps when published as a standalone. So something has definitely changed in the last few months. Update: Yeah, something has definitely changed with app.lua. I managed to build the project again with the old app.lua script and that one shows fps of several hundred. With the current default app.lua script created by Leadworks, it is showing a cap of 30 when testing through Leadwerks (both Debug and Run) or 60 when published.
  4. I noticed today that I'm only able to get 30 fps when running builds through Leadwerks. But I'm sure this never used to be the case (and old project still gets fps in the hundreds when run outside of Leadwerks). Is there a setting I've missed that allows me to change this?
  5. As someone else said, one of the recent patches was meant to fix the throw function for when a player does not have a weapon. Is this not the case?
  6. With one possible exception, I've never had an update break scripts. I can't even be sure it was an update that did break the script that stopped working... That said, I have had updates wipe out all connections in the Flowgraph. I've also had to manually update all my projects as a new update to Leadwerks only seems to give you a warning that existing projects are out of date. So if you're concerned something will break, there's certainly opportunity to make a backup of the project directory yourself. As for getting a refund from Steam, they do offer a one-time goodwill gesture refund. But you'll have to fight for it and be polite while doing so.
  7. Yeah, I just found this. It only works if I make the trigger object really tall. Perhaps this is connected to the height of the player? This now appears to be working again. I would still like to work out how to use a separate entity to toggle this though just in case something else breaks it again in the future (and it could probably be useful for other things too). That is, to be able to access the variable for enabling/disabling with an imported script. I think I have an idea of how to try this. I just need to wrap my head around self and local variables... Thanks everyone for all the help and ideas thus far.
  8. I have tried exactly as your video, making trigger objects on the pads and adding the script to the triggers. In that case nothing happens. That is, I collide with the trigger and don't teleport. If I add the script to the pads without the teleport, they work as long as their collision type is not trigger (but with the behaviour mentioned at the start of this topic). In short, the Trigger collision type is not working for me.
  9. You probably need to add the included script to Pad 1 and Pad 2, linking to the other pad respectively. The forum was being a pain while I was trying to attach the files.
  10. I'm new to Lua too and wanted to to something similar myself. It probably isn't very good, but my solution was as follows: Script.ObjectDescription = "" --String "Object Description" Script.DisplayTimeMax = 5000 --Int "Display time" Script.Used = "0" Script.DisplayTime = 0 Script.DisplayEnabled = false local font1 = Font:Load("Fonts/arial.ttf", 15) function Script:Use(context) self.Used = "1" self.CurrentTime = Time:GetCurrent() self.DisplayTime = Time:GetCurrent() + self.DisplayTimeMax end function Script:PostRender(context) if self.Used == "1" then App.context:SetBlendMode(Blend.Alpha) App.context:SetFont(font1) self.DisplayEnabled = true if self.DisplayEnabled == true then if self.DisplayTime > Time:GetCurrent() then self.texture = Texture:Load("Materials/Developer/GreenGrid.tex") App.context:SetColor(1,1,1) App.context:DrawRect(598,598,304,104,0) App.context:DrawImage(self.texture,600,600,300,100) App.context:SetColor(1,1,1) App.context:SetColor(0.1,0,1) context:DrawText(self.ObjectDescription, 610, 625) else self.DisplayEnabled = false self.Used = "0" end end App.context:SetBlendMode(Blend.Solid) end end Basically, this allowed me to display a short piece of text with a background when I pressed the Use key over an object the script was attached to.
  11. Even with that stripped down script, the result is the same. The only difference is likely that I am using the default FPSPlayer.pfb. But that has the same Physics mode, Collision type, and script that you are adding to a pivot, so it shouldn't be acting any different. Have you tried your script using the FPSPlayer.pfb? I've tried making a brand new map, using a pivot as the character and again, the same problem occurs. Just in case, I've attached a rar of the new map I just knocked together, along with the script I attached. _temp.rar
  12. Yep. The script acts as if an "exit" is detected when you stop moving and then move again. I.e., teleport and jump, etc. I can solve that by not allowing the script to enable itself, but that makes the teleport one-way. If I then move away from the teleport and re-enter, it won't send me back to the original teleport. The script above is what I think I should work from for the outer pads (the ones I want to use to enable the teleports. The script I am using on each of the actual teleports is as follows: Script.entered = false Script.exited = false Script.hadCollision = false Script.Target = nil --entity Script.Enabled = true --bool function Script:UpdatePhysics() if self.entered then if self.hadCollision == false then if self.exited == false then self.exited = true self.component:CallOutputs("OnExit") --System:Print("Exited") --self.Enabled = true ** this can also be self.Target.script.Enabled = true, doesn't matter it will have the same effect ** self.entered = false end end end self.hadCollision = false end function Script:Collision(entity, position, normal) -- speed self.hadCollision = true self.component:CallOutputs("OnCollide") if self.entered == false then if self.Enabled == true then self.component:CallOutputs("OnEnter") --System:Print("Entered") self.Target.script.Enabled = false --entity:SetPosition(self.Target:GetPosition()) -- Teleports if entity:GetKeyValue("name") == "Player" then EntPlayerCoord = entity:GetPosition():ToString() --System:Print("Player "..EntPlayerCoord) EntPadCoord = self.entity:GetPosition():ToString() --System:Print("Send Pad "..EntPadCoord) TarPadCoord = self.Target:GetPosition():ToString() --System:Print("Targ Pad "..TarPadCoord) end PlayerTable = split(EntPlayerCoord, ", ") --for key,value in ipairs(PlayerTable) do -- System:Print( key .. " has value " .. value) --end SendPadTable = split(EntPadCoord, ", ") --for key,value in ipairs(SendPadTable) do -- System:Print( key .. " has value " .. value) --end TarPadTable = split(TarPadCoord, ", ") --for key,value in ipairs(TarPadTable) do -- System:Print( key .. " has value " .. value) --end -- Will need to use checks like this -- to help cope with minus numbers, etc., when teleporting BaseValue = "0" -- Need to set this to avoid error if SendPadTable[1] < BaseValue then OffsetX = PlayerTable[1] - SendPadTable[1] --System:Print("LT X " .. OffsetX) end if SendPadTable[2] < BaseValue then OffsetY = PlayerTable[2] - SendPadTable[2] --OffsetYa = SendPadTable[2] + OffsetY --System:Print("LT Y " .. OffsetY) end if SendPadTable[3] < BaseValue then OffsetZ = PlayerTable[3] - SendPadTable[3] --System:Print("LT Z " .. OffsetZ) end if SendPadTable[1] >= BaseValue then OffsetX = PlayerTable[1] - SendPadTable[1] --System:Print("GT X " .. OffsetX) end if SendPadTable[2] >= BaseValue then OffsetY = PlayerTable[2] - SendPadTable[2] --OffsetYa = SendPadTable[2] + OffsetY --System:Print("GT Y " .. OffsetY) end if SendPadTable[3] >= BaseValue then OffsetZ = PlayerTable[3] - SendPadTable[3] --System:Print("GT Z " .. OffsetZ) end TargetX = TarPadTable[1] + OffsetX TargetY = TarPadTable[2] + OffsetY TargetZ = TarPadTable[3] + OffsetZ --System:Print ("XYZ: " .. TargetX .. ", " .. TargetY .. ", " .. TargetZ) entity:SetPosition(TargetX, TargetY, TargetZ) end self.entered = true self.exited = false end end function split(s, delimiter) result = {} for match in (s..delimiter):gmatch("(.-)"..delimiter) do table.insert(result, match) end return result end Don't mind the system:prints, I just used those while coding to check what the script was doing. The section commented with ** is where enabling the teleport again is likely causing the problem. This is why I need to work out how best to enable the script again from a different entity. Does this make any sense?
  13. The first suggestion is not going to work, no. I am using the teleports as a way to move players around without their knowledge, so having them specifically hit a button isn't going to work in all situations. The second idea might work, thanks. But again, I could use some help on how best to access variables from an imported script, as half the time I try, they cannot be found (I get the usual attempt to access nil value error).
  14. Yeah, that's the script mine is based on. It has the same problem with it detecting an "exit" as soon as you stop moving even though you're still on the entity.
  15. Reference: http://www.leadwerks.com/werkspace/topic/8462-how-to-pass-variables-between-scripts-lua/ As a follow on to what I was doing in the above topic, I notice that a later update to Leadwerks resulted in my solution breaking a bit. I'm now trying to find a better way to do things. But I have noticed some strange behaviour which I'd like to try and resolve. The following is the basic collision script I am using: Script.entered = false Script.exited = false Script.hadCollision = false Script.Target = nil --entity Script.Enabled = true --bool function Script:UpdatePhysics() if self.entered then if self.hadCollision == false then if self.exited == false then self.exited = true self.component:CallOutputs("OnExit") -- command for enabling placed here self.entered = false end end end self.hadCollision = false end function Script:Collision(entity, position, normal) -- speed self.hadCollision = true self.component:CallOutputs("OnCollide") if self.entered == false then if self.Enabled == true then self.component:CallOutputs("OnEnter") self.entered = true self.exited = false end end end The basic idea is that on detecting collision, the trigger activates and performs what I need it to do. In this case, it's a teleport. As such, it also needs to disable the script for the receiving end. But when entering the receiver a second time, it should allow the player to return to the original teleport. My problem is, the script detects the player as "exiting" as soon as the player stops moving. Thus, the script activates when the player moves again (either when they walk, or change where they are facing). This can cause a loop where the player rapidly moves from one pad to the other. As such, I'm trying to find a good way to ensure the script only resets to its default active state when the player really does "exit" the entity the script is attached to. The solution I thought of trying was to have an outer pad and an inner pad for both teleporters. These would be separate entities of course. Imagine something like: <Pad a [Pad b]> <Pad c [Pad d]> Pad a and c are the outer pads, these I would want to use to enable the scripts connected to Pad b and d respectively. Pad b and d are the actual teleports, they will move the player to the linked pad [b to d, d to b]. But these scripts need to disable themselves as soon as a teleport has finished. The aim being that the player will not then re-teleport until they have actually left the pad (ie, made contact with pad a or c). Could someone suggest a good way to do this? I was thinking of importing the script attached to the teleport pad into the script attached to the outer pad, but could then not work out how to actually interact with the variables from the imported script. All help and suggestions will be greatly appreciated!
  16. I was hoping to have something finished for this, but due to unforeseen circumstances, it looks like I may not be able to after all. Here's hoping I'll be in a better position for the next one =/
  17. So I was just rewatching this tutorial, which is a part of the "Pick Up Objects" tutorial map. It mentions that if you press the left mouse button, the carried object should be thrown. This is not the case. Using that tutorial map, or any map for that matter, the left mouse button does nothing while carrying an object. Was something perhaps changed in an update that has rendered this non-operational?
  18. IIRC Standard cost twice as much as the Indie version when they were sold outside of Steam. So the way it's done on Steam makes sense and doesn't actually cost you more.
  19. Ah, then hopefully I can find some time to give this a try. Thanks Josh.
  20. "You can participate by posting blogs about your game's development" Would that be using the Blog feature here? Can these be used by people with "Members" accounts?
  21. Something that introduces a new user (or returning one, wanting a refresher) to the features in Leadwerks, in a coherent and consistent manner. The tutorial levels, etc., are nice but each one is individual and self-contained. If the features could be introduced while guiding the user in the creation of an end product, it may help with learning how everything interacts together. This need not be anything too complex. It just needs to be a consistent project that walks through each feature. The actual documentation is okay, but many of it lacks a working example to help explain how that feature works. Some have script examples of course, but many of those don't do anything but cause an error if you try to plug that script into a default Leadwerks setup.
  22. Thank you both. That makes it a lot clearer. Rick, you can expect to get a few more questions from me when I start to mess with this (once I have some free time) >_>.
  23. If it's not too much trouble, could you explain this a little more? I've looked at both AnimationManager and SimpleAnimation scripts, and don't get which one you are referring to. The contents of AnimationManager are definitely beyond my current understanding. This would certainly prove useful for a variety of things, so I'd like to gain an understanding of this.
  24. Off topic, I know, but I also wanted to echo this. The kindness and helpfulness of the Leadwerks Community is what makes my feel my $100 was well spent.
×
×
  • Create New...