1

(2 replies, posted in UFE 1 Source (Deprecated))

I've managed to at least uncover exactly WHERE the problem was happening. It's not that the FixedUpdate is taking too long or anything like that. It's because the bothReady is returning false quite a lot of frames. While using the P2P implementation, bothReady is false once each 15 frames or more, so you can barely tell that the game wasn't running well. While using Photon it's like once each 3 frames or even worse.
Looking at the code that happens because the inputBuffer count of the RemotePlayer isn't higher than the currentFrameOffset, and that happens quite a lot with my Photon implementation. Whenever that happens, UFE will simply stop and wait. I can't seem to think of a way to fix that without making it so Photon updates like 10 times faster than it is currently. Yes, I already tried to increase the SendRate, it helps just a little. Apparently there's a limit for the SendRate.

If I could get anyone that has a deeper understanding of UFE's code or Networking in general that'd really help.

So I've managed to stitch together a "working" Photon implementation with the Network support of my UFE Bundle. Problem is that apparently there's a massive slowdown in the game while running on Photon. Even the countdown isn't updating each second, but each 3 more or less. The thing is, the fps is fine, both clients are running at 60fps. From what I can tell after some tests, it's the FixedUpdate of UFE that's taking too long, and apparently after checking if both players are ready is their IsReady. I can see that by using Debug.Log just before checking the bothReady boolean is true, and another Debug.Log inside that condition.

The Logging just before the condition is running almost 3 times more than the one inside, like this
http://i.imgur.com/Pfd1zZv.png

If I select the option to use the normal P2P implementation everything works nicely.
Any help is welcome, I've been stuck on this for quite a while.



Update on the post below

Reading the changelog I saw that, apparently, the version 1.8 solved a problem I was having with one of the players not being able to use chain moves

Fixed issue where moves with 2 button execution would not link using chain moves

the problem is that right now it's not feasible for me to upgrade from 1.7 to 1.8, as that would break a bunch of stuff that I simply don't have time right now to try and deal with. As this is the only problem I'm having with 1.7, and I do have access to 1.8 as I've bought the UFE Bundle, I wanna know if there's a way for me to "backport"  that 1.8 fix to my modified 1.7, as just fixing that seems to save me way more time than trying to upgrade the entire UFE.

Thanks for your time.

4

(4 replies, posted in UFE 1 (Deprecated))

Haritha Denuwan wrote:

In fact , story mode is a survival battle , try to customize it!

Thanks, I managed to string together a survival mode based on Story Mode. Wonky but it's working.

5

(4 replies, posted in UFE 1 (Deprecated))

Hello. As said in the title, I have no idea how add a new game mode and configuring it to work like a Survival Mode. A Survival Mode being a mode that only ends when the player loses all of his health, and his healthbar is shared between battles. There are essentially "endless battles" as long as the player is alive. When he wins a round, a new opponent appears and he goes through it again.
I have UFE Source. Thanks for your time.