That´s a valid question. The same mechanism that checks for the original player model should be able to check for the new, improved one. I wouldn´t worry about this.

Ok, sounds good

most modern quake engines like fte and darkplaces and ALL netquake servers have sv_cullentities which restricts the appearance of all entities including the player model to the exact size of the bounding box of the server's models
so if u have the shub as a player model it will not even be seen by players unless 100% of the original bounding box size is in view.
this also works against wallhacks. msvd needs to break its all under the sun visibility if it wants to have a successful tournament style server.

This is the latest iteration of the new player.mdl.

How does one get it to work?

This is the error message you get, did some research to further elaborate:

======================
Host_Error: Mod_LoadAllSkins: Player skin too large
======================

Obviously there is a tweak that needs to be made, so I´m simply asking for somebody to make it as I lack the know how.

Yes thats true, that can be done on server side (proper side to limit things).

Hooraytio: All you can do is make it harder for people that can't compile their own binary (client). Anything checked/controlled on client-side is easy to circumvent and will never be any kind of protection (just a false sense of safety).

But as I said before, usually works for most people with honest intentions

Cara, I got the player model to load... I copied it to qw/progs and launched the client, but when trying to connect to a server I got the same error as you:

======================
Host_Error: Mod_LoadAllSkins: Player skin too large
======================

Searching the EZQ source for this error, I found it in gl_model.c:


Looks like the error is thrown because the size of the model is larger than "player_8bit_texels". That variable is defined earlier in the same file:


All I did is double the size of that variable:


recompile, and presto! The model loads when connecting to a server.

WARNING!!! I know nothing about the EZQ code and have no idea what the above change does other than let the new player.mdl load. Of course, you do trigger the "modified player" warning when joining a server.

There is, however, a problem. The model loads fine but it looks a bit off. First two with enemyskin "" and last two with enemyskin "2white":







I'm not sure if this strangeness is because the skins need to be updated to cover the rest of the model, or because of some other client and/or server change that is required. The easiest thing to test first might be to create a new skin that matches the new dimensions/layout (assuming they are different)?

I can send you the ezquake client that I compiled for this test, but I only have a linux version. Someone who knows how to compile EZQ for windows can make the change in 5 seconds.

Cheers,
BLooD_DoG

P.S. "player_8bit_texels" is also defined in gl_rmisc.c. I did try doubling the size of the variable there too, but it didn't seem to make any difference.

P.P.S. Special thanks to Giant and Ivan for posing for my screenshots. Also thanks to Matab for photobombing the first screenshot.

(Edited 2013-08-19, 06:43)

Ok so problem solved! When I first skimmed over the original thread, post #4 said the new model works with the original textures and high-res replacements. Somewhere in his development of the model, the author decided to take a different route.

[Edit] I should have read post #7 of this thread (not the original thread), it would have saved me some time and guesswork. SputnikUtah already explained that the old skins won't work with the latest version of this model.

The zip in the original post includes a PlayerUV.png file that can be used as a base for new textures. Using this texture, the new model looks just fine!




What you can't tell from the screenshots is that the animations (firing, etc...) are smoother than the ones of the original player model.

Someone with artistic talent either needs to paint that texture template to create new usable textures, or look over the 38-page original thread to see if someone else has already done that.

Also, I want to re-iterate that my "multiply the variable's size by 2" solution is not based on any science. It was a guess that got the model to load, and I can't guarantee that there aren't any unintended side-effects. At the very least, "320 * 200 * 2" should be replaced with the proper dimensions.

Finally, someone still needs to compile a windows version of ezquake with this modification. Finally finally, you can go back to petitioning for a new ruleset that would allow this new model

Love,
BLooD_DoG

Well, I was being productive so I decided to setup the Windows development environment for Ezquake (wasn't too hard given the instructions in the repo, just make sure you use Visual Studio 2010 and not 2012, that cost me some unnecessary troubleshooting time).

Try this build of ezquake. It is the latest official source + my minor modification. Works for me with the new model, just remember to also use the PlayerUV.png skin that is in the zip file in the original post.

-BD

Thanks BLooD_DoG, but I have a problem with your build: althoughI can now load a demo with the new player.mdl in qw/progs, it's still the old one that shows in game...
I started to make a skin from the playerUV.png but I can't test it because of that. Maybe you can try it.

Hmm, don't know why, maybe you have another player.mdl in some .pak or .pk3 file that is overriding it? Regarding your skin, it looks good!



Just for fun, this is your skin on the old player model:

Ok it works when playing a bot, but not on demos, maybe because the model is part of the informations recorded in the demo itself...

Great work BlooD_DoG, didn´t know you were such a haxxor!

So now I guess what´s left is:

* Make skins (most people use fullbright one or two-colored skins, so this isn´t really a big deal)
* Make the client check for this specific player model (or the old one, if people still prefer it) when doing a ruleset check. Or best case, server side check.
* Make the client load the old player model when playing a demo that has the value: new_player_model: 0 (arbitrary line and value, I know jack shit about coding and just wanted to make my point come across)

Besides, is it really necessary to edit something on the client to make the model work? The first iteration of the model that was posted further up in this thread was pretty much plug and play. The 24-bit textured skins looked very nice on it aswell (maybe not perfectionist-perfect though).

It´s great that more people start taking this implementation more seriously, for me, it´s a nobrainer with all to gain and nothing to lose. One day in the not-so-distant future this player model will be plug-and-play and standard in nQuake. I won´t stop nagging until it is (Pokes Empezar, dimman etc)

It already loads the old player model on a demo, that's the problem

Ok I made a few changes, so here are a "faithful" HD skin and a green fullbright one.
They seem to work rather well.

Yea I know, but I mean having them both possible to load in the client... It´s not my area so lets just say: "Fix the demo issue." then.

Looks like it, because the first iteration of the new player model was a certain size, and this last iteration is a new size that is too large for what ezq is expecting. I'm not saying the new model looks bigger or is unfair, it actually looks the same size to me. I think the difference is in detail and/or animation complexity, i.e. a larger file size. Besides, a client change would be necessary even if you just want to pass f_modified.

Anyway, I went ahead and made an additional modification to ezq so that it reports "All models OK" for either the original player.mdl or this new one. You can find the build here.

You will still trigger the "modified player/eyes" warning because that comes from a server-side check. I also went ahead and updated mvdsv to take care of this, build available here.

I'll reiterate again that I have no idea what I'm doing I figured out what works for both ezq and mvdsv with some frustrating trial and error. mvdsv is hard-coded to check for a single player.mdl file, so I had to add some logic to also check for newplayer.mdl and accept either one (on the client, you should still use "player.mdl", not "newplayer.mdl" ). There are some other places in the mvdsv code that specifically mention "player.mdl" for pre-caching or network traffic optimization that I did not touch. The KTX code also is hard-coded to "player.mdl" in some places, and I didn't touch those either. No idea if additional changes to these sections should be made.

Happy to share the ezq and mvdsv code changes with someone experienced so they can review and commit the changes to the official repositories.

I guess what's left is:

* Get someone to review my changes, and determine if additional changes are necessary.
* Test a lot.
* Convince every server admin to update (good luck!) if you don't want to trigger the "modified player/eyes" warning.
* Figure out the demo issue
* Make more skins! Jisse, could I request a fullbright red and a fullbright white skin?!

Cheers,
BD

(Edited 2013-08-20, 10:07)

It will most likely be allowed in EQL whenever it is fully implemented and everything works like it should.

Yep, I'll just make a few color variation, and maybe two color ones if I have the time.
Another thing we have to test is what happens when you get the ring, hopefully there won't be any problem with the eyes...

I've been spending the whole spring and summer building on our apartment, and we just recently moved from our old one to this new one. I will get more time the closer to winter we're coming. I will look into this and fix it properly.

Blood_Dog: There is no developer left on the mvdsv/ktx projects, I have forked them on github here. I've added a patch to KTX to make it support updating gameclock instantly as spectator or when rejoining a game. It currently needs latest ezQuake and a server that supports it (pangela servers does).

Just to clarify: The player.mdl check is not a server side check in the sense that it would provide any more "security". I haven't looked into details but it is still the client sitting on the information (player.mdl) and is absolutely most likely just sending a hashed value of the player.mdl to the server which the server then decides if it is okay or not. It is then just as easy to find out which hash value it expects, hardcode the value to send in the client and then freely use whatever model you want.

I think the model itself needs to be remade a littlebit to fit into the size limits. Blood_Dog: Perhaps you could ask Spike (Spoike) about it, I don't have time to look it up for a while yet.

Amazing work Blood_dog, even for a rookie coder to show such interest

Hooraytio, good news. Hopefully it will be "safe" to use it as soon as possible.

dimman, we´re waiting eagerly for parts of shedule to clear up!

I doubt the eyes will be affected as I haven't touched them at all (famous last words for any bug fix or feature add). Regardless, it should be a very easy thing to test.

Other than general play testing, I think the following precision test is critical for ensuring fairness:

3 players required:

* Player 1 will be the in-game observer. He will have the modified player.mdl
* Player 2 will be a spectator observing Player 1. He will have the original player.mdl, and will be speccing through the view of Player 1. Essentially, Player 1 and Player 2 would normally see the exact same thing (given the same fov, etc...), the only difference being the player.mdl
* Player 3 is an in-game player running around. No need to have the modified player.mdl

Test::

Player 3 hides behind columns and other objects so that Player 1 can "just barely" see Player 3. Maybe just 1 pixel of the tip of the gun, or the top of the head, or something like that. Player 2 should also "just barely" see the exact same thing. If Player 1 or Player 2 at any time have a different view (only one of them notices Player 3), then that is unfair. The reason for this test is the models could have little differences in animation and layout, and we don't want any advantage or disadvantage due to using one or the other. The test should be repeated for a variety of positions / orientations, shooting vs non-shooting, etc...


I'm not really an animator / modeler so I'm probably not the right person to pursue this Someone should probably look through the original thread to find out when the author decided to go "outside the limits" and see if he explained why that was necessary. Did the other nq/qw clients need any updating?

There was an updated model, that he also mapped the skin. Yet broke compatibility,.,,,, grrrrr

unfortunately, the author is (as we say in the quake universe, gone)...afk.

http://www.quakeone.com/qrack/player.mdl
has the original model. conforms to original skin, yes! works with primevils skins
i can dig up the original blend files that has the original map skin.


bloood dog thaat skin looks like someone's mom stitched your torn porno mag....


no offenses but might as well have solid colored skins..

I do use solid red (team) and white (enemy) skins! The first few screenshots I posted were from before I realized that the new model required updated skins. They show what the base skin looks like on the new model, hence why it looks all messed up.

So I found out that in the original code, ezq expects 320x200 = 64000 bytes for the skin:


My original fix increased this to 320 * 200 * 2 as a simple hack, but I found out that the exact value that works with the new player.mdl is 65536 (aka 2^16, or 16 bits). The line of code should be changed to:


and that's really all it takes to get the new player.mdl to load in ezq. Posts #199-201 of the original thread (see pages 20-21) explain that the new model fixed some skin stretching/uglyness, which is why the above code change is necessary and also why the old skins don't work well. They also explain how to easily "port" the old skins to the new layout using blender. SputnikUtah, that "older" new player.mdl was a work in progress and didn't include everyone's feedback. You can use it in official ezquake builds and with existing skins, but you'll still fail f_modified and so on. If you want to pass those checks, you'll need a new client build anyway, at which point it makes sense to just use the "final" player.mdl instead of the work in progress version.

Progress summary:
* New player model (courtesy of capnbubs) available here (or here for full pak with extra files)
* (Required) New skins (courtesy of Jisse): faithfull HD and green fullbright
* New ezquake available here (supports new player.mdl + passes f_modified)
* New mvdsv available here (does not trigger "modified player/eyes" warning specifically for the original player.mdl and this new one)

Todo (not me!):
* Get someone to review my changes, and determine if additional changes are necessary.
* Test (see my post #51 above).
* Convince every server admin to update mvdsv (good luck!) if you don't want to trigger the "modified player/eyes" warning.
* Figure out the demo issue (how to display new player.mdl on old demos?)
* Make more skins!

Ok more good news, I figured out how to get demos to use the new model! Just remove/rename qw/progs/vwplayer.mdl and you're good to go! You can copy the new player.mdl to vwplayer.mdl if you like, though it is not necessary. Without looking into the details, I guess demos load vwplayer.mdl if it is available, and fall back to player.mdl if it is not.

I think I'm done playing with this, I can't really contribute to any of the remaining tasks anyway (other than testing on a server with others)

-BD

<3 BD

Thanks for shedding some light on the situation, Sputnik!

Minor update: By removing vwplayer.mdl, demos will use the updated player.mdl model instead, but you lose "vwep" functionality. That means you won't see which weapon the player is holding. I saw on page 16 of the thread that this topic came up, and the model author said he could create a vwep model relatively easily, but as Sputnik mentioned he has gone AFK.

Could you make a mvdsv for Windows too? That way I can include it in nQuakesv for Windows.

Haven't tested it but try this.

Also, since you're resuming work on nquakesv, I'd love to double check all the CTF settings Not that anybody still plays CTF, but it deserves some attention for nostalgia purposes!

This sounds so awesome and promising, I haven't yet tested (waiting for things to finalize), but what I wanted to add is: isn't _this_ enough news to be shown on start page of qw.nu? Most recent news is from 9 Jun 2013. I have privileges to do it, but dunno if/how to put it