User Tag List

Results 1 to 10 of 19

Thread: Large Link Hitbox Doesn't Detect Collision Properly

Hybrid View

Previous Post Previous Post   Next Post Next Post
  1. #1
    Keese Just registered
    Join Date
    Jan 2018
    Posts
    31
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    vBActivity - Stats
    Points
    315
    Level
    6
    vBActivity - Bars
    Lv. Percent
    50.38%
    Any word on this Link->Extend function lately?

  2. #2
    The Timelord
    QDB Manager
    ZC Developer

    Join Date
    Oct 2006
    Location
    Prydon Academy
    Posts
    1,396
    Mentioned
    112 Post(s)
    Tagged
    1 Thread(s)
    vBActivity - Stats
    Points
    4,766
    Level
    21
    vBActivity - Bars
    Lv. Percent
    69.92%
    Quote Originally Posted by Downloader View Post
    Any word on this Link->Extend function lately?

    Not yet, and it's somewhat tricky. I will eventually get to this, but IDK when.

    The issue is that the internal checking for collision with Link is not uniform. Everything uses a different routine to do this, and it needs to be unified, first.

    What I need to do, is add a set of collision routines in FFCore, and move all internal collision checking to those. For Link, this means collision with enemies, collision with ffcs, collision with weapons, collision with items, collision with map flags, and collision with combo types.

    Ideally, all collision events will process through FFCore, setting up a series of internal pair-based collision flags, that the user will be able to easily read by script. Dispose of manual collision checking in FFScript, and allow ( if type->Collision(ptr) ). That way, internal engine collision becomes more sane, and script collision checking returns engine collision.

    Anyway, once there is uniform collision checking for Link, adding all of the hitbox vars will be easy, and those will also exist in Link's ZQuest config, where I plan to add a number of settings, including hitbox size, sprite size, defences, states ( e.g. visibility, transparency, diagonal movement, and tile overlap, other values).

    None of these should remain as 'rules', but rather, be transformed into initial settings that the user can modify by script at any time.

Thread Information

Users Browsing this Thread

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

Tags for this Thread

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