WIP: SaberMod

Discussions about modding, questions, mod requests or just show off what you're working on.
Post Reply
User avatar
fau
Staff
Posts: 433
Joined: 16 Aug 2015, 01:01
Location: Warsaw / Poland
Contact:

WIP: SaberMod

Post by fau »

SaberMod Alpha is out, it has it's own topic, mainly for players/server admins. There are few things I'd like to share and discuss with modding comunity so let me publish a micro development blog here.

As you read before, I wanted for changes I make to be reusable by others as easily as possible. This didn't quite work out as I expected, but at least I keep commits that don't change default behaviour (or change it only a tiny bity) in jk2sdk-gpl repo. You can find there few bugfixes, refactoring commits and code quality improvements, Hopefuly some of them will go to mvsdk eventually.

Next comes a list of commits that aren't quite vanilla enough for jk2sdk-gpl, but may be interesting to all modders around (and free to use as long as you GPL your mod)
  • Perl script fixing indentation in q3 script assets: Anyone who edited .menu files or other scripts parsed by q3's GenericParser know what a whitespace mess they are. This ends now. It will print fixed version to stdout, you can run it as `perl -i q3scriptindent.pl <path to file>` for in-place transofmation. Fun fact: not a single backspace was used while writing this script.
  • Follow targeted player: Someone posted reverse cycle on +use as a mandatory spectator improvement, I would like to add this to the list. (whoops, I should increase 256 to something greater in VectorMA there)
  • Sort clients with stable sorting algorithm: I'm very happy with this one. It fixes multiple inconsistencies across the whole game, by giving you a meaningful fallback for order of tied players. One example and a reason why I changed it was that when I implemented "follow current score leader" feature, it would jump wildly whenever a player with lower client number got tied with current leader. Now it doesn't change unless someone actually overtakes the leader.
  • Dumb shuffle: This is the best dumb (using only score) player shuffle algorithm I stumbled upon. Try few variants on paper to see why.
There are few more interesting improvements which are not complete yet so I'm not posting them for now.

There is also one open problem requiring knowledge of ghoul2/animations code, which I really don't have time and will to learn right now as there are so many more important areas from my perspective. If anyone having experience with this wants to give it a try, I'll be very thankful :-)

Problem description:
In Red Rover gametype (see branch redrover) player switches his team on respawn (I don't really care if it's on respawn, when he dies or in the middle). At the same frame, new body is created via CopyBodyToQue and EV_BODY_QUEUE_COPY. In cgame this copies player's model to a new ghoul instance. The problem is that it uses clientinfo from the same frame, which has already been changed to account for team change, so newly spawned corpse changes it's color.

I recall I tried few solutions to this in December. I believe the cleanest one is to move CopyBodyToQue to player_die and make player body invisible until he respawns, however this poses a few challenges: (a) Make death animation/physics continue smoothly (b) make dismemberment work correctly (c) make camera follow new corpse (try running off the cliff and press kill in the last moment, sometimes player's dead body falls off, while copied corpse stays up).
(c) is not a big deal and I can pass over that. If it requires cgame modification, it's fine too. Note that delaying sending new clientinfo just slightly won't make it, as we have no guarantee that few consecutive snapshots won't get "merged".
Post Reply
Created by Matti from StylesFactory.pl and Warlords of Draenor (modified by jk2.info)
Powered by phpBB® Forum Software © phpBB Limited