It was brought to my attention that recent MVDSV versions write MVD files which are incompatible with some clients and which are excessively big as a result of this.

I wrote a small demo fixer which also with my test files makes the file 2.8% smaller!

Source code
MorphOS binary
Win32 binary

Type 'gcc -O2 mvdsv-fixer.c -o mvdsv-fixer' to compile the source code.

Hey bigfoot. MVDSV tend to break demo recording occasionally in its history. But before you bash could you take a look at these demos: http://dybbuk.de/fixmeplz.zip ? :-) They seem to have a problem being played back. Those demos were recorded around November 2004. I think it was a known issue with MVDSV at that time but no tool for fixing those demos were provided Do you think there is any chance I/you/we can repair theses?

It's not some hot super demo - We actually lost that match - but I really would like to get them fixed for the sake of completeness of my unsuccessful qw career :-)

useful tool for some but a) being a native english speaker i'm not sure i would consider 'excessively big' == '2.8%' :-) and b) the .MVD format has (afaik) been extended to provide support for saving stats, maintained clients should be updated to stay in sync whilst legacy clients can make use of the tool you provide

I guess you're talking about MVDSV 0.176, which there's a patch for here?

I did look into fixing the demos back when that happened, but the trashing done to the file due to this bug was a bit more complex than I wanted to waste time on, so I didn't write a demo fixer for it - sorry.

Being a native English speaker, you quite obviously missed the joke with the excessive marketing of the bloat removal feature


Yes, I realise that you guys just looooove breaking everything for any good or bad reason, and here it seems you're trying to defend a bug with a bad reason.

Take a look at the source code, I believe you do have at least some C knowledge, so you will see that all this thing does is _strip out empty packets_. Yes, that's it. It removes empty packets. It has got nothing to do with stats. Fuhquake fails on this file only because it tries to read 0 bytes from the file and treats the return value as an error.

Here's the workaround for making the files play in Fuhquake:

any hints and/or advise what must be done to fix such demos?

i've not done any real work on mvdsv for ages or even ever really

but as i've said on several occasions, if you have found a genuine bug then submit a bug report rather than posting derogatory posts with workarounds - it seems unfair to vilify developers for breaking compatibility through mistakes arising during the course of development, fair enough posting your workaround for fuhquake users that still exist (though you should have posted the patch for fuhquake at the same time) but no need to postfix it with your usual flame

I have seen several players already being grateful for this workaround being done for them. How you can even criticize him for spending his time for doing this is beyond my understanding.

I don't think you'll get away with anything less than trying to analyse the source code and figure out exactly what trashing of the demo data occurs, and then hoping that it didn't trash any important data.

As far as I remember, I tried manually going through a sample file and fixing up as many problems as I could find, and I got the demo to play for a few seconds... But...

:roll:

i clearly stated that i understood the usefulness of posting such a workaround.

i merely criticized the continued tone that is prevalent throughout both his and your comments, seemingly feeling that your posts aren't complete unless some criticism of mvdsv / ezquake / ktx developers is included

i also criticized the fact that despite numerous requests to use the proper way of submitting bug reports when problems are found, he continues to ignore this

As I've replied on several occasions, I *have* tried giving bugreports to the MVDSV guys *several* times, and none of the times with a positive result.

About 'derogatory posts', well I can just assume that truth hurts?


Please, as the developer in here who undoubtably receives the most abuse, I don't think you're in any position to teach me about what is fair and what is not.


Why? The bug is in MVDSV, not in Fuhquake. The patch is simply there to show to *YOU* why your comment made as little sense as they often do.

And you. You should have spent 10 seconds researching what you were talking about before spouting the usual 'who cares about compatibility? Just use the latest breakage'-nonsense.

That would explain your previous flaming when Molgrum posted facts about the fact that FTE is not able to run current KTX because the mvdsv interface was changed yet again.


bigfoot was not the one to find the bug. Even if he reported the bug directly to the mvdsv team then these demos would not be magically fixed. They would remain forever broken.


The 'extensions' causing the issue here are packets with no data size which were added to keep qtv in sync when there is nothing going on on an empty server, so it stays 10 seconds ahead, instead of having buffering issues.

Interesting note: If you strip out these empty packets then you discover that all timing is gone too. Yes, these empty packets are the only ones that now carry any sort of timing information. This is a waste of space, and destroys much of highlander's work on compressing the format a bit. It just shows mvdsv's lack of thought, care, and testing.
Yes. Lets make demos bigger simply because we can't be bothered to use the correct conditions. That sounds like an ideal plan. And lets flame them and accuse them of being counter productive instead of fixing the bugs when they provide a useful tool that actually fixes the problem in already existing demos. That's a perfect way to maintain software.
And yes, I'm also being sarcastic, but you'd have realised that, considering you're a native english speaker and all.

Ok, if you're a developer and can't take a little heat about issues that's affecting a whole lot of players, you should perhaps reconcider your position? Obviously the improper way for a developer to behave is by whining to a guy for doing a fix for those demos that are already broken (they will not be fixed retroactively whenever mvdsv gets fixed, sorry).
Take it like a man, go tell the mvdsv-crew to fix the bug and thank bigfoot for doing the workaround.

irc != place for bug reporting, 'isthisinuse' SF account shows no bug reports in mvdsv SF tracker


did you ever receive any abuse for developing fodffa? or when you posted about running quake on motorola phones? no, as far as i have seen you only ever received negative comments in response to negative comments you yourself had given


*shrug* makes sense to me that client shouldn't fail due to empty packets so providing a patch for fuhquake / zquake / fte etc. that stops this problem is good to me


the sooner it was posted in bug tracker, the more time could have been spent looking at the issue to fix it before next mvdsv release is made and the more exposure it would receive from the correct people.


so they were added as a slightly dodgy way to fix a problem? not entirely useless as originally suggested anyway...

You know this isn't IRC, right?...

K, just checking.

i am not a mvdsv developer and i do not speak for them, i merely think it is unfair that you continuously choose to publically criticise a development team when they may well be unaware of a particular issue because you stubbornly refuse to report it through the proper channels


at no point did i complain about the fix being posted for old demos to be processed with - please stop returning to that - it is obvious though that the sooner the problem is looked at in mvdsv then the fewer demos will be floating around that won't play in fuhquake

the assumption was that bigfoot's 'I *have* tried giving bugreports to the MVDSV guys *several* times' were conducted on irc as i've not seen them on this forum or any project mailing list

You guys must really love developing, else i wouldn't know what keeps these development teams together

Every thread seems to be in a flaming tone hehe

No. They're *entirly* pointless in the media in which they are present. Utterly utterly useless. They are a mechanism to keep the timing going when there is no data. In this case, there is data. There's lots of it. And the data that there is that should have all the timing information has no timing information and these additional empty packets are there instead wasting 2.8% of the file size. It would be proportionally more in a duel.
They are meant to only be sent by the server when the server is idle. They are only meant to be present in qtv streams. And never when written to an mvd on the disk - there is no point in doing so. You cause the client to just sit there playing the game from an empty server with absolutly nothing going on. Their presence in an mvd _file_ is pointless and wasteful.


Please do some research next time, _before_ accusing people of unjustified flame.
Without posting such a tool, I expect the mvdsv people would do exactly as you have done and compleatly disregard the bug, saying exactly as you 'update your client'. This is a clear mvdsv bug, and you try to pin the blame only on older clients.

Maybe you're right, we should probably fix the clients to print the message 'this demo contains utterly useless packets' when it receives such an empty packet. That sounds like an ideal solution.

Anyway, in what way were they extended to provide support for saving stats? How do you expect other engines to maintain support if you never tell anyone when things change? Its like the KTX API all over again.

You said you _were_ a developer though, right? I suppose that you haven't left MVDSV because you became worst pals with the team, so there is nothing that hinders you to simply forward this bug report to the team. However I'm pretty certain that the bug has already been reported by Renzo before this post was created.
BTW what is wrong with using IRC instead of the sourceforge tracker? It's not like the #mvdsv channel is hyperflooded with people talking all the time, and i frequently see developers being there (VVD, deurk, Tonik).


Yeah I got that you complained about bigfoot being too factual about this, you are simply religious about MVDSV being totally bestest and every factual poke at it seems to hurt you alot. It is a very simple issue to deal with: 1. Accept that MVDSV has flaws. 2. Accept that publicly known flaws is less likely to leave users clueless. 3. Unless you have something to say about the particular bug or workaround, don't post here. 4. You still haven't thanked bigfoot for the workaround.

Waiting for a _real_ MVDSV developer to comment here.

YAWN...

Geez. What a nice reading before going to bed.
Nice flamewars going on there but did anybody care to ask qqshka if he actually finished the rewriting of MVD handling?
For the record I think he wasn't yet done...

Maybe you should before going on with rhetoric discussions. There are obviously some old tensions thrown in every topic about mvdsv/ktx.

Oh and by the way: please stop getting latest commits in the minute they are out just to start thread like that Molgrum, after all, all of the complains you have are NOT present in the latest... what's the word again?... oh yeah STABLE version. SVN is NOT a freaking stable version unless we release a revision labelled STABLE.

I'm ok with you not liking some people (and please stop talking about VVD like an active developper of mvdsv), not liking they way we handle coding, releasing and all but why do you even care? You should be more than happy to see MVDsv breaking things because then you can promote your FTEqwsv!

Anyway, kinda pointless as usual, so I'm mostly skipping all of that since I am not interested in old stuff I wasn't part of... If you want to contribute to fixing the developments, feel free to do so, I've always been ready to work with you, if not, well please just use trackers or other means to report bugs, even this forum, but without using the common "they did it again those morons I had to fix it" type of sentences, as respect towards people you don't even know, ie ME at least. And I (and not Tonik or qqshka or VVD) accept bug reports on IRC as well and will follow most of them as long as you highlight ME and talk in #mvdsv or #ktx depending on which one your rant is about.


PS: Not a native speaker, if something is unclear ask for clarification.

Molgrum, the only real dev of MVDsv nowadays is qqshka.
I am not because MVDsv's code is a MESS, is not CLEAN, and is BUGGY, which doesn't mean the whole is a total crap, far from it.

It means that it needs a lot of effort and TIME to make it better and all good will persons WILLING to help are welcomed on board, as it has been said over and over since I lead the project.

I will never stop getting the latest commits nor will I never stop using them on all the servers I'm administering.

The more servers they are running on, the more people are playing there. The more people playing there the higher possibility to find bugs and to get someone actually tell me about it. The more they whine, the more I whine to MVDSV guys.

Perhaps they fix things then, or perhaps they ignore me. Who knows (hi deurk, qqshka, should I commit something? ;( )

You are free to tell qqshka about the bug deurk.


How would that fix the broken demos already out there?


It was not my server, what is this "the topic for guessing facts" or something? It is not my thread either, please deurk get the facts straight. Are you saying that the stable version of MVDSV is what you're promoting? I beg to concur: http://www.quakeworld.nu/forum/viewtopic.php?id=2392
Also, you can see that I clearly posted AGAINST using the SVN version on public servers. All of your arguments are simply and clearly wrong here deurk.


Why should I be happy that the commonly used server is breaking things? Are you doing it on purpose so that people should whine on you to get it right? No I am not discussing here to promote FTEQWSV, I do it to highlight flaws in MVDSV so they get fixed sooner. A server should not be promoted with the argument "at least it doesn't break demos like MVDSV does, get it now!".
Ok no problem, I will only call qqshka the developer for MVDSV hereafter.


Dunno who you're refering to here, but if it's me then no I'm not interested in working on either KTX or MVDSV, and I will not say why here (you should already know why deurk, it is nothing personal, it is a fundamental design flaw, I'm sorry).
The forum seems to work good to announce bugs in, I like to think of it as speeding up the fixing process, and since you're obviously reading here I see no problem. I will actually use it from now on

And still, none of the developers has thanked bigfoot for doing the workaround. I notice a pattern...

Molgrum, quick replies:

1) qq knows he broke something doing the rewrite, my guess is that work delayed his study of what he would do about it since he has not been online for several days
2) I don't care about the broken demos out there because 3)
3) oops, not your thread indeed, though it could easily be... I just say: SVN is not a stable release until I tag one as such. That is a fact. You are right in a way to promote against SVN built servers, although Renzo's point about why he is doing it is clearly more interesting to us developers.
4) I'll tell you when I feel myself confortable enough with MVDsv to be called dev for it
5) I am refering to anybody with knowledge about C, QC, or anything that is used for that project (QW knowledge, web design, 3D modeling, texture making and more...). I understand you don't want to participate for your reasons, and I understood bigfoot had his. I'm fine with that.

I will say again: if you (you being everyone) find bugs, I am interested, talk to ME about them, any way you want, instead of coming here and post about a temporary situation on a development code not flagged as stable. At least if you do, use the MVDSV thread which is pinned for people to request features, report bugs or ask information about it.

As for the fix, why should I thank for a fix that doesn't concern my project nor the client I am using? It is nice that people concerned have a fix, I'd be more interested in a fix for MVDsv that takes into account the problematics around the recent change of code.

And Renzo, yes you do get bug reports and you do relay them and yes, you harass us with some issues and YES you are right to do so.
(I am NOT saying everybody should be as painful as Renzo can be )

Thank you bigfoot for making this MVD fixer program. Not because I have problems watching demos in fuhquake or something, but because your code inspired me to add some new demo code to ezquake. Didn't have a clean view how MVDs worked before, your code helped Found it funny you didn't mention what the bug was in your initial post though

Regarding the bug in mvdsv, it's obviously that, a bug, there is no usefullness to have empty packets in demos, so it was not added to screw people over.

Not even for eztv?

I should've written "demos saved on disk"... Yes for QTV stuff it's usefull.