Lagless

[John Doom]

Removes lag spikes, increasing performance.

DOWNLOAD: https://www.nexusmods.com/daggerfallunity/mods/288

[chtujo]

Is there any reason why this can't be integrated into the base game? This doesn't seem like it should need to be a mod to me. Good job regardless.

[John Doom]

Is there any reason why this can't be integrated into the base game? This doesn't seem like it should need to be a mod to me. Good job regardless.

Thanks for your reply. I actually tried asking to integrate it into the base game, but wasn't possible: https://github.com/Interkarma/daggerfal ... /pull/2289

[BadLuckBurt]

I actually tried asking to integrate it into the base game, but wasn't possible: https://github.com/Interkarma/daggerfal ... /pull/2289

You need to stop saying that and read better. You being unable to invest more time into pinpointing the issue does NOT equal 'wasn't possible'. Interkarma is very clear in the text I've made bold that he's willing to continue the conversation. It is not uncommon for PRs to be closed or put on hold until the issue they try to address is more clear and normally that is done by someone who is actually experiencing the issue, which would be you.

If you're experiencing ongoing drops down to 15fps, that sounds very much like a local issue. All I can suggest for now is comparing your performance to a clean build (new DaggerfallGameFiles method > new folders > new settings.ini > no mods) and see if the problem continues. If you don't experience frame drops moving around town in clean build, the next step would be a fresh clone of the source project and try to better identify where the lag is coming from.

I do believe you that you're experiencing something here, but I don't observe same. We'd first have to identify we're even fixing the right problem to start with before changing any code.

I'll close this one for now. Please feel free to update comments and I'm happy to continue conversation. I may not be able to help much more, but I'll do my best. Good luck!

[John Doom]

How are discussing and closing the pull request compatible, especially if i gave him all proofs I had and still he wouldn't believe this was an issue? Bah, let people judge.
I have great respect for InterKarma; that said if he doesn't want to patch this issue because he doesn't want to mess with the codebase at this stage, i'm free to fix it as a mod and share it with other players

[BadLuckBurt]

especially if i gave him all proofs I had and still he wouldn't believe this was an issue?

That is a lie, I will show you the quote again, IK clearly states he does believe that you're experiencing SOMETHING but that he doesn't observe the same.

I do believe you that you're experiencing something here, but I don't observe same. We'd first have to identify we're even fixing the right problem to start with before changing any code.

And I'm just going to post what I said on Discord already since it pretty much fits your response to a tee.

At the moment we don't even know what it's for. Nobody has complained about these lag spikes but you and while you may have actually fixed an issue, you are unwilling to discuss it, elaborate on it and appear to get triggered whenever someone does not do what you expect. Two screenshots is not proof that you fixed anything, especially when it involves profilers. If this were a widespread issue, a lot of people would be posting here complaining about lag. And if you want profound changes to be accepted into the code base, you'll have to be prepared to make a case by showing multiple examples etc. and maybe try explaining why your approach would be the better one.

It's a theme with all your stuff, there is no value in the descriptions you add and when people ask you to elaborate it's all minimal effort. I understand English isn't your first language but you are clearly intelligent enough to do better.

Read up on software development rules, etiquette etc. It's quite obvious you're new to this. IK has every right to close any PR he is not going to merge, it's called project management and keeping things organized, mostly for your own sanity. He invited you to comment to continue the conversation but so far you haven't followed up.

It's fine if you just want to keep this as a mod now, it fixes your issue and if anyone else comes on the forum to ask about this problem we can just direct them to your mod.

[King of Worms]

Must agree with BadLuckBurt here... would be good to cool off, add some more description etc, exactly what he posted in a last msg. But closing the PR seems like a end of discussion to me? Because, how can the communication go on?

EDIT: tested the mod and it did not remove lag spikes from my game. Its a modded game mind you, so I cant say if it helps with vanilla. But I dont have any lag spikes in vanilla, thats the thing.

To test lag spikes ingame, you have to have MSI afterburner and frame-time graph enabled, not just FPS counter IK was refering to tho. MSI can show u 60fps locked but frame-times can look really bad at the same time.


IMG BELLOW
The lag spike in the img is serious, and on the fps counter it showed as 57 fps briefly. So unless u are sensitive to this and use only FPS counter to measure it, you will NOT notice it. But the frame time graph shows everything. Those two small lags before the big one, you will never notice.

Untitled-2.jpg (348.91 KiB) Viewed 1814 times

[chtujo]

I'm not a software developer, so I can't speak as to whether John Doom's conduct is appropriate or not. However I do also experience several of the same frame drops as him. I tested in a dungeon in build 0.13.4, with all mods disabled. I only tested 4 of the frame drops listed on the mod's Nexus page:

- when a new spell is cast;
- when being hit by a new spells;
- when a new enemy is killed;
- when you first hit an enemy;
- when a new NPC is spawned in town.

...and 2 of them occurred for me. I can recall similar frame drops occurring many times before. I haven't complained about these only because I'm too lazy to test fully. Keep in mind this is not a clean build, and with a save that I have been playing for a long time.

Edit: I should mention, I haven't tested this mod to see if it resolves my frame drops.

[King of Worms]

Than test it

[hurleybird]

Sorry, but looking at it I don't blame InterKarma for rejecting the PR.

I disagree with IK on the "local issue" bit (EDIT: after reading through his full responses, and not just the quoted text from earlier, I probably don't). Clearly, whether the issue is mods that hit the PopulationManager, weak single threaded performance, weak IO (my guess), other tasks that are consuming CPU time, or some combination of the above, you're exposing a performance bottleneck and alleviating that is a good thing in and of itself. If you're hitting it, other people are hitting it too, or may in the future if other areas get faster.

But I don't like your solution.

You're changing a huge number of regular methods into coroutines, which isn't a C# feature but a Unity invention. This has a significant cost above and beyond the small overhead of starting a coroutine. Coroutines have a lot of edge issues. With the amount of changes you made, it wouldn't surprise me if you created a few bugs. It would be more of a surprise if you didn't. And when you have an issue that spans multiple frames and coroutines it can be a bitch-and-a-half to debug, so you're also making future issues more difficult to fix. To make matters worse, both the VS and Rider debuggers have had sporadic issues stepping through coroutines.

I'm not sure which scripting backend IK has DU on now, but for what you're trying to do, the new best practice is async-await. Unity Technologies now only recommends coroutines for fire-and-forget situations. Async-await also has its own pile of potential issues if you aren't experienced and careful in their use though.

Which is why before you do anything drastic like spreading the work over multiple frames, which is a major change, you should look at less extreme measures. Figure out what the actual hardware bottleneck is, then find what's hitting it and go optimize it. Odds are there's a solution that keeps everything in a single frame. You may need to cache something that is expensive, use object pooling, optimize a loop, convert some LINQ into loops, replace for with its parallel version, etc. Your solution should be the last resort to a serious problem, not the first to a problem that most don't experience.