## "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.
yetneverdone
Party member
Posts: 378
Joined: Sat Sep 24, 2016 11:20 am
Contact:

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

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

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!

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

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

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 True 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

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: 8
Joined: Sat Dec 24, 2016 9:43 am
Location: The Netherlands

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

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.

pgimeno
Party member
Posts: 2413
Joined: Sun Oct 18, 2015 2:58 pm

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

By changing math.random to love.math.random.

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

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.

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

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

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 True 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.

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

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?

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

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

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 True 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.

### Who is online

Users browsing this forum: Google [Bot], Majestic-12 [Bot] and 13 guests