"Questions that don't deserve their own thread" thread

Questions about the LÖVE API, installing LÖVE and other support related questions go here.
Forum rules
Before you make a thread asking for help, read this.
User avatar
yetneverdone
Party member
Posts: 302
Joined: Sat Sep 24, 2016 11:20 am
Contact:

Re: "Questions that don't deserve their own thread" thread

Post by yetneverdone » Mon Dec 26, 2016 11:00 am

nyenye wrote:Okay I have two different questions. First of all say that it's a Top-Down view kind of game.

The first one is about "collisions" and the second one deals with Jumper and STI.
  • Collisions - I am using Hardon Collider, and till now very pleased, but right now I am dealing with collisions between two 'dynamic' entities and I get a not expected behaviour. The 'enemy' pushes the 'player'. Is this normal? Attached a video.

    Code: Select all

    function CollisionManager:resolveCollisions()
      -- For every dynamic collider do
      for _, dyn in ipairs(self.dynamics) do
        -- Check if active. If not active then it doesn't collide
        if dyn.is_active then -- if active then
          -- HardonCollider returns all collisions with the current dynamic collider (dyn)
          local collisions = self.hc:collisions(dyn)
          -- For each collision...
          for other, sv in pairs(collisions) do
          	-- If other active...
            if other.is_active
              and ( dyn.mask[other.group] or dyn.mask[Globals.MASK_ALL]) then -- mask filters collisions. Player and Enemy always collide
              if other.mode == Globals.COLLIDER_DYNAMIC then -- If other is dynamic too...
                CollisionManager.resolveDynVsDyn(dyn, other, sv) -- resolve collision for dynamic objects.
              else
                CollisionManager.resolveDynVsOther(dyn, other, sv)
              end
            end
          end
        end
      end
    end
    
    In this code below 'shape_a' is always the one colliding, and the one which should be separated.

    Code: Select all

    function CollisionManager.resolveDynVsDyn(shape_a, shape_b, sv)
      local entity_a = shape_a.entity
      local entity_b = shape_b.entity
      -- In the original code I had more things but it didn't work, so I simplified 
      --   to the minimum (more or less like a dynamic vs static collision)
      entity_a:move(sv.x, sv.y)
    end
    
    Maybe what happens is that the collision is checked two times? One for the player against enemy and second enemy against player. But I don't think it should because when it's resolved one time, its resolved for the two, right?
  • Jumper / STI - Has anyone dealt with Jumper and STI? Is there a standard way to do it? Or do you have to make a matrix map with walkable tiles each time you change a map on Tiled? Or does anyone have a trick to make it more or less dynamic?
Thanks in advance.
PD: game.love is attached

Collision between two dynamic entities will always push the other, since they are both dynamic. Its physics stuff in love2d

nyenye
Citizen
Posts: 62
Joined: Fri Dec 02, 2016 1:44 pm

Re: "Questions that don't deserve their own thread" thread

Post by nyenye » Mon Dec 26, 2016 4:49 pm

Thanks a lot for the insight. I was really frustrated because I didn't see it normal.

About the STI/Jumper problem it's been more or less solved for now. Don't quite like the solution, because it's not very dynamic, but at least I solve it with the Tiled editor, and not with hardcode.

Thanks again!

User avatar
zorg
Party member
Posts: 2428
Joined: Thu Dec 13, 2012 2:55 pm
Location: Absurdistan, Hungary
Contact:

Re: "Questions that don't deserve their own thread" thread

Post by zorg » Mon Dec 26, 2016 8:22 pm

yetneverdone wrote:Collision between two dynamic entities will always push the other, since they are both dynamic. Its physics stuff in love2d
Last i checked, HardonCollider doesn't use love.physics (Box2D).
http://hc.readthedocs.io/en/latest/Main ... collisions
According to that link above, the order with which you iterate over objects matters, so if you think that "the 'enemy' pushes the 'player'" is wrong, then you're simply doing collision detection from the enemy's perspective. (And you do write that only one of the shapes get moved, only it's the "wrong" one.) I might be wrong, but this would be my guess. Try putting an if into your resolver, to only do things if shape_a is the player or something.
Me and my stuff :3True Neutral Aspirant. Why, yes, i do indeed enjoy sarcastically correcting others when they make the most blatant of spelling mistakes. No bullying or trolling the innocent tho.

nyenye
Citizen
Posts: 62
Joined: Fri Dec 02, 2016 1:44 pm

Re: "Questions that don't deserve their own thread" thread

Post by nyenye » Tue Dec 27, 2016 1:23 pm

Hmmm, you where right, I was moving the player instead of the enemy. As I see I'll have to check if entity_a or entity_b is is the one moving toward the collision, and choose what to do. If the two of them are moving against each other, I'll move them both by half of the separating vector, and it should work. Thanks again!

matjojo
Prole
Posts: 6
Joined: Sat Dec 24, 2016 9:43 am
Location: The Netherlands

Re: "Questions that don't deserve their own thread" thread

Post by matjojo » Tue Dec 27, 2016 8:53 pm

Can't figure out how love.math.random works,

I need to get a random number between two limits:

Code: Select all

	love.math.setRandomSeed(os.time())
	Ball.YMovement = 0 - Ball.YMovement - math.random(-RandomBounceLimit, RandomBounceLimit)
where RandomBounceLimit can be just about anything, but mostly between about 100 and 200.

But every time I make the ball bounce, it bounces to exactly the same place, or in other words, the random generator gives the same number back every time. I found out about the randomseed, and set that one to os.time as that would probably be different every time.

still, the number does not change, even if I put a print after setting the new seed the second random number is still the same, being 118.

How do I generate a random number that is different every time?

EDIT: I was using the love random gen, and not the love one, thanks for the help!
Last edited by matjojo on Wed Dec 28, 2016 11:08 pm, edited 1 time in total.

User avatar
pgimeno
Party member
Posts: 1369
Joined: Sun Oct 18, 2015 2:58 pm

Re: "Questions that don't deserve their own thread" thread

Post by pgimeno » Tue Dec 27, 2016 9:04 pm

By changing math.random to love.math.random.
Thrust II Reloaded - GifLoad for Löve - GSpöt GUI - My NotABug.org repositories - portland (mobile orientation)
The MS-Github repositories I had have been closed after the acquisition announcement and will be removed in the near future.

User avatar
Robin
The Omniscient
Posts: 6506
Joined: Fri Feb 20, 2009 4:29 pm
Location: The Netherlands
Contact:

Re: "Questions that don't deserve their own thread" thread

Post by Robin » Tue Dec 27, 2016 10:16 pm

Also, don't call love.math.setRandomSeed, it only needs to happen once and LÖVE already does it for you. You only need to set the seed if you want to do something like minecraft, where you can enter the seed to get a specific world.
Help us help you: attach a .love.

User avatar
zorg
Party member
Posts: 2428
Joined: Thu Dec 13, 2012 2:55 pm
Location: Absurdistan, Hungary
Contact:

Re: "Questions that don't deserve their own thread" thread

Post by zorg » Wed Dec 28, 2016 10:18 am

Robin wrote:Also, don't call love.math.setRandomSeed, it only needs to happen once and LÖVE already does it for you. You only need to set the seed if you want to do something like minecraft, where you can enter the seed to get a specific world.
Even then i'd create a new (dedicated) PRNG object for that, with [wiki]love.math.newRandomGenerator[/wiki]
Me and my stuff :3True Neutral Aspirant. Why, yes, i do indeed enjoy sarcastically correcting others when they make the most blatant of spelling mistakes. No bullying or trolling the innocent tho.

User avatar
ken.athomos
Citizen
Posts: 77
Joined: Fri Aug 05, 2016 10:13 am
Location: Philippines

Re: "Questions that don't deserve their own thread" thread

Post by ken.athomos » Wed Dec 28, 2016 10:30 am

Quick question:

I would like to know what is the best approach (either in general or in love2d game dev) in creating data/variables for a certain entity. What is the more favorable approach? Is it:

Code: Select all

-- [APPROACH A]
local entityImg
local entityX
local entityY
local entityW
local entityH

function love.load()
	-- give the variables value here
end
or

Code: Select all

-- [APPROACH B]
local entity = {}

function love.load()
	-- give the values here
	entity.img = ...
	entity.x = ...
	entity.y = ...
	entity.w = ...
	entity.h = ...
end
Or is this more of an it depends thing?

User avatar
zorg
Party member
Posts: 2428
Joined: Thu Dec 13, 2012 2:55 pm
Location: Absurdistan, Hungary
Contact:

Re: "Questions that don't deserve their own thread" thread

Post by zorg » Wed Dec 28, 2016 11:21 am

It should be the second approach, most of the time.

I mean, table access is just a tiny bit slower than directly accessing variables (not to mention them being locals), but unless you're doing thousands of calculations per frame with them, i wouldn't worry; also, the B approach does give you "encapsulation", so that's nice.

(Also also, my thousands example works more for many entities with similar properities and not in lua, but in c or similar languages, where you do need to worry about cache misses and whatnot; there, using structs of arrays instead of arrays of structs can speed things up tremendously, given that the code used with them goes over properities in order; but yeah, not that important for lua, unless you're using the FFI to use C like arrays instead of lua tables...)
Me and my stuff :3True Neutral Aspirant. Why, yes, i do indeed enjoy sarcastically correcting others when they make the most blatant of spelling mistakes. No bullying or trolling the innocent tho.

Locked

Who is online

Users browsing this forum: Shadowblitz16 and 9 guests