Forum Fighters: Rewritten (Discontinued)

Hey at the moment I finished the intro, but I’m trying to access the attack hitTime of a specific attack… but I’m stuck:

I thought i could simply access it by making a hitTime variable for the function that gets the attack’s hitTime:

//inside the project.playerAttack function
    this.hitTime = player.attackName.hitTime;

and I tried to set the hitCooldown to the function’s hitTime variable code:

//inside the player cooldown condition, in line 484
player.hitCooldown = (project.playerAttack.hitTime||maxHitCooldown);

I scrapped that idea and tried this instead

//inside the player cooldown condition, in line 484
player.hitCooldown = ( 
project.PLAYER_ATTACKS[project.playerAttack.attackName].hitboxes.hitTime||player.maxHitCooldown);

It didn’t work as I hoped.

I’m just wondering if you guys know how to access the specific attack’s hitbox variables.

Edit: I did learn I could access the function’s variables, so i tried:

//inside the project.playerAttack function
this.hitTime = project.PLAYER_ATTACKS[player.attackName].hitboxes.hitTime;

And tried to set the player hitCooldown to the playerAttack’s hitTime variable

//inside the player cooldown condition, in line 484
player.hitCooldown = (project.playerAttack.hitTime||player.maxHitCooldown);

It came as undefined… so all I have to do now is figure out how to access the PLAYER_ATTACKS’s specific attack object and get its hitbox’s hitTime variable…

1 Like

Made a start anim for story mode/swiftstyle
FFR 1.3.26 v7 (less active intro)5-8-2021_8-56-27.wick (1.1 MB)

I FINALLY DID IT! I ADDED THE HITTIME VARIABLE!!

So I finally figured out pkhead’s code (or was it Baron, I wasn’t paying attention during the coding part last time) and tried to add the hitbox’s attached attackHitboxes.
image

And add the hitbox’s attack variable from there!

AND IT WORKS *insert excited keyboard mashing*
AND I ALSO ADDED A recoilY VALUE! *external excited shouting and shrieking*

and i lost all the data… rats

i’ll do this again at monday. this post is here to note of my comical and melodramatic failures.

m*elodramatic sniffing* i even finished remaking the intro…

5 Likes

How did you just lose it like that?

Wait, just in case I forget.
@Cleetus_Kernel
You still up for the fight?

I thought you could just change hurtAnimFrames to make it work… it should leave the player there immobile for as long as hurtAnimFrames is playing.

so, strange issue.

i made the button animations controlled mainly by code instead of pure animation (only for main, char_select, and arena_select). it would hopefully make the buttons look a bit better and all that. it seems to look nice. for example, in the old version, if you hovered over the button for 1 frame and went out, it would start the hover animation but instantly go to the release animation from the start, so it would jump weirdly. with code, it doesn’t jump around anymore like that.

the problem is that for some odd reason, the more you go through the menus (quick play + back + quick play + back …), the faster the animations play. i don’t know why that’s the case, so if someone can fix that, that would be awesome.

FFR 1.3.26 v7 (less active intro)5-8-2021_10-18-27.wick (1.1 MB)

I think I fixed it - FFR 1.3.26 v7 (less active intro)5-8-2021_16-38-31.wick (1.1 MB)

The issue was that you had a mousehover, update, mousedown, and these events in the default script of the buttons.

When the frame unloads, these events were still attached to the buttons, so when the frame was re-entered, the default script was re-run, and therefore the events were re-added to the button objects, making the animation move double the speed from before.

Therefore, the more that you went through the menus, the faster the animation played.

1 Like

I forgot to save. I forgot what happened, but I might’ve closed the project somehow. I then instinctively opened a version that didn’t have all of the changes because I thought I saved.

The auto save with all the changes was thus gone. oops.

I’m awake now so I’m now re-doing it again!

3 Likes

ok, that works great :) the sparks need to be fixed still though. maybe some other things too.

and… just a slightly irrelevant suggestion, but it’s an idea I had for a bit… what if we put a level of @Jovanny’s Dumbies game in as an arena? (with his permission of course)

2 Likes

I made the arena select buttons also the “new” version as well. (didn’t do the one on the first frame since i’m assuming we will remove that… unless i’m wrong? there’s no point of having a start button there, the user opened the game to play it, so why put an extra step?) i thought i did it the first time, but i guess i didn’t. or i uploaded the wrong file or something.

FFR 1.3.26 v7 (less active intro)5-8-2021_17-59-08.wick (1.1 MB)

1 Like

wait @awc95014 could you help out with this?

i gotta do math homework so i’ll be busy for a bit, then i’m gonna do my own stuff, but yes, i’ll do those eventually.

except for the knockback thing. it’s just how the engine works. I will make the dash attack deal less vertical knockback though.

although… i can make air friction less than ground friction with some majik :mage: :woman_mage: but i’ve played scratch games with no air friction, only ground friction, and they’re hard to control. the current engine is more predictable.

  • air friction less than ground friction, more realistic… not really but sorta
  • leave it as it is, it’s easier to control, simple as that

0 voters

tldr, i will update it so that the dash attack will do less vertical friction. air-friction-vs-ground-friction stuff shouldn’t matter unless yall really want it. i don’t… but it’s a team thing, and a vote is the easiest way to do this.

2 Likes

So I’m finally back in the state that I was in where I made progress, though I’m not sure how to improve the intro now.

FFR 1.3.26 v9 new intro

wait a second…

ah. *reads comments in code* ooooh… okay I’ll fix that up first :man_dancing:

The small attack update

So 2 new things relating to attacks (might be significant so it’s here just in case):

//A few new toys I'm trying out to make attacks with hitbox properties

- hitTime: how long the player is stuck in the hurt state for
- invTime: how long the player is invincible for
- recoilX: (its the one that pushes player backwards, not new)
- recoilY: number the player would move upwards
- recoilCancel: when true, forcefully replace attacker's velocities it with recoil X and Y
/*Baron, you were thinking about adding cancellable boolean,
does it cancel a current attack upon using another move or...?*/

Another thing is a neutral air attack. It’s… something.
FFR 1.3.26 v9 attacks

I do want to try to make the players bounce off the walls while in the hurt phase, so that’s what I’m planning to do next.

Meanwhile you guys can tweak the attacks to make it more balanced. I kindof made it easier for players to dodge the neutral attack.

Meanwhile this thing:

image
I thought it would give time for the browser to load the introsong by making a functional loading screen, but I’m not knowledgeable in that area (it also sounds redundant since we have a Wick Loader for that).

In this update I do want to try the HowlerJS method to check if the song has loaded.
image
I really don’t know how it works, and it threw up an error.

Regarding the VCam, It would be nice to still use it for bigger stages… unless…

  1. Do we have a method of moving the player’s view without using the vcam?

2 more questions for some other stuff unrelated to each other:

  1. I didn’t get to ask, but why are we keeping the size of the game low, and is there a size that we want to avoid reaching?
  1. So how far are you in finishing it? :eyes:

Here’s the update:
FFR 1.3.26 v9 (changed intro and attack properties) patch1.wick (1.1 MB)
there was a patch I had to make to fix the countdown looping on finished.

3 Likes

2 things Mr kringles

  1. You are a man of many many talents m8,
  2. [quote=“KringlePrinkles, post:1264, topic:5887”]
    So how far are you in finishing it? :eyes:
    [/quote]

Yes, around 1/2 there…

well, i’ve clearly been greatly overwhelmed in the vote (yes, “i”, nobody else voted to leave it as it is), so i’ll try to make air friction seperate from ground friction. we can try it out, and if it feels too slippery, we will change it back. sound good?

and in the mean time, i’ll edit the attacks to be a bit more realistic.

2 Likes

I feel like I’m not helping enough (only been fixing basic bugs lately)
Also, expect me to be more inactive on the forums (read profile description to know why)

That’s why I wanna start getting more things done!
Since Baron is currently coding, lemme know if there’s anything I can help with “art-wise”

Also, don’t ask why I made this, but I tried to re-drew pk’s character bc I haven’t drawn something on Wick for a very long time (I’ve been spending too much time coding, that my drawing skills feel like they’re dropping :chart_with_downwards_trend: )

But umm… one issue is that I used the brush tool a “little” too much ⊙_⊙

Anyways, I will probably redraw and try to make it look better, and draw other characters too and add a background until I get a perfect final drawing that you guys can add with the “random art” thingy collection

4 Likes

only patch made is that I reverted the countdown back to the old one (with a minor modification). this is because if you play a second time, the 2 and 1 would zip by in 1 frame. i inspected the animation to realize there was much more than animation there (code was there too, making things overengineered and bugged).

i made it this way the first time because we could edit the animation more easily. what if we wanted to grow/shrink the countdown as it counted? or make it spin in and out? you can’t easily do that with the code. plus, it’s overengineered. the original way lets me do that very easily, it’s pure animation. (if you couldn’t tell already, i like simplicity that works well.)

sorry for the rant, i just wanted to explain why i did it.

about the attacks, i decided that we should actually get the characters in first, then tune the attacks. there’s no use in tuning PoC attacks. also, just saying, you can fly if you constantly up attack.

and other problem thing, things are broken when you approach the top of the screen. the physics kinda break, it sorta tries to force you down. it pushes the y-value of the players, pushing them through the blocks. (you should only deal with xv and yv with my platformer engine)

i’m pretty sure it’s code doing that, but i don’t know where to even start looking. if anyone knows, please remove it, thanks. for the person who put that in the first place, we can just put a ceiling to the maps to stop the players from going up.

here’s a video of it. (i got the white screen of death trying to bring the vcam back, but it’s fine, the file is here still.)

FFR 1.3.26 v9 (changed intro and attack properties) patch25-9-2021_17-17-42.wick (1.1 MB)

1 Like

Huh… I did find this piece of code while I was trying to figure out how to add attack properties…

    // Avoid high jumps {
    if(player.y<project.height/10){
        player.yv+=(0.1-player.yv)/5;
    }

So I tried it WITHOUT the code…

…and WITH the code…

I’m not gonna upload it yet (because it’s a waste of productivity, but that’s just me), so I feel like we could start designing our character attacks since Baron mentioned it. We can balance some things along the way.
We could use nugget’s jamboard that he created:

Ah right! @awc95014 will the characters unique hitboxes for each of them? I’m not sure yet how player hitboxes are implemented in this game, but it’ll be nice to know if we can make them unique for each character clip.

3 Likes

the hitboxes are just the size of the player clips. you can change it in the editor just be resizing them, and i’m sure you can do it in the code. (i’m pretty sure anyway, that’s how it is in the engine, but idk what the other code does to it)