The non-interferance code allows you to only see your opponent when in a private duel. You do not see or get stopped by any of the other players in the room.

The Multi-Duel code is a new gametype alternative to the standard duel. It uses the non-interferance code for duels to allow multiple 1v1 duels at the same time. Players are ranked & you can play against someone that is within 2 ranks of your own. This teams up the better players with the better players & the worse with the worse & should create a more enjoyable dueling experience for everyone.

I like to duel, and that would be better than just waiting to be killed by someone that's most likely going to win anyway.

While it's a good idea, it would probably take a lot of programming. The game simply isn't set up to physically ignore other players like that by default.

Well, maybe just have it where multiduels are possible. I don't know how hard it would be, but can you make it where the duelists pass through those not dueling? That would be just as effective.

I like the scoring match ups. That doesn't sound too hard to write, but then again I'm at the 'Hello, world!' stage of C++ programming...

Originally posted by razorace
While it's a good idea, it would probably take a lot of programming. The game simply isn't set up to physically ignore other players like that by default. For the record (so this isn't an issue in the future), the non-interferance code was originally thought up by Jaii der Herr even though Lee refused to give him credit for the concepts.

The multi-duel concept was originally my idea but Lee improved it. Lee already designed a code for this in JK2 & it works damn near flawlessly, if there are any problems I'm sure there is a way around it.

This would be a huge thing for people because no one plays JK for the guns, people play JK to saber fight, well it's annoying to be in an FFA room in a private duel & have someone get in the way, this would eliminate that. It's also annoying to wait to play in duel mode, this would eliminate that.

I'm telling you, this is a HUGE, HUGE thing.Originally posted by Samuel Dravis
Well, maybe just have it where multiduels are possible. I don't know how hard it would be, but can you make it where the duelists pass through those not dueling? That would be just as effective.

I like the scoring match ups. That doesn't sound too hard to write, but then again I'm at the 'Hello, world!' stage of C++ programming... First off, this is C, not C++. Secondly, without the non-interferance code, the multi-duel is not possible unless you build maps specifically for this gametype, in which case it would not be players going through one another, it would be duelists to their designated areas.

Well, if you only did it for the sabers and player movement, it would be easier it would still involve a fair amount of coding. And it would mean that you'd have to disable the guns (or they would act weird).

Originally posted by Marker0077
First off, this is C, not C++.
Perhaps you could elaborate on that? I'm not learning anything if there's no information...

C++ is a superset of C.

C++ has extra keywords and syntax specifically related to OOP (Object-orientated programming.)

I would have actually prefered it if the JKII / JKA (QIII) engines had been written in C++ (like Half-Life for example), since OOP code is much neater to work with in my book...

But the good news for coding beginners is that there is less to learn for plain C :)

OK, thanks. I was under the impression that they used C++... *looks sheepish* :o

Well, the engine is suppose to be in C++. It's just that the qvm code is in C. I suspect that's because it's easier to create a C compiler vs. a C++ compiler. :)

Well, the engine is suppose to be in C++.


Ahh - that's interesting. Wasn't aware of that...

And yeah, a C++ compiler would have been a bigger deal.

...still a shame though. Once you've gotten used to OOP, it's a pain to have to go back to procedural stuff...

Originally posted by razorace
Well, if you only did it for the sabers and player movement, it would be easier it would still involve a fair amount of coding. And it would mean that you'd have to disable the guns (or they would act weird). At first it did not work well with guns but eventually Lee made it work with that too in 1.2.1 I believe. Again, there is a way around damn near everything.

I never stated that it wasn't doable. It would just take a lot of coding. I did something very similar for Dodging in JKA.

You just gotta be realistic with the additions, especially when you're not going to be doing them yourself. :)

Who's not being realistic? Yes it will take alot of work but do you think it won't be worth it? That is a huge plus.

Well, I've been trying to avoid talking about large coding projects (say, more than one week's worth of work) that have no current developers planned. This is due to the fact that there will always be more ideas than people to do them and it's not like we don't have enough stuff to work on as is. :)

As such, I think we need to focus on posting concepts/ideas that developers can work on when they need a break from their primary project.

Not that we can talk about big projects...I just think we need to talk about them in broad terms. For example, this sort of thing would probably fall under "Dueling System" and would encompass all the dueling behavior like private duels, Duel mode, Power Duel, etc.

Hopefully by talking this way we'll be able to coordinate the major projects better. There's no point in reinventing the wheel twice. :)

Well I am sure Lee plans on having this in Duelrs for JK3 but the guy is selfish & won't share his work with the community. This feature is about as big as they come & I think should be in all mods, which is why I am bringing it up here.

You know, I could try to ask him if he'll let us use some or all of his code. Do you have his e-mail? Perhaps if he's asked by someone else, he'll see the light... :)

Well, it's worth a shot. What's the worse thing that can happen? He'll say no?

I think it's Razor's place to talk to him, one coder to another (unless you are a coder). His contact information is on the Duelers web site at http://duelers.jk2files.com).

Make sure he knows that this is going to be put in OJP, which is for everyone in the community.

The only thing I am interested in is the multi-duel code & the non-interferance code.

Here's his e-mail: oattes@not4hire.net.
Razorace, if you are going to e-mail him, then post that you are. If you don't want to, I will.

It's interesting how he has this on the bottom of the duelers documentation:

Obtaining the Code

I intend to release the compiled mod to public JK2 sites for users. I expect that I will also release the source code to these sites eventually. In the interval, I would like to retain a little more "contact" with interested developers. Note that if you want to make changes and build the code, you will need Microsoft Visual Studio. If you just want to read the code to figure out how things really work, or just for the heck of it, that is fine too.

If interested, please send me an e-mail (oattes@not4hire.net) and let me know you would like to get the code. I will send you a URL where you can obtain a code package.

I'll pass. At this point I'm only contacting individuals with cool stuff for JKA currently out. Plus, I don't exactly feel like dealing with trouble issues right now. :)

So, Samuel Dravis, feel free to contact him for me.

Ok, I've sent him an e-mail. :)

No luck, guys - He's not going to release any of the core Duelers mod code. Some of the minor stuff he might release after a while. :(

I knew he would, the guy's a selfish prick but that's okay, one day he will get his. You know what they say, what goes around comes around.

Anyways, I don't think Razor is interested in coding this & I don't know of anyone else that is either. Damn shame.

I'll try to enchourage this as much as possible but to be honest, it doesn't look good.

Sorry, I just don't think it's high on the to-do list. If people want to fight more often, they can just play FFA.

Plus, I got a freakin' full plate here.

Actually, it's all C. Everythink Quake, Doom, and anything done by John Carmack and id has always been C and assembly. Remember John Carmack making a stir when he said Doom III was going to be written entirely in C++? Various minor speed issues, both at compile and run times have been why John Carmack has ignored it for so long. A lot of minor issues have been resolved as compilers have gotten better, but one main reason was that run-time polymorphism is just too damn slow for games.

And, actually, some Q3 based games (HL is based on Q1, sounded like ROP was saying it was Q3) have the game code in C++. Both Elite Force games have it, and I think nearly or all of Elite Force II's code (including engine) is in C++, as it's Rituals UberTools engine or whatever they call it. Since Elite Force by Raven had C++ gamecode, I'm hoping there's a slight possibility that JA's is in C++, but it's doubtful.

Well, that's not what I've heard.

What do you mean by "run-time polymorphism"?

Half-Life was not based on Quake 1 or Quake 2, it was inbetween the 2 actually. Quake 2 was around the time of being released when they started on Half-Life, so I'm not exactly sure why they chose that version of Quake to base it on but that's what I read, it's based on an inbetween version of the 2.

Technically, it started on Quake, but they made many of the same changes to it that id did for Quake II.

razorace, which isn't what you've heard? The run-time polymorphism? It's simple. Polymorphism is overloading things like operators, functions, etc. It's slow because it has to figure out what to call or use at the run time, each time. For example (very simple), if you have:


void foo(int A, int B, int C)
{
...
}

void foo(string A, string B, string C)
{
...
}

for(int I = 0; I < 1000000; I++)
{
static string A, B, C;
foo(A, B, C);
}


Each time you have foo(A, B, C); it has to figure out which function to call, every time, for every iteration of that loop. It's not a big deal with that example, but when you start to have a ton of classes, virtual functions and all that, it starts to get slow, and it starts to matter in games, where everything is real-time.

GameDev.net has a good article on it here (http://gamedev.net/reference/programming/features/impperfcpp).

Emon,


void foo(int A, int B, int C)
{
...
}

void foo(string A, string B, string C)
{
...
}

for(int I = 0; I < 1000000; I++)
{
static string A, B, C;
foo(A, B, C);
}


This example you've used above is an example of polymorphism, but it's not the kind that will cause run-time slowdown.

What you've shown is how functions can be differentiated not only by their name, but also by their parameter types. The compiler will effectively treat each function seperately - and compile them seperately. i.e. no run-time slowdown when compared with the C equivalent. (which would be just a function with a different name)

The example used in the tutorial, however, is valid. The tutorial shows polymorphism as it relates to functions being overloaded by inherated classes. THis does require vtables, and as such, this would require extra run-time to work out exactly which function needs to be called.

...but let's make it clear - a vtable is just a list - nothing more. And unless your class structure is hideously tall, the time taken to traverse the vtable each time COULD be considred negligable -although I accept this depends on how 'real-time' the task is.

I would say the example used in the tutorial - while valid - is a little extreme. It would be a VERY tricky task to ALWAYS single out loops which you can be sure will only EVER be passed one particular object type...

So yes - C++ .vs C is a balance between maintainable code and squeezing absolutely every single cycle you can out of the resulting compiled code... (exactly the same as C vs. assembler)

I would argue that - depending on what 'level' of the code your working on, the benifits of OOP would far outweigh any performance decreases (in fact, I'm not sure in many cases if you would even notice them) - but without knowing all the details of the specific tasks, you can only guess - so...

One thing for sure is that HL used C++ - at least for the moddable parts. And I don't know of HL being a notoriously slow engine because of it...

Well, HL is an old game. It wouldn't be as noticable on today's computers.

You're right, that's a bad example. I realized it when I was in the shower a few minutes ago. :)

Well, HL is an old game. It wouldn't be as noticable on today's computers.


So you would have to compare HL's performance to a similar game from the same time.
What I'm saying is - when HL first came out - were people saying 'Wow - this is slow as hell compared to the other (C) games around...?' - ermm - not that I'm aware of...

And even IF there was a performance issue, how could you be sure which areas of slowdown were being caused by C vs. C++, as opposed to any number of other factors...

...anyway - I guess this is off-topic now - so I won't labour the OOP vs. procedural debate. (Believe me - I've had this type of discussion a lot...!)

Is there any way to adjust the server config to take off the silly green glow , you get when dueling, ....really wrecks the duels................

Look at the date before you post. The threads you've posted in are several years old.

There isn't a way that I'm aware off that involves server configurations.

But you could probably hack the shaders to not display anything for that particular effect thou.

Here's a link to a pk3 to put in your base folder to get rid of the shield. It works for me. http://jediknight3.filefront.com/files/search/?search_category=all&fields_name=1&fields_filename=1&keyword=no+shield&game=38)