OpenJK General Topic

[serenity0937]

There does seem to be a fair amount of negativity on some of the JKA related forums.

And it seems inevitable that sometimes people disagree on certain matters.But its also true that if a new guy who knows very little about a certain topic posts a suggestion or idea,on some forums he can get "flamed" and practically abused for his suggestion.

 

I've noticed this happens more and more on coding forums(not naming any specific forum).Coding is a difficult topic to address,and it takes time to learn and master,but many "good" coders become "cocky" and "arrogant" to the point that they actually scare people away.

 

OpenJK is the only code currently being "openly" worked on for JKA,and as such is the best choice people have,Some of the best JKA coders are involved in maintaining this code.But people need to be aware "Anything is possible" is a false statement.The code still has boundary,s that must be adhered to .Even if stretching the limits is possible.Some guy asked me if i could put physics and Euphoria code into Evolution of Combat once and the answer is definitely "No".

 

I myself use the Original release of JKA SDK that was posted when it was first release,But i use OpenJK GitHub as a source for fixing bugs and maintaining stability.

​I think they have slightly digressed from the original idea of maintenance and fixing bugs and are just coding in some things for the sake of coding and in doing so they are risking stability.

 

Suggestions for OpenJK with the greatest respect.

 

Fix all the errors / Warnings that appear when compiling the code in Debug and Final mode.

I downloaded the code a few weeks ago to "Take a look at it" and the first thing i noticed was all the warnings when compiling in Debug, and the code didn't even compile correctly in Final mode.I think this is far more important than adding visual (renderer) addons.

This will give people a clean base to work from and improve stability when playing .The game crashes for various reasons and on multiple instances when playtesting.

There are lots of warnings that would be simple to fix,but "A new coder" might not be able to fix these small errors.

I.E.  q_shared.cpp(919): warning C4389: '==' : signed/unsigned mismatch. A simple problem that could/should have been fixed by now.

Think of a beginner who only wants to increase rocket speed or something simple like that ,no way he could fix any warnings/errors before he even starts .

 

If the code is being maintained and prepared for people to download and develop, maybe add some things that could make thing easier for new coders/Developers.

 

New button slots - the code needs new button slots so people can assign new buttons to do new things they may be working on. ie grapplehook /sprinting/prone /etc,etc

I've added 5 new button slots in my code even though i am only using 3 at the moment.

 

And finally stop changing the names of things that are already in the code to OpenJK. The exe and the sp cfg don't need changing as don't  many thing ive seen in the code.

 

The OpenJK team is doing an amazing job and im sure there source will be the base for many mod in years to come. But people need to realize that they are not making a "mod"

​They are preparing the code for further development and updating many aspects to bring the code up to date to run on newer more powerful machines. So don't be too harsh on them or they may just stop.Then JKA will have lost a good thing.

[mrwonko]

The code still has boundary,s that must be adhered to .Even if stretching the limits is possible.Some guy asked me if i could put physics and Euphoria code into Evolution of Combat once and the answer is definitely "No".

That's wrong. There are no limits to what you can do, it's just a loooot of work. Well, and in the case of Euphoria it'd also be a matter of getting its SDK, which is apparently nigh impossible, so maybe that's why you got a definite "No", but there are no boundaries imposed by the code itself, since you can change all of it, there are just boundaries outside the code, like your skill, time, available libraries etc.

New button slots - the code needs new button slots so people can assign new buttons to do new things they may be working on. ie grapplehook /sprinting/prone /etc,etc

 

I've added 5 new button slots in my code even though i am only using 3 at the moment.

You added them yourself? So that's obviously possible then, I don't see why OpenJK has to do it for you. That's very much a gameplay change and thus outside the scope of OpenJK. If you want newbies to have an easier time modifying OpenJK, you should ask for/write tutorials on how to add new buttons etc., not clutter OpenJK's codebase with unused code.

[serenity0937]

You added them yourself? So that's obviously possible then, I don't see why OpenJK has to do it for you. That's very much a gameplay change and thus outside the scope of OpenJK. If you want newbies to have an easier time modifying OpenJK, you should ask for/write tutorials on how to add new buttons etc., not clutter OpenJK's codebase with unused code.

 

Exactly what i mean about people being sarcastic rude or aggressive,at people suggestions.

 

Of course i added them myself,OpenJK does not have to add them for "ME" and adding the possibility to make new button function does not alter gameplay any more than adding " WPN_Damage" and "WPN_SplashRadius" edits, yet this has been done."and a good thing it is too".

 

Not everybody is an "Expert " like you. And im just thinking of the people who are just getting started, My god even JKA mp sdk has free button slots, so why no sp too?

 

Maybe you just don't like constructive criticism.

 

OpenJK does not have to add any of the suggested changes, maybe you don't agree, maybe you just don't want to. But this attitude that you seem to have when answering or commenting is the biggest problem of all.

 

Play nice its not hard to be polite.

[Tempust85]

Xycaleth & Razor are the only OpenJK coders that I know of who don't act like know-it-all-im-god-asshats to newcomers or randoms with questions.

 

There was this one guy who came to jacoders asking questions about OpenJK and Ensiform was quite rude.

 

my advice to anyone with a question/suggestion: approach Xycaleth or Razor.

[mrwonko]

Exactly what i mean about people being sarcastic rude or aggressive,at people suggestions.

Mind explaining to me how I was being rude/aggressive? I didn't mean to be, sorry.

Not everybody is an "Expert " like you.

As far as Jedi Academy goes, I'm not actually an expect. I've hardly done any coding beyond changing some rocket velocity and the like.

OpenJK does not have to add any of the suggested changes, maybe you don't agree, maybe you just don't want to.

I'm not really part of OpenJK anyway, by the way. I just hang out with those who are in IRC occasionally and discuss requests.

[serenity0937]

"Applies to JKA as well. Note that JKA's lightmap size (max) cannot exceed 128x128."

 

This is a quote from a previous post, I will not name the person and bring him into this discussion but needless to say he is one of the openJK  maintainers and a highly respected coder and member of the JKA community,he definitely knows what he is talking about.even if you "think" i dont.

 

That's wrong. There are no limits to what you can do, it's just a loooot of work. Well, and in the case of Euphoria it'd also be a matter of getting its SDK, which is apparently nigh impossible, so maybe that's why you got a definite "No", but there are no boundaries imposed by the code itself, since you can change all of it, there are just boundaries outside the code, like your skill, time, available libraries etc.

 

My point is this. 

 

The code does have its limits in various areas and pushing these limits can cause stability issues.Its not just a case of increasing a definition limit.Its not worth it at the cost of stability.Why do a mod if its going to crash before the start credits have even finished?

 

 

Mind explaining to me how I was being rude/aggressive? I didn't mean to be, sorry.As far as Jedi Academy goes, I'm not actually an expect. I've hardly done any coding beyond changing some rocket velocity and the like.I'm not really part of OpenJK anyway, by the way. I just hang out with those who are in IRC occasionally and discuss requests.

 

Then if this is true,you are exactly the type of person im trying to help by making suggestions that would make life easier for people like you.

 

You answered the initial post i made without even considering the implications or discussing the proposal with the other maintainers,and just shot out the idea.without a reasonable reason.

"not clutter OpenJK's codebase with unused code" The unused button slots would be there for future coders to use. Its not clutter .Writing OpenJK all over the code is clutter....

[Apprentice]

@@Apprentice - Check out some of the ICARUS tutorials we have here on JKHub. They are under the 'Mapping' section. It's really not as tough as it looks, you'll catch on quick!

Those tutorials don't get me anywhere . . .

 

 

Anyway, I was under the impression that this thread was also a suggestion thread, so I made a suggestion to have a func_door_rotating as an additional mapping entity so that we mappers have an easier way to implementing rotatable doors . . .

[Xycaleth]

I would in general appreciate it if people were to ask legitimate questions or ask for legitimate features (read: not renderer-related ones outside of bug reports about broken renderer stuff), instead of, as Xycaleth mentioned with the GitHub issues, slog through a ton of junk issues which pertain to renderer crap like bumpmaps. We get enough questions like "Is X possible?" or "Can you guys add Bloom/normal maps/realistic physics/cloth physics/HDR/water physics/mesh collision/motion blur?" to allow me to simply say "No, read the OP next time please." Saves everyone a lot of time and effort.

I never said there were a ton of junk issues on GitHub :| I was saying that not everyone is familiar enough with GitHub to find all the issues we've fixed and are currently working on.

 

But i use OpenJK GitHub as a source for fixing bugs and maintaining stability.

In case you didn't realise, please note that by using OpenJK's code, you need to license your code under the GNU GPLv2

 

​I think they have slightly digressed from the original idea of maintenance and fixing bugs and are just coding in some things for the sake of coding and in doing so they are risking stability.

As far as I'm aware, the majority of the changes made so far are aimed at improving the existing engine. One of the more controversial and major changes like moving the location of where the config and PK3s are loaded from allow JKA to be installed in a multi-user environment without requiring administrator rights to add new mods. While it's not so necessary for Windows, this is more common on Linux and Mac.

 

Suggestions for OpenJK with the greatest respect.

 

Fix all the errors / Warnings that appear when compiling the code in Debug and Final mode.

[...]

I'm currently in the progress of removing the majority of the compiler warnings in GCC and Clang. When I've finished that I'll be looking at clearing up warnings produced by Visual Studio.

[eezstreet]

I wish people would call me arrogant/an asshat to my face. It would make the job of reading through the lines a lot easier.

 

@serenity: About the new buttons, you'd break backwards compatibility with the original game because in order to add more button slots, you'd have to change the networking code to allow for more than 16 buttons (Note: the 15th button slot was broken, OpenJK fixed it). For single player this wouldn't be bad, because backwards compatibility is already broken, and there aren't any mods that would be affected. On the other hand, multiplayer would be filled with issues with jamp.exe clients trying to connect to OpenJK servers and vice versa. We want OpenJK to work with base clients as well.

 

@@Apprentice: Yeah, that isn't a bad idea per se. It just depends on how much demand there is for it. We don't want to implement things for the sake of implementing them, especially if only a small handful of maps are going to make use of them.

 

I generally try to help new people and point them towards the JACoders tutorials, and I can offer some help in C, but a lot of the time I see people asking, "How can I make a new power that makes Jedi shoot lasers out of their eyeballs?" or stuff like that which is way too complex for a beginner to do. My advice to those people is to start small and work their way up.

 

@Serenity; the signed/unsigned issue is not exactly an issue, it doesn't affect stability really at all. A signed/unsigned mismatch occurs when you're comparing, for instance, an unsigned integer variable with a signed integer variable. For example:

unsigned int x = 6;
int y = 6;
if( x == y ) {
...
}

The above code is valid but will generate a warning. It's perfectly legal and stuff to do that, but the warning is quite annoying. So in Visual Studio, we can disable this warning by simply putting this line of code, somewhere where all the code includes (such as q_shared.h):

#pragma warning(disable: 4389) // signed/unsigned mismatch

This line of code causes issues in Linux, so you'll want to make sure it only does it in Windows.

#ifdef _WIN32
#pragma warning(disable: 4386) // signed/unsigned mismatch
#endif //_WIN32

[serenity0937]

 

 

@serenity: About the new buttons, you'd break backwards compatibility with the original game because in order to add more button slots, you'd have to change the networking code to allow for more than 16 buttons (Note: the 15th button slot was broken, OpenJK fixed it). For single player this wouldn't be bad, because backwards compatibility is already broken, and there aren't any mods that would be affected. On the other hand, multiplayer would be filled with issues with jamp.exe clients trying to connect to OpenJK servers and vice versa. We want OpenJK to work with base clients as well.

I Totally agree, 15 seems to be the max you can add  (ANOTHER LIMIT)  without having further issues.But the standard JKASDK only has 9 slots,maybe you already added some slots in the OpenJK SDK.Im talking about singleplayer here not multiplayer, as multiplayer already has 14 or 15 slots that are usable.

 

I had to add new slots in cl_input.cpp / ui_shared and of course q_shared.h in my code as it only had 8 usable slots.

void CL_InitInput( void )
	Cmd_AddCommand ("+button9", IN_Button9Down);//kick
	Cmd_AddCommand ("-button9", IN_Button9Up);
	Cmd_AddCommand ("+button10", IN_Button10Down);//block
	Cmd_AddCommand ("-button10", IN_Button10Up);
	Cmd_AddCommand ("+button11", IN_Button11Down);//dodge
	Cmd_AddCommand ("-button11", IN_Button11Up);
	Cmd_AddCommand ("+button12", IN_Button12Down);//free
	Cmd_AddCommand ("-button12", IN_Button12Up);
	Cmd_AddCommand ("+button13", IN_Button13Down);//free
	Cmd_AddCommand ("-button13", IN_Button13Up);
	Cmd_AddCommand ("+button14", IN_Button14Down);//free
	Cmd_AddCommand ("-button14", IN_Button14Up);

static bind_t g_bindings[] = 

{"+button9",        -1, -1, -1, -1},
{"+button10",       -1, -1, -1, -1},
{"+button11",       -1, -1, -1, -1},
{"+button12",       -1, -1, -1, -1},
{"+button13",       -1, -1, -1, -1},
{"+button14",       -1, -1, -1, -1},
{"+button15",       -1, -1, -1, -1},

 

//New EoC serenitysabersystem buttons
#define BUTTON_KICK     512 //+button9   KICK
#define BUTTON_BLOCK     1024        //+button10  BLOCK
#define BUTTON_DODGE 2048        //+button11  DODGE
#define BUTTON_BUTTON12 4096 //+button12
#define BUTTON_BUTTON13 8192 //+button13
#define BUTTON_BUTTON14 16384 //+button14

 

CL_CmdButtons( usercmd_t *cmd )

for (i = 0 ; i < 16 ; i++)
{
if ( in_buttons[i].active || in_buttons[i].wasPressed ) 
{
cmd->buttons |= 1 << i;
}
in_buttons[i].wasPressed = qfalse;
}

 

 

 

If you guys have already addressed this issue then please ignore my suggestion.  

Thanks for the reply eezstreet.

[eezstreet]

Change usercmd_t -> buttons from 'short' to 'unsigned long', and you can have up to 32 button slots, provided you add all the necessary info.

This applies to MP and SP.

[Fighter]

I'll go ahead and lock this thread. It's getting rather large and now that OpenJK has its own section, that would be better suited for OJK discussion rather than just one thread.