Jump to content

Herobot

Members
  • Posts

    17
  • Joined

  • Last visited

Posts posted by Herobot

  1. 22 minutes ago, Josh said:

    The player will exert a force on objects it is standing on if the object has the "Scene" collision type. This is sort of a hack to make it so he exerts force on the see-saw puzzle. Try changing the platform collision type to "Prop".

    This fixed it! Took me a bit to get it working, turns out that the default Platform.lua sets the entity's collison to scene in the start function.

  2. Since the 4.6 update my platforms that use slider or kinematic joints will tilt around the joint position when pushed or stood on by a character controller. It's more pronounced when the character is standing a platform, especially on the edges. This is happening with both the SlidingDoor.lua and Platform.lua scripts even in new projects, ie the moving platforms map included in the fps template.

    Greatly increasing the platform's mass reduces the tilting. At about 100 mass the tilt seems to stop, but this also causes a rubberband effect when the platform moves above a slow speed. I've tried adjusting the limits, friction and spring values on the joints but these seem to have no effect.

  3. You'll need a way for the ammo item to tell that the colliding entity is the player, otherwise the item will attempt to add ammo to something that doesn't use ammo and cause a crash. Add this variable to the player:

    Script.player=true

    Then put this code on the ammo item:

    function Script:Collision(entity, position, normal, speed)
    	if entity.script~= nil and entity.script.player ~= nil then --Check if colliding entity is the player
    		if entity.weapons[1].ammo < player.weapons[1].maxammo then
    			entity.weapons[1].ammo = players.weapons[1].ammo + self.ammoamount
    		end
    	end
    end

    When an entity collides with the ammo, the script makes sure the entity has a script attached and that the entity has the "player" variable, then adds ammo if it does.

  4. 2 hours ago, Josh said:

    I cannot tell what you are doing without a working example.

    Made an example, open a blank project and attach this code to a pivot in an empty map.

    function Script:PostRender(context)
    	context:SetColor(1,1,1)
    	context:SetBlendMode(Blend.Alpha)
    	context:DrawText("This text starts invisible. Press escape and left click anywhere except a menu button to show it.", 10, 10, 300, 100, Text.WordWrap)
    	--mousing over a menu button causes the above text to disappear again.
    	context:SetColor(1,0,1)
    	context:DrawText("Normal DrawText, always visible.", 10,150)
    	context:SetBlendMode(Blend.Solid)
    end

     

  5. I'm using the improved DrawText to show dialogue onscreen with wordwrap, but the text disappears when I interact with the buttons on the GUI menu. Simply mousing over a button makes the text disappear, and it stays gone until I click on an open section of the screen.

    function Script:PostRender(context)
    	context:DrawText(self.text, 10, 10, 300, 100, Text.WordWrap)
    end

    Using the regular DrawText command doesnt cause the text to vanish, but it doesnt have automatic wordwrap. Is there something I can change to keep the wordwrapped text from disappearing?

  6. 17 minutes ago, Josh said:

    Okay, I fixed one thing that would cause the blue boxes to crash.

    The Leadwerks boxes are crashing because when they are hidden they get removed from the list that you are iterating through in the ForEachEntity command! :o

    What I can do is make a copy of the list and iterate through that, to make this safer.

    Wonderful! Thanks for looking into this Josh and everyone else. :)

  7. 2 minutes ago, Josh said:

    Are your saying a child is deleting its own parent in a script?  :(

    I don't think that's the case.

    --This is used for hit detection for the players weapon.
    Script.playerModel = nill
    
    function Script:Start()
    --empty--
    System:Print("Ref Count: "..self.entity:GetRefCount())
    end
    
    function Callback(entity,extra)
    	if entity.script ~= nil and entity.script.targetable ~= nil then
    		entity.script:Hurt(1, extra)
    	elseif entity.script ~= nil and entity.script.repairable ~= nil then
    		entity.script:Repair(1, extra)
        end
    end
    
    function Script:UpdateWorld()
    	if self.playerModel.script.attacking == true then
    		local aabb = self.entity:GetAABB(Entity.GlobalAABB)
    		local v = Vec3(1,0,0)
    		local world = World:GetCurrent()
    		world:ForEachEntityInAABBDo(aabb,"Callback",self.entity)
    	end
    end

    This is the player weapon script. (self.playerModel is set during the start function of the character controller) What i tried to do is while attacking, the weapon checks for entities in it's aabb, and if they have a script, and a self.targetable or self.repairable variable then it calls the entity's Hurt script. This worked in 4.3, and i double-checked to make sure that the weapon's parent (the player model) doesn't have a self.targetable or self.repairable variables.

  8. 8 minutes ago, macklebee said:

    The only crash i get is when I melee the boxes. But I can see if i let this run for awhile there will be issues as the script memory is just constantly rising even when not doing anything. My guess that the issues are somewhere inside the 3 separate player entities with their own scripts you have sitting ontop of  each other?

    That could have something to do with it. I just tried making the weapon a child of a separate crawler model, and the crash doesn't occur (whether the separate model has a script or not). I also tried having the weapon use a global variable to tell if it should deal damage, with it's only link to the player being it's child, and the crash still occurs.

     

  9. I've done some more digging on this problem.

    On 2017-07-01 at 1:45 PM, Christian Clavet said:

    I have a similar issue with NPCs that are seeing the player and become active, then game "lock" for less than 1 second. If they don't see the player, the FPS maintain. I'll try to see if I put a mesh model with no script if it still will do this.


    EDIT: Hi, most of the problems I had came because I was using an old map (updated at each release). Did you tried to make a new project and new map using Leadwerks 4.4. It might fix the issue you have...

    I've tried making a completely new project and map, unfortunately both the slowdown and crashing persist. Although i did discover that my enemy models were still using the old animation manager function, switching them over to using entity:PlayAnimation seemed to delay the slowdown after they aggro the player.

    On 2017-07-04 at 6:32 PM, Josh said:

    Overall, the post-processing shaders (especially SSAO) are going to be slower in version 4.4 because they were updated to give better quality.

    Are these shaders on by default, and is there a way to turn them off so I can see if it affects the slowdown?

    I've also discovered that the crash with entity:Release seems to occur when an entity that's the child of a model calls the function that releases the crashing entity. There's no crash if there's new keyboard or mouse input in between calling the function and the entity:Release.

    I can get around the crash by using entity:Hide instead of entity:release, however in debug mode this causes a different crash:

    59604a379acf5_DebugError.thumb.png.dc18c9f26dfd55c7a4d393a43f4140b7.png

  10. I've been having performance problems with my Leadwerks projects since the 4.4 update. Some of my levels are experiencing massive fps drops, sometimes locking up completely, when they ran at 60 fps on 4.3. I can't pinpoint the cause but it seems to tied to the number of models in the map, any more than 4 (with or without scripts) seems to cause the slowdown. The slowdown seems worse as the player gets closer to the models.

    I've also had trouble with crashes using self.entity:Release(). Once released, the game crashes with a "game.exe has stopped working" message. It seems to happen most when the entity was copied with control+C in the editor.

    Has anyone else experienced these problems? What could I look for to try and fix them?

  11. Thanks gamecreator! I've updated the demo a little, the enemies now aggro in groups and respect the players space a bit more when they're waiting to attack. I see what you mean about jumping on the ramps, I'll need to fiddle around more to see what's causing that. smile.png

    • Upvote 1
  12. This has some pretty interesting mechanics. I like what you did with his arm.

     

    Thanks! I'm planning to replace the arm box with a proper melee weapon once I get a custom character model finished :)

  13. Finally got my first Leadwerks game demo together, looking for feedback!

     

    Game Launcher: http://steamcommunity.com/sharedfiles/filedetails/?id=893683828

    I've had some trouble with the Leadwerks Game Launcher, my demo shows up in the steam workshop just fine but not in the actual launcher for some reason. If it's not showing for others then I also put it on Dropbox.

     

    Dropbox: https://www.dropbox.com/sh/gjwqb7rafk77drw/AAA0yd470eeypYpknXAJ0uSaa?dl=0

     

    I'm trying to do a 3rd person 3d platformer. The current demo has enemies, switches, door keys and healthpacks. The player can jump and use a melee attack.

     

    Press escape to access the pause menu.

     

    Feedback is appreciated! smile.png

     

    Edit: 1.1 update!

    -Enemies now aggro in groups and don't crowd the player while waiting to attack.

    -Added checkpoints, no more respawning all the way back at the start!

    • Upvote 2
  14. I've been using window:Active() to check if my game's window was active or not, to prevent the mouse from being locked in the center of the screen when alt-tabbing. Fired up leadwerks today and suddenly window:Active() is crashing my game with the message "attempt to call method 'Active' (a nil value)".

     

    Has window:Active() been disabled/removed? And if so, is there another way to tell if my game has been alt-tabbed?

    • Upvote 1
×
×
  • Create New...