Universal Fighting Engine 2.0 Beta (Page 1 of 2)

Yes!!!  I'ts finally here!  Take my money!!!

I'd be interested in learning if 2.0's input system allows for the directionals to be interpreted as button presses instead of only axes.

My desire is due to my system I'd prefer it if I can get the input system to function similar to buttons (or digital exclusive), as it makes it easier to calculate and handle diagonals and motion better than the existing axes method.

A use case example would be:
Press and hold forward
- Game recognizes forward is pressed and animates walking forward. Input display shows Forward icon.
While still holding forward, press and hold Down.
- Game recognizes Down + Forward is pressed and crouches. Input display shows Down-Forward icon
While still holding Down, release Forward.
- Game recognizes Forward has been released, remains crouching, and input display shows Down icon has been "pressed"

Current system doesn't recognize that Down has been pressed at the third step, and it doesn't show it in the input display. The user is forced to Hold Forward, Hold Down, Release both, then hold down. Due to the axes.

You can test my desired method by trying it with buttons, which do function in the way i'd want inputs to function.

Considering 1.x will still be updated. I presume that at this time MisterMind is not supporting an upgrade discount? And if I am wrong I apologize and would also be happy to see a discount applied for such a high buy-in cost.

Do you have a price-plan for those of us upgrading yet?

Awesome news MisterMind! But will you still be implementing any new features for UFE 1.x when you release an update for it or will UFE 1.x only have just compatibility updates for newer versions of Unity?

That's awesome thanks for not leaving UFE 1.x high and dry in terms of new features!

Its updated now. For future reference, please make a new topic (instead of replying to unrelated topics).

Good question. I'll try to answer the best I can.

Say you have a multiplier that changes the damage of attacks based on the remaining life points. Before, you had something like this:

public class ControlsScript : MonoBehaviour {
(...)
    public float afkTimer;
    public int airJuggleHits;
    public AirRecoveryType airRecoveryType;
    public bool applyRootMotion;
    public bool blockStunned;
    public float comboDamage;
    public float dmgMultiplier; // Your variable
(...)

    private bool DamageMe(float damage){
(...)
        dmgMultiplier = 1 + ((opInfo.lifePoints - opInfo.currentLifePoints)/100);
        myInfo.currentLifePoints -= damage * dmgMultiplier;
        if (myInfo.currentLifePoints < 0) myInfo.currentLifePoints = 0;
        UFE.SetLifePoints(myInfo.currentLifePoints, myInfo);
(...)
    }
}

It will now look like this:

public class ControlsScript : MonoBehaviour {
(...)
    public Fix64 afkTimer;
    public int airJuggleHits;
    public AirRecoveryType airRecoveryType;
    public bool applyRootMotion;
    public bool blockStunned;
    public Fix64 comboDamage;
    public Fix64 dmgMultiplier; // Your variable
(...)

    private bool DamageMe(Fix64 damage){
(...)
        dmgMultiplier = 1 + ((opInfo.lifePoints - opInfo.currentLifePoints)/100);
        myInfo.currentLifePoints -= damage * dmgMultiplier;
        if (myInfo.currentLifePoints < 0) myInfo.currentLifePoints = 0;
        UFE.SetLifePoints(myInfo.currentLifePoints, myInfo);
(...)
    }
}

In the example above, the only big difference is that you must recast the value from float to Fix64. Now let's say you need dmgMultiplier to be tracked in case of a rollback. In that case you can track by 2 different means: Auto Tracking and Manual Tracking.

Auto Tracking
Its the simplest way, but it consumes more CPU. To use it, under the Rollback Netcode options, toggle "Track UFE Variables" and add the RecordVar attribute to your custom variable:

[RecordVar] public Fix64 dmgMultiplier;

Manual Tracking
More complicated but has 0 impact on the CPU.
To use it, first we need to open UFE\Scripts\Netcode\NetworkCore\FluxStateTracker.cs and find nearby variables to where you are casting dmgMultiplier. Following the example above, you would need to do the following:

(...)
protected static void LoadCharacterState(FluxStates.CharacterState state, int player) {
(...)
        controlsScript.blockStunned = state.blockStunned;
        controlsScript.comboDamage = state.comboDamage;
        controlsScript.dmgMultiplier = state.dmgMultiplier; // Your variable
(...)
}

(...)
protected static FluxStates.CharacterState SaveCharacterState(int player) {
(...)
        state.blockStunned = controlsScript.blockStunned;
        state.comboDamage = controlsScript.comboDamage;
        state.dmgMultiplier = controlsScript.dmgMultiplier; // Your variable
(...)
}

Now open UFE\Scripts\Netcode\GameState\FluxStates.cs and add the casting for the new state variable:

(...)
public struct CharacterState {
(...)
        public bool blockStunned;
        public Fix64 comboDamage;
        public Fix64 dmgMultiplier; // Your variable
(...)
}

Doing this will ensure your variable is tracked and deterministic on all machines.

Now, on a side note, if you have added a new option in one of the editors, remember that aside from casting it to Fix64, you also need to change how the editor reads it:

Before:

moveInfo.elementalDmg = EditorGUILayout.FloatField("Elemental Damage:", moveInfo.elementalDmg);

After:

moveInfo._elementalDmg = EditorGUILayout.FloatField("Elemental Damage:", (float)moveInfo._elementalDmg);

To carry the values from your previous project to UFE 2.0, instead of replacing the casting, create a new variable below your previous one and add the prefix "_". Now add the following to UFE\Editor\UFEUpgrade.cs and run the update:

(...)
private static void SpecialMoveUpdate(MoveInfo move) {
        if (move == null) return;
        move.version = 2f;
        move._elementalDmg = move.elementalDmg; // Your variable
(...)
}

I also hope 2.0 fixes the issue where because levels are dependent on prefabs, you can't use reflection probes or Advanced GI (Which has frustrated me the most about your asset). And it requires source to add the ability to load the .unity file (which most unity games do), that has EVERYTHING I set, including the UFE camera.

I do understand it's to keep the build size small... but I have a lot of per level settings and visual effects (and post effects) that I would end up scripting to load on camera whenever the level loads.

I'll take a look

You will need to study the implementation and apply the changes to your code as you see fit. As described in the netcode page, all usage of floats, vectors and any physic related methods are now using a new variable type. If you know what you are doing and have enough knowledge around C#, it's very much doable.

Just 2.0

Yes. Much like the upgrade options on the Asset Store, you pay the difference in price between versions.
Example: If you bought UFE Bundle ($299) you will pay $1200 for UFE 2.0 Source.

Yes, but since I need a bit more feedback before releasing it, this is how it's gonna go:
The beta version of UFE 2 Source will be available next Monday by email request through Paypal invoice. If you want a discount send me the invoice number of your previous purchase. Once UFE 2.0 is available on the Asset Store I'll provide every customer that paid this way a free copy from the store.

The Pro version might suffer some delay, but hopefully it will come out before the end of July.

Not yet.
Adding that feature in a user friendly environment on top of what UFE already offers will take some time, but if you already developed your own solutions, integration is possible.

I saw the price for it, now if this is built on top of unity I think it might have been best to start off at $300-$400 for Pro, then $500-$650, Enterprise $800-$900. I understand that you guys put in a lot of work, but if it is built on unity & correct me if I'm wrong & its not a stand alone engine, its gonna be seen as over priced. Now starting it at $300-$350 in my opinion makes more sense that it's price point starts at pro version of the previous version of the engine that way those that paid for the bundle version would pay for this version & treat it as an upgrade for bundle buyers only  with a discount of $20-$25 would make more sense & lead to more sales of it from current users of the previous version. Starting it so high will limit its earl adaption rate & even buy new users as they will start questioning why is a unity add on so expensive. Just a thought