Create an account


Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
ice

#1
[Image: 1Z6n6cRi29M2GGafLxwmEh]

I was making an ice shader ... and I added surfaceparm slick ... but it didn't seem to work

Code:
textures/hty0005x/terrain-hty0005x-ice-0001
{
    qer_editorimage textures/hty0005x/terrain/hty0005x-ice-0001.tga
    surfaceparm slick
    dpoffsetmapping - 0.5 match8 119
    q3map_bounceScale 1.25
    dpglossintensitymod  3
    dpglossexponentmod  4
    {
        map textures/hty0005x/terrain/hty0005x-ice-0001.tga
                
    }
    {
        map $lightmap
        rgbGen identity
        tcGen lightmap
        blendfunc filter
    }
}

does xonotic support slick shaders?

If I cant use surfaceparm slick ... is there any entity that will give a slippery effect?
Reply

#2
There does not seem to be any support in my git checkout from twenty days ago. Friction on the ground is always the same.

All Q3SURFACEFLAG_SLICK surfaces are used for is bouncing port-o-launch projectiles.
Reply

#3
Hmm there is slick surfaces in CTS?
Reply

#4
I know only slick maps which have different settings loaded on the server for that particular map. I don't think there are slick surfaces.
"Yes, there was a spambot some time ago on these forums." - aa
Reply

#5
Is it possible to get slick surfaces support?
[Image: 542.png]

#deathmatchers @ irc.quakenet.org

Reply

#6
[Image: 4LHtsUrRmBM9O9elMyBAKg]

....
I sure hope so ....
I cant seem to find any combination of tigger_push, trigger_impulse, trigger_conveyor, or trigger_gravity ... that will get a friction-less effect ...

although the bouncing porto launch thing works fine ...
Reply

#7
You could try to cheat that effect by creating a slim brush of water (caulk_water) above the surface you want to be slippery.
Reply

#8
hutty Wrote:Slick surface support is desired, I would like slick surfaces. Ice and such. Capital, Grand.

I'm guessing change the friction if you trace downwards and find the slick q3 attribute. There is code to do that with sounds. It could take about 10 min maybe to implement this change and another 1 min to add a cvar to set what the friction should be multiplied by (0.2 say) for slick stuff.

However that way would be changing the friction each tic, must be a better way.

How about a compromise between all of us who want to see monsters in git and you who want this, what is the word, "slick" surface param to work: get mario to finish up monsters and get it committed to git, and we will... discuss... each of us... about looking into this problem?

Honestly, why would you want a "slick" surface? Sounds alittle to... adult... for xonotic. As you said before I think, xonotic does not support that level of adult content. It's a kids game! (Kids are defined by their existance as disembodies souls who, depending on the culture, are only granted a shell forwhich their ghost to operate once they reach their 16th year on this earth)

In server/sv_main.qc there is code that traces down to check surface param for metal step sound:
A similar thing could be done for friction perhaps

Code:
if((time > self.nextstep) || (time < (self.nextstep - 10.0)))
                {
                    self.nextstep = time + 0.3 + random() * 0.1;
                    trace_dphitq3surfaceflags = 0;
                    tracebox(self.origin, self.mins, self.maxs, self.origin - '0 0 1', MOVE_NOMONSTERS, self);
                    /*
                    if(trace_fraction == 1)
                        dprint("nohit\n");
                    else
                        dprint(ftos(trace_dphitq3surfaceflags), "\n");
                    */
                    if not(trace_dphitq3surfaceflags & Q3SURFACEFLAG_NOSTEPS)
                    {
                        if(trace_dphitq3surfaceflags & Q3SURFACEFLAG_METALSTEPS)
                            GlobalSound(globalsound_metalstep, CH_PLAYER, VOICETYPE_PLAYERSOUND);
                        else
                            GlobalSound(globalsound_step, CH_PLAYER, VOICETYPE_PLAYERSOUND);
                    }
                }

Friction is used alot in the code and we would want to do this efficently and not have code duplication, I think a better mind should perhaps look at this.
server/
movelib.qc
cl_physics.qc
g_subs.qc
cl_client.qc

All deal with friction.

kojn translates to horse
Reply

#9
HellYeah is mostly right, although I don't believe this needs more editing than just in cl_physics.qc, wherever autocvar_sv_friction_on_land is read. Add a code branch there determining whether or not the surfaceflags include slick, and adjust the used value accordingly.

Although I can't be sure it will work well with prediction. I can't seem to find anything that uses cl_movement_friction_on_land though, so maybe it isn't subject to prediction???
Reply

#10
Maybe:
Code:
if(self.lastground < time - 0.3) {
  trace_dphitq3surfaceflags = 0;
                    tracebox(self.origin, self.mins, self.maxs, self.origin - '0 0 1', MOVE_NOMONSTERS, self);
if(trace_dphitq3surfaceflags & Q3SURFACEFLAG_SLICK)
                self.velocity = self.velocity * (1 - autocvar_sv_friction_on_slick);
else
self.velocity = self.velocity * (1 - autocvar_sv_friction_on_land);
}

And similar for the
if(self.lastground < time - 0.3)
{
self.velocity_x *= (1 - autocvar_sv_friction_on_land);
self.velocity_y *= (1 - autocvar_sv_friction_on_land);
}

stuff

I don't know if trace_dphitq3surfaceflags = 0; should be there. I'm guessing it should because it clears that out before the new trace we make

No, that doesn't work, it's only for friction when landing.

I think here is the place:
if(f > 0)
{
if (f < autocvar_sv_stopspeed)
f = 1 - frametime * (autocvar_sv_stopspeed / f) * autocvar_sv_friction;
else
f = 1 - frametime * autocvar_sv_friction;
if (f > 0)
self.velocity = self.velocity * f;
else
self.velocity = '0 0 0';

waiting for compile.....
waiting and waiting

Ok looks like this works, posting file

http://ompldr.org/vZ2FpcQ/cl_physics.qc

Make sure to add to autocvars.qc :
float autocvar_sv_friction_slick;

(I suggest under float autocvar_sv_frictionWink
And in some config:
set sv_friction_slick 0.1

The diff:
http://ompldr.org/vZ2Fpdw/cl_physics.diff

Some concerns: is tracebox(self.origin, self.mins, self.maxs, self.origin - '0 0 1', MOVE_NOMONSTERS, self);
the correct trace? Why MOVE_NOMONSTERS? does that mean don't hit into monsters? or abandon the trace if ... Should that be changed to something else? Monsters should be affected by slick too.

I used that trace because it works for other things.
Reply

#11
[Image: 1Z6n6cRi29M2GGafLxwmEh]

Quote:get mario to finish up monsters and get it committed to git,
Actually ... he might be waiting for me to finish some maps for him ....

--------------

anyways ... wait ... did you just get it working? .... right now ? .... that was quick ...

thanks

[Image: 3RR4Gk75TBzRbQ1C1ara17]

is there a way to upload this to my server? (without using git or autobuild ... im stuck with 0.6 (hypernia hosting ...)) ...
or should I just shelve the ice map till 0.7 ...
Reply

#12
Yes it works, I tested it, committed to my branch.

If someone could compile for you some new csprogs and progs files after inserting this file they could give you those.
You probably don't want my csprogs and progs file as I'm working on a mod that adds alot other code.

I'd like monsters. Also I'd like some engine additions having to do with deforming models and cleaving them in twain so I can add an axe to my mod and not have it be a simple bludgeon nor something that magically explodes the other player into a mound of bloody gibs. The Lord of all Nexuiz and the secret overlord of Xonotic says that cleaving a model via a plane is the easiest thing to do in the engine, but he himself is not interested in coding modeldeform.c for darkplaces. If there were someone else who could breathe life into darkplaces/modeldeforms.c (notice it doesn't exist and even if it did currently it would be empty) I would be grateful, as, I imagine, others would, in time, be.

Quote:It NO Werky >.<
This is now false!
Reply

#13
(11-14-2012, 09:12 PM)hutty Wrote: anyways ... wait ... did you just get it working? .... right now ? .... that was quick ...

thanks

Not exactly, we still don't know if prediction works fine with this. Also, HellYeah's standards for performance are a bit low, so I'd test it some more before calling it a victory Tongue

Also, this is not committed to git. Something to check first is that no official maps use it for a reason different from sliding. We don't want maps to become randomly slippery heh.

I suggest adding a patch to the tracker or, better yet, sending me a formatted git commit based on the current master so that I can submit a branch and merge request. A plain old patch can work too, but no guarantee.
Reply

#14
Actually, I'm afraid this will break prediction. This is quite bad. The engine prediction code does not seem to have anything related to alternate friction.

I'm afraid I'll have to wait for this to be discussed further before it gets a branch. The last thing I want is a hanging branch that I have to maintain.
Reply

#15
hutty if you want to test out
http://ompldr.org/vZ2I5cw/xmod-chaos-esq...naries.zip

Rename to zzzzzzzzzzz999999-stuff.pk3

I suggest puttng it in a alt game directory and executing with -game altgamedir
Lots of stuff changes and I wouldn't want your vanilla xonotic configs getting changed.
Reply

#16
Don't bother with that humongous file of his, hutty.

Just use this pk3 with a git autobuild (csprogs included to make sure there are no incompatibilities). And set the sv_friction_slick cvar in the xonotic console before starting a game:
Code:
set sv_friction_slick 2
(default friction is 8, set it to something a bit lower).
Reply

#17
[Image: 3RR4Gk75TBzRbQ1C1ara17]
wow ...

I tested this in my 0.6 (single player) ... it works beautifully ...

There is even some interesting acceleration you get from strafe/turning mouse .. while sliding ...
thus adding a new way to gain speed ...

time to make some ice maps
Reply

#18
(11-16-2012, 01:37 PM)hutty Wrote: [Image: 3RR4Gk75TBzRbQ1C1ara17]
wow ...

I tested this in my 0.6 (single player) ... it works beautifully ...

There is even some interesting acceleration you get from strafe/turning mouse .. while sliding ...
thus adding a new way to gain speed ...

time to make some ice maps

No. Did you test it on a server with more than 50 ping? Prediction does not support sliding surfaces.

As long as this is not sorted out, there will be no sliding surface in Xonotic.
Reply

#19
(11-16-2012, 03:22 PM)Mr. Bougo Wrote:
(11-16-2012, 01:37 PM)hutty Wrote: [Image: 3RR4Gk75TBzRbQ1C1ara17]
wow ...

I tested this in my 0.6 (single player) ... it works beautifully ...

There is even some interesting acceleration you get from strafe/turning mouse .. while sliding ...
thus adding a new way to gain speed ...

time to make some ice maps

No. Did you test it on a server with more than 50 ping? Prediction does not support sliding surfaces.

As long as this is not sorted out, there will be no sliding surface in Xonotic.

But there is in (single-player) modified xonotic. By the time he's done with his icemaps perhaps an engine hacker may have ... made things better?
Reply

#20
[Image: 4LHtsUrRmBM9O9elMyBAKg]

No ... I have not tested it on a high ping server ...

Is the prediction code part of darkplaces? ... or part of xonotic ...

iceskating is fun btw ...
Reply

#21
Hutty I think we all, you me everyone, need to start learning to hack darkplaces code.
These years and years of (first nexuiz and now) xonotic's existence most of us have taken a few forays into quake C, a few quick incursions at first and then one day we suddenly have learned enough that we "understand" how the language and the world it creates, the world we virtually inhabit, actually sorta works.

But that's just half of the puzzle. We neglect the other half of this universe, this population of code. We ignore it and say we can never understand it. How can we really make any progress when 50 percent of the code remains neglected by us? Beyond a pall of superstition and fear? I say we start to learn that code and we start to make some features we may want there, and I propose that we do this together with mutual support, and maybe even guidance from those above us in understanding.
Reply

#22
(11-16-2012, 07:45 PM)hutty Wrote: No ... I have not tested it on a high ping server ...

Is the prediction code part of darkplaces? ... or part of xonotic ...

It's part of the engine because it would have to be CSQC otherwise. Since CSQC is fairly recent compared to prediction and implementing CSQC players is a big chunk of work, it has not been done yet and prediction is still done by the engine.

(11-16-2012, 08:34 PM)HellYeah Wrote:
Hutty I think we all, you me everyone, need to start learning to hack darkplaces code.
These years and years of (first nexuiz and now) xonotic's existence most of us have taken a few forays into quake C, a few quick incursions at first and then one day we suddenly have learned enough that we "understand" how the language and the world it creates, the world we virtually inhabit, actually sorta works.

But that's just half of the puzzle. We neglect the other half of this universe, this population of code. We ignore it and say we can never understand it. How can we really make any progress when 50 percent of the code remains neglected by us? Beyond a pall of superstition and fear? I say we start to learn that code and we start to make some features we may want there, and I propose that we do this together with mutual support, and maybe even guidance from those above us in understanding.

Words, words, words. You've been saying this for a long time, too. That, and asking people to do stuff for you.
Reply

#23
You seem in a bad mood today. The fact is that I've been hacking on the quake C for about a year now, sure it doesn't help your game, but your game is completed: you have a platform for competitive map play. I want more and have added more to my version of your game. I wanted and I did. I learned.

Hutty asked for slick to be supported. It is now supported to a degree that he is happy with.
Why can't I ask for things I want? I helped out. Weather it's complete or not is not my concern, it's good enough for some fun. If you feel this pressures you or others to add some sort of prediction code to the engine: it doesn't. You don't have to work on xonotic code at all, nor does anyone, as far as I can see you see xonotic as "done" in the code area. It supports the gameplay you like, for you xonotic is complete.

For others it must be extended. Some people take offense that people would want to extend it. That is a problem within themselves.

And yes I would like for someone to help me with stuff that I cannot do but would like to exist, and there is nothing wrong with that.
The ramp into the engine is much more steep than into QC, qc has books dedicated to explaining it.

Hutty you should make many ice maps and release them to the community. They'll be fun for those of us on LANs atleast. Tons of ice maps. You do not have to do things the proper way.
... but if you want to do things properly, time to go into darkplaces/*.c Smile

server.h:extern cvar_t sv_friction;
prvm_offsets.hTongueRVM_DECLARE_clientfieldfloat(friction)
prvm_offsets.hTongueRVM_DECLARE_field(friction)
cl_input.c: cl.movevars_friction = cl_movement_friction.value;
client.h: float movevars_friction;

One needs the engine would need to know when to use sv_friction_slick rather than sv_friction.
In the quakeC it was a matter of using a allready-known routine to check what's under the user's feet.
But how can we communicate either that or that the entity is using a different friction to the engine?

clmovement_ seems to be stuff about client prediction, so where it is, there seems to be prediction code.

in sv_user.c there is:
case MOVETYPE_WALK:
SV_RunThink (ent);
// don't run physics here if running asynchronously
if (host_client->clmovement_inputtimeout <= 0)
SV_WalkMove (ent);
break;

Though in static void SV_WalkMove (prvm_edict_t *ent)
I don't see much about friction of the sort we're looking for.
Reply

#24
No, no, I don't feel any pressure. I just find it odd that you're trying to motivate hutty to do stuff that I've never seen you do yourself.
Reply

#25
I don't know enough about the engine to help with prediction. If I did know about the engine there would be a bunch of more gib effects avaliable Tongue.

Making maps is about having fun tho, so have fun.
Mr. Bougo: What do you mean, nowadays I just add whatever code or things I want to the QC rather than ask for them. I'm normally not in communication so you may not know of this.
What is wrong with me asking for help for things I don't yet know how to do? I would be very happy if someone would add the things I want in the engine to it, since I don't know how to do it why not ask? Hutty didn't know how to add slick support, he asked, and he was rewarded for that. Since I helped him in something I was not interested in but saw would not take too long to do, why shouldn't I ask others for similar help in things I don't know enough about but which LH says would not take long to do?
Reply



Forum Jump:


Users browsing this thread:
1 Guest(s)

Forum software by © MyBB original theme © iAndrew 2016, remixed by -z-