Modding Help Need some input on choosing between two solutions.

Discussion in 'Starbound Modding' started by @lias, May 21, 2017.

?

Option 1 or 2?

  1. Option 1, for style!

    1 vote(s)
    33.3%
  2. Option 2, for safety!

    2 vote(s)
    66.7%
  1. @lias

    @lias Void-Bound Voyager

    Guess who's back, back again? @Lias is back, tell a friend.

    I've been working on something real cool, and this time it's something that actually works! As in, I've got it working ingame works, which isn't bad for someone who didn't know what a table was a month ago. Progress!

    What it is, is a sort of pseudo character replacer. A little while ago I found out that you could animate status effects with the same flexibility and nuance as you could anything else, and immediately started brainstorming ways to put that to work. Cut to a short while later, and now I've got a system that uses a status effect to render the player invisible and draw a sprite that perfectly(and I do mean perfectly) mimics the action the player is doing at any given time. I can also change the player's hitbox, physics, and other minutae like hurt sounds and mouth position(for breathing calculations), and because it's a status effect it doesn't hamper item use. Obviously it's not without shortcomings, but I'm pretty darn proud of what I've got.

    Anyway, to get back to the reason I've posted this thread, I've reached an impasse regarding how I want to solve a problem. There's two possible solutions, and they both have their pros and cons, so I was hoping you could help me decide.

    Option 1 is what I'm currently running with. When activated, it sets the new hitbox and sprite at the center of the player character.
    Pros:
    +I don't have to muck about much with offsets
    +Items held and used by the player will rotate much more naturally around the new sprite. Most melee weapons have their damage sources centered around the player's own, so this makes things like aiming and damage polys look much more natural, even though the weapons themselves are still invisible.
    +If turning into something smaller than the player, you'll fall a short distance to the floor after changing, which looks cute.
    Cons:
    -The cloud of particles produced when jumping and landing are still centered at the player's old foot position.
    -If the new size is significantly smaller than the player's old, you can and will get stuck in the ground when changing back and have to either noclip out or change again. Currently the only way to not get stuck is to deactivate the status while jumping, which is... less than ideal.

    Option 2 is setting the bottom level of the new hitbox to match the bottom level of the default hitbox.
    Pros:
    +Seamless changing back and forth, no getting splinched in the ground.
    +The dust for jumping and landing is in the right place.
    Cons:
    -The rotation center for held items will be off, either above or below strangely-heighted forms.
    -I'll have to do much more with offsets.

    Personally I'd much prefer option 1, but if I cannot fix the cons I'll have to go with 2.

    Two questions, additionally.
    A: Is there a way to check to make sure there's enough space for the player to change back? I know the distortions sphere probably does something like this but I wasn't able to find what I was looking for in it.
    B: Is the appearance of the jumping/landing dust clouds hardcoded?

    Thanks for reading!
     
  2. bk3k

    bk3k Oxygen Tank

    What about with option 1, right before your transmission back you teleport the player slightly so you won't get stuck? That's fairly easy.
     
  3. DraikNova

    DraikNova Ketchup Robot

    Actually, if you get stuck in the ground, just using the distortion sphere will usually bring you back up. Either way, I'd love to see the code for this.
     
  4. Cyel

    Cyel Scruffy Nerf-Herder

    Code:
      self.basePoly = mcontroller.baseParameters().standingPoly
      self.collisionSet = {"Null", "Block", "Dynamic"}
    [...]
      local pos = restorePosition()
      if pos then
        mcontroller.setPosition(pos)
      [some kind of thing to force the player to change back after some time pressing the tech key as to avoid being stuck forever here]
    
    [...]
    function restorePosition(pos)
      pos = pos or mcontroller.position()
      local groundPos = world.resolvePolyCollision(self.basePoly, {pos[1], pos[2] + positionOffset()}, 1, self.collisionSet)
      if groundPos then
        return groundPos
      else
        return world.resolvePolyCollision(self.basePoly, pos, 1, self.collisionSet)
      end
    end
    Maybe /animations/jumpsmoke is what you're looking for? In /player/playereffects.animation:
    Code:
      "jump" : {
      "transformationGroups" : ["flip"],
      "particles" : [
      {
      "particle" : {
      "type" : "animated",
      "animation" : "/animations/jumpsmoke/jumpsmoke.animation",
      "fade" : 0.9,
      "position" : [0.0, -3],
      "timeToLive" : 0.4
      }
      }
      ]
      },
    I'm eager to see where you're going with this!
     
    Last edited: May 25, 2017
  5. @lias

    @lias Void-Bound Voyager

    Hello Cyel, bk3k, it's good to see you again! Sorry it took me so long to reply, but it feels like Sundays are the only days I have time to work on things anymore. Busy, busy, busy.

    So, on to updates!
    The height on transforming problem ended up being a much easier fix than I had anticipated, which was a welcome turn. All I had to do was tack an mcontroller.translate that scoots the player up the pixel difference between the floors of the old and new hitboxes into the uninit block of my lua file, and transformations are basically seamless now. One line of code, one problem solved. I really wish all fixes were that simple...

    The dust clouds are still an issue, but at least I know where to find them now. I tried using directives to multiply them into invisibility but it doesn't seem like you can affect the visuals of things that aren't directly connected to the player, at least not through a status file alone. I'm drawing a blank of other angles I could take to hide them, but it's a minor enough issue that I can overlook it for the time being.

    With both of those problems solved(or at least not posing an immediate hindrance to the player), I can proceed with option 1! Which is nice, because I was not looking forward to all the busywork I'd be doing to pull off option 2. Thanks for the advice and input.
    There are still a few standing issues, but they should be easy enough to work around, fix, or otherwise ignore. Namely the major issues are as follows:
    1: The setparentdirectives line that renders the player invisible also renders held items and melee swooshes invisible. Projectiles are still visible, so my current thought is to make a series of weapons mimicking monster attacks such as claw swipes, bites, etc. that exclusively create projectiles like how the old system of melee weapons used to work.
    2: Interactions with furniture are borked. Transformations hover over chairs and don't change rotation while resting in beds. I already have several ideas on how to fix these, but it's not really a pressing issue at the moment.
    3: I haven't had the opportunity to try it in a server setting, so I don't even know if status effect visuals show up for other players or if they're client-side. I'd be gobsmacked if they didn't though.
    4: It can't tell what your arms are doing, but the flexibility it otherwise offers makes me feel like this is a fair trade.​

    I've been kind of dancing around what it CAN do, though. Some of the bullet points:
    * Supports all of the basic types of animation with great accuracy! This includes running and walking with separate animations for backwards movement, jumping and falling, crouching, and swimming.
    * Any of these animations can be as simple or complicated as desired, frame-wise, and can be made to loop, end, or transition into other animations.
    * The potential is also there for nonstandard animations that don't have to do with basic movement, such as animated idle frames and differing animations based on health thresholds. Depending on whether or not I'm right about being able to use specialized status effects as a convoluted form of animation trigger, it could do much more.
    *Alter nearly any physical property of the player, from mass to land/sea/air speed, to health pools, to hitboxes, to hitsounds, you get the idea.​

    There are a couple of maybes and hopesos, too. Like, for instance, because it's a status effect it should also be applicable to monsters or even other players, though I haven't tested it. Also I'm pretty sure that if I could find what made the player's emotes tick I could rig up a similar system so the transformations had expressions too. I dunno if it's possible, but I'd really like to be able to change an affected player's damageteam or something so enemies ignore you while transformed. Plus if there was a way for statuses to check what buttons a player was pressing I could just start going crazy, but I'm 99% sure that one's hardcoded.

    Oof, that post got a little long in the tooth, didn't it. Sorry, got a bit worked up.
    Anyway, I'd like to do a small demonstration or something, but it would be a really big gif. Does anyone have any recommendations for recording software, maybe I could put up a Youtube video or something?
     
    Cyel likes this.
  6. @lias

    @lias Void-Bound Voyager

    Still working on this. I have more time than usual this weekend, so maybe I can get some significant stuff done.

    Current progress: Today I discovered I can apply status effects to or during various movement states. Right now I have a Nutmidgeling form that gets a lowgrav effect only when falling, an Oogler with speed boost while running but a slow effect while walking, and one of those little rock guys everyone hates that cranks your defense way up as long as you're crouching. The more I sift through the various functions, the more paths open up. It's kinda cool, even if I probably won't be able to use most of them the way I'd like.

    Actually, if you've got the time and it's not too much trouble, there's a question that's been bugging me. Is there a function to check whether a player has a specific status effect? I know there are functions to determine whether the resource-related statuses are positive or not, like health or air, but I'm not finding anything that specifically checks whether the player has general-variety status effects such as Runboost or Rage. I thought that maybe status.getPersistentEffects might do it, but it only does Persistent Effects, as the name implies.
     
  7. Cyel

    Cyel Scruffy Nerf-Herder

    ?
     
  8. harvie89

    harvie89 Void-Bound Voyager

    T~Teach me senpapi!
     
  9. @lias

    @lias Void-Bound Voyager

    Huh. I checked the unpacked docs and sure enough, there it is. The resource I've been looking things up from must be a little out of date, because it doesn't have that one listed. Thanks.

    Also I asked around and people told me to use OBS, so I'm probably going to spend some time figuring out how that works. Never uploaded a video to anything before, should make for a good learning experience.

    Soon.
     
    harvie89 likes this.
  10. @lias

    @lias Void-Bound Voyager

    Well, here it is. A short demonstration of what I've been working on. Sorry about the awful quality of the video, and the fact that it's not edited, but it was hard enough to wrangle the program in the first place, and this was after multiple rerecords. I am not good with computer.
    Hopefully this gets all the basic points across OK, there's no text but I tried to pantomime things out.
    I actually have a slew of questions and other things I need to ask you smart modders about, but I'm gonna save it for tomorrow when I have all my notes together and it's not late as.

    BE UNDERWHELMED
     
    DraikNova, Cyel, Inf_Wolf14 and 2 others like this.
  11. Cyel

    Cyel Scruffy Nerf-Herder

    (If I may add, ithink you can change the 'ouchNoise' with
    Code:
    status.setStatusProperty("ouchNoise","/sfx/tech/honk.ogg")
    Don't think you can change the footstep sound tho? Unless breaking the walk itself but I think I remember you saying those were looking at the player's animations to do stuff -- and you'd probably need to redo all the maths for movement speed and handle collisions etc....
     
  12. @lias

    @lias Void-Bound Voyager

    I completely forgot SB switched to Vorbis files, despite going through a bunch of animations and seeing .ogg over and over again. I guess that's why the .Wavs I tried to replace ouchNoise with didn't do anything.

    And yeah, I'm pretty sure you can't swap out the default footsteps because they're linked to the player's animation file (which I can't find anywhere? seriously where is that thing), but you can give the overlaid animation sound effects on specific frames with frameProperties and make them slightly louder than the default foosteps so it kind of cancels out. If you listen closely during the Oogler part of the video, you can hear it making its gross slapping footsteps while it runs, and that's how.
     

Share This Page