Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[notajf]

which python be you using

2.x - I'm using 2.7, I'm not sure what Orpheon's using but as long as it's 2.6 or later it will probably work

[Psychopath]

Why is SCOPE_IN and out synced? Can't you simply do the same thing as for cloaking?

For 2.4, I changed SCOPE_IN and SCOPE_OUT to just a simple TOGGLE_ZOOM, it cleans up the code nicely. It's on github if you want to find that.

Cloaking is already synced, just not in the same manner. I don't know the reasoning behind it being there instead of where the special inputs (eating, build menu, scoping) are located. You'd have to ask Medo for that, although, if I'm not mistaken, Cloaking came before those other three. You could try moving it if you want, just don't break shit, I'm not cleaning up your mess if it fails.

[MedO]

How is GG2 licensed? Do we have the blessing of the devs to go ahead?

Yes, we definately do have the blessing of the devs. There's a big thread in the Beta tester forums about this, and I quoted large parts of it in the OP.

You still have to stick to the license if you use anything from GG2. And even if you don't, I think it would be a good idea to add a proper license file soon, so that everyone has some legal safety.

[Vindicator]

which python be you using

2.x - I'm using 2.7, I'm not sure what Orpheon's using but as long as it's 2.6 or later it will probably work

Oh, shoot. I suppose I can rearrange things for my class to use 2.6 then. 3.2's syntax seems different in a few areas so I that'll be a problem.

[Dusty]

Hm, perhaps time to take on a new art style? Like KillPanzer's sprites? Of course I'm joking.

[Mr.L]

which python be you using

2.x - I'm using 2.7, I'm not sure what Orpheon's using but as long as it's 2.6 or later it will probably work

Oh, shoot. I suppose I can rearrange things for my class to use 2.6 then. 3.2's syntax seems different in a few areas so I that'll be a problem.

Tis what i was refering to syntax from 2.x is different from 3.2

[Flaw]

Yeah, I think we should set 2.6 as minimum Python version for project participation. Personally, I'm using amd64-2.7.2.

[notajf]

I am using Python 2.7.1 64bit on Linux

[Orpheon]

I am using Python 2.7.1 64bit on Linux

Me too.

How is GG2 licensed? Do we have the blessing of the devs to go ahead?

Yes, we definately do have the blessing of the devs. There's a big thread in the Beta tester forums about this, and I quoted large parts of it in the OP.

You still have to stick to the license if you use anything from GG2. And even if you don't, I think it would be a good idea to add a proper license file soon, so that everyone has some legal safety.

Hmm, ok. I'm not completely sure how to do it though.

Why is SCOPE_IN and out synced? Can't you simply do the same thing as for cloaking?

For 2.4, I changed SCOPE_IN and SCOPE_OUT to just a simple TOGGLE_ZOOM, it cleans up the code nicely. It's on github if you want to find that.

Cloaking is already synced, just not in the same manner. I don't know the reasoning behind it being there instead of where the special inputs (eating, build menu, scoping) are located. You'd have to ask Medo for that, although, if I'm not mistaken, Cloaking came before those other three. You could try moving it if you want, just don't break shit, I'm not cleaning up your mess if it fails.

What I meant is why we have to sync something that's only relevant between client and server with it's own tag. Why not simply use keyByte?


Also, is there someone here that has any experience with collision code?
I've got this concept which I can't find any flaws inside (except maybe stairs), but it's simply not working.

(click to show/hide)

1. Move the character back to the last position before collision.
2. Move character.x+sign(character.hspeed), test whether there is a collision.
3. If yes, use a while to move the character as far as possible
4. Else if the character.y+sign(character.vspeed) doesn't have a collision; do the same with y
5. Done

Any help?

[notajf]

Orpheon, add a README file to the Git repo - GitHub reccommends having one and we need to include the license (GPLv3)

[Vindicator]

Oh, we're literally porting the whole game graphics and all. Interesting.

Also, anyone want to teach me how to GIT? lol

[notajf]

gitref.org

[Orpheon]

Oh, we're literally porting the whole game graphics and all. Interesting.

Also, anyone want to teach me how to GIT? lol

http://book.git-scm.com/

Also, who suggested changing graphics? Because I hadn't planned doing that.

And I still need help for the collision problem.

[Liam]

I've been looking at collision.py and I'm wondering what the logic behind lengthdir()

Code: [Select]

def lengthdir(x, y):

    x = x**2
    y = y**2

    return math.sqrt(x+y)


acting on the hspeed and vspeed at line 40. And in the next few lines at 49-51

Code: [Select]

# hs and vs is the normalized vector of hspeed and vspeed.
hs = character.hspeed/length
vs = character.vspeed/length

What is a normalized vector?
I see...

Then shouldn't you take the absolute value of the length there?

Like

Code: [Select]

# hs and vs is the normalized vector of hspeed and vspeed.
hs = character.hspeed/abs(length)
vs = character.vspeed/abs(length)

That seems to make the sprite less sticky and I get a bounceback effect off of walls.
But when landing on a surface you'll fall through slowly after a bit

[Orpheon]

I've been looking at collision.py and I'm wondering what the logic behind lengthdir()

Code: [Select]

def lengthdir(x, y):

    x = x**2
    y = y**2

    return math.sqrt(x+y)


acting on the hspeed and vspeed at line 40. And in the next few lines at 49-51

Code: [Select]

# hs and vs is the normalized vector of hspeed and vspeed.
hs = character.hspeed/length
vs = character.vspeed/length

What is a normalized vector?
I see...

Then shouldn't you take the absolute value of the length there?

Like

Code: [Select]

# hs and vs is the normalized vector of hspeed and vspeed.
hs = character.hspeed/abs(length)
vs = character.vspeed/abs(length)

That seems to make the sprite less sticky and I get a bounceback effect off of walls.
But when landing on a surface you'll fall through slowly after a bit

Well...

After staring at the code for a while, I found out that objectCheckCollision is based off rects, which aren't updated during the testing.  

Code: (What I'm working on right now) [Select]

def characterHitObstacle(character, wallmask):



newX = character.x
newY = character.y

oldX = character.x-character.hspeed
oldY = character.y-character.vspeed

hspeed = character.hspeed
vspeed = character.vspeed


length = lengthdir(hspeed, vspeed)

if length == 0:# You haven't moved; if this happens something went wrong

return False


# hs and vs is the normalized vector of hspeed and vspeed.
hs = character.hspeed/length
vs = character.vspeed/length

i = 0
while objectCheckCollision(character, wallmask) and i < length:

character.rect.centerx -= hs
character.rect.centery -= vs
i += 1


# The character got pushed out, but now we need to let him move in the directions he's allowed to move.

character.rect.centerx += sign(character.hspeed)

if not objectCheckCollision(character, wallmask):

# There's empty space on the left/right

# Kill all vertical movement
character.vspeed = 0

while True:

character.rect.centerx += sign(character.hspeed)

# If the new position has met a wall too:
if objectCheckCollision(character, wallmask):
character.rect.centerx -= sign(character.hspeed)
break

else:
character.rect.centerx -= sign(character.hspeed)
character.rect.centery += sign(character.vspeed)

if not objectCheckCollision(character, wallmask):

# There's empty space on the left/right

# Kill all vertical movement
character.hspeed = 0

i = 0
while i <= vspeed:

character.rect.centery += sign(character.vspeed)

# If the new position has met a wall too:
if objectCheckCollision(character, wallmask):
character.rect.centery -= sign(character.vspeed)
break

character.rect.centery -= sign(character.vspeed)


character.x = character.rect.left-character.xImageOffset
character.y = character.rect.top-character.yImageOffset
# character.hspeed = 0
# character.vspeed = 0

# character.hspeed = oldX-character.x
# character.vspeed = oldY-character.y

return TrueThis is still buggy.

EDIT: Actually, damn that code, I'll just make objectCheckCollision update the rects itself.


As for those vectors, it's basically just moving the character exactly one step in a certain direction. Length 1. I'm using the term unit vectors since they work on the same principle.

The point of that loop is to move the character at the last place during movement before any collision.