User Tag List

Results 1 to 3 of 3

Thread: _L_: Jump Floatiness Bugfix ¬_¬

  1. #1
    &&
    ZC Developer
    Joe123's Avatar
    Join Date
    Sep 2006
    Age
    32
    Posts
    3,061
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    vBActivity - Stats
    Points
    7,303
    Level
    26
    vBActivity - Bars
    Lv. Percent
    8.74%

    _L_: Jump Floatiness Bugfix ¬_¬

    * Finally remembered to reduce the 'floatiness' at the apex of Link's jump. I know a few people were unhappy with it, so here it is. This should only slightly reduce the distance of Link's jump, but if you were counting on that exact jump length... maybe you could try lowering the Gravity variable a little bit? ( _L_, 2007-11-04 07:50:25 )

    _L_, in doing this you've apparently broken my roc's cape script.

    Would you mind informing me of exactly how you've changed this to differ with the older version?

    How many frames it now takes for Link to reach a jump height of two from standing would be nice, along with any other changes you've made. I'm using the Hover Boots with a duration of 15 at the moment, which used to correlate to 15 frames before the hoverboots kicked in, then 60 frames (so delay duration*4 frames) before they stopped. This is no longer true.

  2. #2
    Developer
    ZC Developer

    Join Date
    Aug 2006
    Location
    Australia
    Age
    37
    Posts
    2,777
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    vBActivity - Stats
    Points
    6,851
    Level
    25
    vBActivity - Bars
    Lv. Percent
    37.71%

    Re: _L_: Jump Floatiness Bugfix ¬_¬

    Here's what I did!

    The number of frames that Link spends at the apex of his jump without Z movement (that is, where his Jump value is less than 1) has been cut by two.

    (P.S: What is this Roc's Cape script? If I was making it, I would simply put a hard cap on the negative minimum of Link->Jump for awhile.)

    (P.P.S: That reminds me: currently the Link->Jump value is scaled up to match Gravity. Now that you can edit Gravity, this behaviour seems a little unintuitive, so I might change it.)

  3. #3
    &&
    ZC Developer
    Joe123's Avatar
    Join Date
    Sep 2006
    Age
    32
    Posts
    3,061
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    vBActivity - Stats
    Points
    7,303
    Level
    26
    vBActivity - Bars
    Lv. Percent
    8.74%

    Re: _L_: Jump Floatiness Bugfix ¬_¬

    Hrmmm

    Right ok. Well how does that mesh with the hoverboots then?
    I think I'm just going to have to experiment and change things around really arent I.

    All my script does is give Link a LTM item that changes his walking sprites to using the Roc's Cape whilst he's using the hoverboots
    http://www.youtube.com/watch?v=7ZRNcXvUi1E

    Code:
    		if(usecape == 1){
    			timer3++;
    			if(timer3 == 15){switch2 = 1;}
    			if(switch2 == 1 && Link->Z > 18){
    				Link->Item[cape] = true;
    				timer2++;
    				Link->InputA = false; Link->InputB = false;
    				if(Link->Z <18){usecape = 0; Link->Item[cape] = false; switch2 = 0; timer2 = 0; timer3 = 0;}
    				if(timer2 == 60){usecape = 0; Link->Item[cape] = false; switch2 = 0; timer2 = 0; timer3 = 0;}
    			}
    		}
    It's only really a few lines so I'll go fix it in due course.
    Which will wait until you've finished messing with how it interacts with the gravity, because I don't really want to have to change it again.

    The jumping layer threshold is really great though, thanks for that.

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
About us
Armageddon Games is a game development group founded in 1997. We are extremely passionate about our work and our inspirations are mostly drawn from games of the 8-bit and 16-bit era.
Social