Lakitu7's Tremulous 1.1 QVM 5.3 (with new crashbug fixes: update)

[Lakitu7]

Lakitu7's Tremulous 1.1 QVM Version 5.3
Dowload links:
http://patches.mercenariesguild.net/index.php?do=details&task_id=192

Well, pretty much everything in this release has been sitting in my SVN for several months, running in several places without issue, so I guess that's time to release. There are almost no new features in this release, but what I did do was merge all of the bugfixes from Tremulous SVN up to this point. The .patch is still based off of Trem SVN 966, but I have backported (in the proper use of the word, not the way that we usually abuse it) the useful bugfixes and added them.

I consider this release optional, as honestly nothing in here fixes any critical showstopping bugs, but the building in doors/on corpses thing is nice enough that it's probably worth doing anyway.

Upgrade instructions: Replace the game.qvm. That's it. No changes have been made to admin flags or cvars.

Items of note from the changelog (read it for proper attributions, since very few are written by me):

Building in doors / on corpses is back. To do this, I have reverted a few items in Trem 966 to their state in an earlier revision, which removes the code that broke these things. This fix breaks markdeconstruct, but since you shouldn't be using markdeconstruct with my QVM anyway since it has no corresponding cgame, that's not much of a loss. An alternate fix is in testing that puts a nasty band-aid fix on top of the nasty broken markdecon code instead of removing it, thus keeping markdecon and fixing that issue at the cost of questionable code. However, that code is hardly stable and they're still finding bugs in it, so for now I will continue to use this fix method and possibly switch later when all the kinks are ironed out.

A few glitchbuild situations are fixed: ie in some cases where building in a location causes the structure to drop to the floor when it finishes, the game will correctly prevent you from building there in the first place. No, all glitchbuilding is not fixed; just one small subset of them.

Switching to the next map will !restart instead of reload the map if the next map is the one you're currently playing.

The deadspec bug of occaisionally spawning without a weapon is fixed

The bsuit taunt/death bug is fixed

Hopefully the stage 4 / 0 spawns remaining bug is fixed

Admin prints are no longer decoloured in server console

No more getting stuck while evolving

No more PTRC bug

[Lava Croft]

And thank you for yet another fine release of the de facto standard Tremulous QVM!

[Lakitu7]

Since this release was a bugfix release, I intend to merge/create a few features in the coming dev cycle. Expect things in my SVN to be more in the testing phase than the stable phase once again (although I do at least make sure to partially test things before committing).

[Lakitu7]

At some point along the line I apparently reintroduced one of the crash bugs. Thanks Nightshade for reporting.

I have updated the precompiled 5.3 game.qvm with a fix, so redownload and update and you're good.

If you are using my SVN, the fix is also there as well, of course.

Either way, you should update to not be crashable.

I wasn't quite ready to release current SVN as 5.4 yet, since a few commits in there do not yet have sufficient testing.

[Snake]

can i have more info about that crash bug?

[Rocinante]

can i have more info about that crash bug?

Considering people who really should know better have been known to exploit bugs that were discussed in somewhat upstanding circles, my guess is that the answer to your question is "no."  Though it's also forum policy to not discuss exploitable bugs on the boards.

[rotacak]

But what if someone have another qvm with this bug? How he can fix it? For example I still know nothing about that previous "size" bug. I can only use new qvm and if I have some changes there, then I have to make all changes in new sources completely :-( For example my mod ambush - it using amines trembot what using older lakitu qvm. Probably includes "size" bug and this bug, but I can't fixt it, because know nothing about it. I can only copy trembot+ambush into new lakitu qvm and that is lot of work. And then maybe another bug appear and again this work... But if someone release bugfix, I can change one or two lines and it is fixed...

My opinion is this: is better know that bug or atleast know how to fix it. If you not discuss about it that not mean nobody use it.

[Rocinante]

Version control systems are designed to merge vendor changes with a local branch for just this reason.

[Lakitu7]

http://source.mercenariesguild.net/lakitu7-qvm/trunk/src/game/g_cmds.c?r1=91&r2=90&pathrev=91

All the info about how to fix it is available via, as Roci said, revision control.

[epsy]

then go fix non-existant bugs by blindly pulling/merging from another's branch <rolling eyes>

[Drakotsu]

Admin prints are no longer decoloured in server console

That bugfix isnt valid from what ive seen.
The |FA| server updated the QVM to your 5.3 but when using CP, the text is still decolored.

[Lakitu7]

Admin prints are no longer decoloured in server console

That bugfix isnt valid from what ive seen.
The |FA| server updated the QVM to your 5.3 but when using CP, the text is still decolored.

Those aren't the type of prints that refers to. That refers to when you go to the server console and use an admin command, things output by ADMP() are no longer declored unnecessarily.

Colors in !cp should work though. If not, that's new to me. I'll check it out.

[rotacak]

BTW, when I use commands in console, for example !time, why it show this:

!time: local time is 15:21:38
(S) UnnamedPlayer: !time

instead of this:

(S) UnnamedPlayer: !time
!time: local time is 15:21:38

It's confusing. And I remember that before (many versions before) was it ok. It should be like before, isn't? First should be displayed what I write and then server reply.

[Drakotsu]

Thanks lakitu,
If the !cp message is longer then one line and colored, the lines after it will not be colored.

Also,
As a suggestion
Could you please add the team variable to !pause, so we can !pause a/h
It would really help us with various things.

[Amanieu]

Could you please add the team variable to !pause, so we can !pause a/h
It would really help us with various things.

I believe this has already been discussed, and was decided to be too abusable.

[Lakitu7]

BTW, when I use commands in console, for example !time, why it show this:

!time: local time is 15:21:38
(S) UnnamedPlayer: !time

instead of this:

(S) UnnamedPlayer: !time
!time: local time is 15:21:38

It's confusing. And I remember that before (many versions before) was it ok. It should be like before, isn't? First should be displayed what I write and then server reply.

Confirmed. Looking at this code, this would have happened when g_adminSayFilter went in, and gone generally unnoticed since as far as I know, most servers use g_adminSayFilter 1. At the moment I can't think of a way to fix this without breaking things/ rewriting tons of stuff for a trivial issue/writing very ugly redundant code, but I'll keep thinking it over until I come up with something.

Thanks lakitu,
If the !cp message is longer then one line and colored, the lines after it will not be colored.

Ah, okay. I didn't realize that's what you meant. I've now fixed it in my SVN. Of course, it about doubled the length of the function, but that's string parse functions for ya'.

Also,
As a suggestion
Could you please add the team variable to !pause, so we can !pause a/h
It would really help us with various things.

No, I don't intend to add any type of pause that doesn't pause EVERYTHING together. I do have a hack on the way, provided it survives testing, that should fix the last remaining minor issues with the current implementation of pause, but I don't forsee adding new abusive functionality for minimal gain like that, no.

[Drakotsu]

Also lakitu,
Im pretty sure on a previous release you said callvote kick reasons were back.

If this is true,
Then im posting this to tell you that reasons dont work.
When you

Code: [Select]

/callvote kick player reasonIt sais invalid name
For example

Code: [Select]

/callvote kick newbie tkit would reply

Code: [Select]

Invalid Player

If this is false,
Sorry, ignore this post xD

[Lakitu7]

Read documentations please.

/callvote kick unnamed player -r this guy is deconning
/callvote draw -r this map sucks
/callvote poll lets' move the reactor -r before A gets s3

-r and text can be added to the end of any type of vote.

[Lakitu7]

------------------------------------------------------------------------
r95 | lakitu7 | 2008-08-31 22:53:51 -0700 (Sun, 31 Aug 2008) | 2 lines

* Ugly solution to commands being "said" after the text produced by their execution, when g_adminsayfilter is 0. I think a lot of people noticed this, myself included, but it took some poking from rotacak to remember to look into it. The "fix" is really ugly and I don't like it, but I can't think of anything better without sacrificing efficency for code prettyness + a pretty trivial issue, so I might as well just stfu and commit it rather than drawing it out forever before doinging so anyway.

[Drakotsu]

Also,
Lakitu,
In your QVM black names are disallowed.
But,
By double carroting, you can use black in your name.
EX:
SHIFT 6 SHIFT 6 8

Any way for you to fix that?

[Snake]

The black names are fine since i use a client that switch from black to gray

[Paradox]

The black names are fine since i use a client that switch from black to gray

Thats wonderful for you. What about the other people in the community who DONT use such a client. Or a new player in the game.

[Lakitu7]

Yeahhh, see I just don't really care about that one. Some kids have to have their little black names to stick it to the proverbial man, except it's not actually a big deal, so whatever. Submit the patch to Trem svn and see what they think. If they commit it, I will too. In the meantime, eh, whatever. 'beats having them grief. I already took away everything else that crowd can do, so 'might as well leave them something nobody cares about, eh?

[Hendrich]

Nice work, keep it up, everyone is loving your work Lakitu7.

[Lakitu7]

At some point along the line I apparently reintroduced one of the crash bugs. Thanks Nightshade for reporting.

I have updated the precompiled 5.3 game.qvm with a fix, so redownload and update and you're good.

If you are using my SVN, the fix is also there as well, of course.

Either way, you should update to not be crashable.

I wasn't quite ready to release current SVN as 5.4 yet, since a few commits in there do not yet have sufficient testing.

Pretty much this post again, but repeated for a new crashbug introduced by the fix for the last crashbug. The binary is updated again, and so is my svn if you're running bleeding-edge. I suggest updating either way.

As far as I know this one isn't really very widespread or well known and the trigger is unique/different from previous triggers, at least.

[Lakitu7]

Again. O_o

Of course, crashbug fixes are the only thing that don't get extensively tested because they're so timecritical, but sometimes it leads to things like this.

[daenyth]

So what's the latest version? 5.3.2? Can you make the thread title more clear? It would help people in staying up to date.

[Lakitu7]

I haven't really assigned it a number.

There have been 3 updates to 5.3. I suppose that you could call it 5.3.3.

[Aditya k]

why exactly cant I download the qvm from the link?