OJP (Open Jedi Project)

[Emon]

It still violates the idea that OJP is a mod directly for developers, not for players. What you are proposing is the opposite. What I am proposing is what Razorace and I originally thought up many months ago.

 

But, I have an idea. If you want to do a gameplay mod, perhaps some of the members of the team would be interested in collaborating an OJP based gameplay mod, which would be an entirely different entity. It's just that OJP itself was never designed directly for the players, and I think it should stay that way.

[RenegadeOfPhunk]

Yeah - I understand I may have a different idea than was originally planned. And sorry if I'm rocking the boat a bit dude

THat's why I made my first post in this thread so long - to make sure I wasn't getting the idea of the OJP wrong...

...I'm guessing you didn't read it!

 

But, I have an idea. If you want to do a gameplay mod, perhaps some of the members of the team would be interested in collaborating an OJP based gameplay mod, which would be an entirely different entity. It's just that OJP itself was never designed directly for the players, and I think it should stay that way.

 

Well - ermm - ok. Do you mean a whole different repository, admins etc.?

 

...do you think that's a better solution than a few preprocessor defines?!

 

My idea of the OJP is still to help share developing resources. Why have 3 different developers work on similar gameplay 'additions', when it can just be put into the OJP by one, and then used by all?

 

Mine isn't a totally different concept to yours!! Mine just isn't limited to non-gameplay changing features - that's all.

 

But anyway - sounds like it's essentially end of discussion for you. THat's not what you had in mind, so that's not what's happenning. If so - ermm - fair enough I guess...!

[razorace]

Woah, lots of activity here.

 

I'm just going to weigh in before heading off to work. I'll be home in about 5 and 1/2 hours.

 

I'm voting for the 2 build system:

 

Basic - (Emon's) Does game side modifications ONLY. There will be no gameplay modifications in this build. It will ONLY bug fixes, map entity additions,etc.

 

Medicorran Enhanced - (Phunk's) Alters both game and cgame code. Also allows good gameplay additions.

 

To keep things under control, we should NOT cvar everything. Instead we need to just tag every major feature with comment tags to allow people to add/remove major features at will. Whither these things are "on" by default will be up to the moderators.

 

This means that functions will have to duplicated for the major function rewrites.

 

In addition, I propose that we do NOT put any per person comment tags in the code. Instead, we'll do it on a per feature basis and then list all the credits in the credits file. That way we wouldn't have person tags up the ass when multiple people end up working on a single feature.

[razorace]

BTW, the gameplay code sharing was part of my original OJP concept. I never mention to imply that gameplay changes were outside the scope of the project. I was simply minimizing the concept to make it clear that we only want the good gameplay additions.

 

Anyway, the two builds will be handled on the same repository. They will just be in seperate directories. The what's new? files will probably be seperate and the credits/rule handbook/readme files should be shared.

 

Off to work!

 

end of line.

[Wudan]

You run a high risk of having one big ugly codebase, if you just have everybody's stuff thrown in to one big soup.

 

I'm really not sure what Emon thinks that the mod might be - if you want a set library of things that mod devs use to make a mod - we'll have that when the SDK comes out.

 

You'll find that people agree and disagree on what should or shouldn't be in a mod - the key concept of OJP (imho) is that if we all do LMS (for example), we should collaborate and make the most possible stable set of code for it - an OJP LMS module.

 

I think that the gameplay altering sources should be in separate files, with the best possible guide to plugging the code in to the SDK source (or perhaps a core OJP codebase), that way you won't have your gameplay changed unless you opted for it.

 

I know that I'm very afraid of writing a mod too similar to other OJP mods, but I'm pretty certain that it is not. I can benefit from OJP though, if it's done right.

 

Let's decide on how it's going to work.

[RenegadeOfPhunk]

Wudan,

 

Your right - we need to think about how - practicaly - it will work. But it can work - I'm sure of that.

 

I think the first obstacle is just deciding what were actually trying to achieve first! It seems to me we haven't actually decided that yet!

 

Once we DO decide that, then we can start talking about how we practically approach it. Many of the suggestions you've made sound sensible - for certain cases...

[Emon]

Well then, Razorace, you did a pretty poor job of explaining it to me in those two pages in the other thread, because I have been convinced that it's a mod for developers mostly.

 

If you've programmed in C++, you've probably used the STL, Standard Template Library, and you know how incredibly easy and powerful it is, and how much time it saves when programming. I think OJP should be similar to this. Let's fix bugs, make new entities, fix up the AI or vehicles, things which don't alter gameplay, but provide a good base for other developers. You all want to stop lookalike mods, but if you start putting gameplay changes in a mod that's labeled as a base for other developers, guess what, people are going to leave them in there, and mods are going to start looking the same! That's why if you leave out all but the basic balacing fixes, you can leave up originality and creativity up to people who use OJP in their mods, which reduces lookalike mods.

 

Also, most players aren't going to freely accept the mod if it's going to start seriously mucking with their gameplay. A lot of people like vanilla versions of their games. With my idea, OJP would keep that intact on many servers, but allow for much more advanced levels to be created.

 

Do you guys understand what I'm saying?

[Emon]

I think we need to be in a chat to discuss this. Since we're all here as it is, come to #OJP on GamesNET.

[Emon]

I don't know why we disagreed, but after some chatting, ROP and I seem to have come to an agreement and understanding on what we think OJP should be. I think was partly confused, and just looking at it the wrong way.

 

I think I can sum it up by describing the two distributions of OJP.

 

1. The first distribution would be a barebones, streamlined mod for developers and players. For developers, it would include all the bugfixes, AI enhancements, and anything else that mappers could use in their levels. The only gameplay modifications would be balance fixes and bugs, things that everyone would agree on. Not everyone would want jetpacks or mouse sabering, we can leave that to the second distribution.

 

Think of this one as a stable base for both mappers and players, but modders could use it too, especially if their mod has nothing to do with what's described in distribution 2. What was really cool about the original JK was that you could have new maps that had totally new code, and could be played with any mod. In most cases, it was something basic in concept, like a new type of elevator, a trap of some sort, etc. You can't really do that in JO without a mod, which means you can't be playing other mods while playing the level. With OJP, we can code for the mappers (on demand of what's needed in the community), we can add versatile, modular and flexible systems that fit any mapper's needs.

 

This lets you play really sweet maps with still a (basically) vanilla game. No major gameplay modifications, just fixes and better maps.

 

2. This distribution is designed for more serious changes. It's a superset of distribution 1, it includes all it has, and more. Again, every new feature has to be really versatile and adaptable. Examples could be, say, a dual wield weapon system, mouse sabering, LMS, a player class system, etc. You'd still keep most if it basic, no shockingly specific gameplay alterations, just good features that a lot of modders would want, and can adapt them to their own stuff. And because it's a superset of the first distribution, you can still run all the maps.

 

I don't know about the rest of you guys, but cool features in maps is really important to me. JO kind of limited you on this, and although JA is better because of scripting, it is not perfect. It's probably because I spent so many years in the original JK, I came to really love and understand the potential maps can have. With OJP and all mods based on it, you can have a map with all kinds of cool stuff that works in any mod.

 

As far as copy cat mods, I'm not really worried any more. Again, I remembered back to the original JK, and everything was open source, because code and hardly anything else was stored in other than ASCII. But it was never a problem! Rarely was work stolen, and if it was, it was just taken down by request of the author. I think the main reason for copy cat mods in JO is that everyone was too busy trying to fix the bugs and the balance issues, and trying to create what they thought JO should have been. The first distribution fixes that on the most basic level. No more bugs, no more balance issues, just vanilla gameplay. The second one doesn't cause the copy cat issues I thought it might earlier, because if the fundamental issues are solved, people are going to start working on the more important stuff.

 

 

So, what do you guys think? Are we all clear on this?

[RenegadeOfPhunk]

Sounds great Emon.

That covers it all.

 

Now if we are agreed on the purpose of OJP, we can move on to practicalities.

 

btw - I have applied to ChrisC3P0 for seperate forums and webspace for the OJP project.

He did say it sounded like a good idea, but didn't confirm anything. I'm hoping to hear from him soon.

 

I think seperate forums especially will be great! Trying to continue all this stuff in one thread is a real ball-ache!!

[Emon]

That's great, ROP. Try to get us a private forum, too.

 

We can host our source code at a place like Freerepository or Asynchrony, but I think having our forums and web space right here with the community is not only convenient, but functions as an ad, too.

 

Which brings me to my next point, advertisement. It's going to be a while before everyone accepts the mod and it becomes widespread. I think if we can get big mods like the DF mod and AotCTC to use OJP, the words "Built on OJP!" or whatever would give us a lot of publicity. I'll talk to the rest of the DF mod team, and see what they have to say. I'm pretty sure they'll agree, especially because they need the AI. Also, any code they develop could be a great boon to us, and consequently the rest of the community.

 

Another great example for my map thing is co-op or other gameplay modes. We can code those in, and it would make it really easy for people to make co-op or whatever kind of gametype maps. I can't imagine the popularity we would get from co-op, you've got no idea how many people want something like that! Especially if we go recreate the ents from SP, like verbatum, hopefully it could be possible to boot up most all SP maps into MP and play them. I already tried, and it actually ran, but was just missing entities.

 

Edit: I'll start working on a page layout and the graphics for it, more on that tonight.

[RenegadeOfPhunk]

The possibility of co-op is indeed very sexy!

 

And yes - I think we need to get as much of the modding community on board as possible. At the end of the day, the more this is standard across the board, the more it benefits everybody.

[Emon]

Oh, and in addition to the forum idea where current tasks and whatever are listed, we have to make sure our CVS host supports checking in and out of files, so that only one person can edit a file at a time. For added safety. I think this is a standard thing, but we should check anyway.

[razorace]

Question, on the plan you guys came up with (which sounds just like I suggested) would Distro 1 be BG or G only? I know a lot of people want game only mods to make it easy for people to join the game. If Distro 1 is to appeal to tourny players, it needs to be game only.

 

I know some of my stuff (the updated animation system) requires BG modifications.

 

Secondly, the whole point of CVS is to prevent a checking in/out system. We want to maximize the number of people that can modify the code at the same time. With CVS, the only issue will be that you sometimes have to manually handle conflicts if someone commits something while you were doing your modifications.

[Emon]

BG? You mean client game modification? Yes, it would require that, but I don't care about the competitive community. Quite frankly, most of the competitive community sucks in my opinion, and they're never going to use a mod unless it's entirely perfect to their exact specifications, and is designed for exploits and tricks, something which I find stupid.

[razorace]

Suggestions for coding guidelines:

 

- All code should be as isolated from the normal code as possible. I suggest seperate functions whenever that's approprate.

 

If you have to alter a large portion of an existing function to make things work, make sure you leave an original untouched copy of the function (commented out of course).

 

- I suggest html style tags to indicate when changes are started/ended. Example:

//[AS2.0]
//code goes here.
//[/AS2.0]

 

Features should use analogies. Bug fixes and code improvements can probably just use something like "[bug Fix #]" and

.  We can leave the explainations of Bug Fixes and such in the project documents.   

 

- Try to document your code as much as possible.

[Emon]

Good idea.

 

You can also be extra fancy and do this:

 

/***************
*  New feature A  *
***************/

 

[Emon]

Preliminary site layout from 1:30 AM, I think the comments emphasize my fatique...

[razorace]

Originally posted by Emon

Good idea.

 

You can also be extra fancy and do this:

 

/***************
*  New feature A  *
***************/

 

 

Well, we don't want to make it too complicated because some of the more complex features take a LOT of on/off tags to work. The key is to have something that is easy to ctl+F for.

[RenegadeOfPhunk]

About check in's and out's

 

I think whatever CVS we end up using should have some kind of check-in / check-out system. (If it doesn't have that, it won't be a very good one...!)

 

That doesn't mean only one person can modify a file at a time. If the CVS is good, it should allow 'multiple' check-outs - which means more than one person can have any one file checked out at the same time.

 

This gives the CVS extra information (person A checked out the file before person B etc.) it needs to do a LOT of the merging duties automatically. We will still need to do some manual merging in particular cases, but hopefully this should be reduced to a minimum if the CVS is good....

 

So, if at all possible, I'd make that one of our criteria for whatever CVS we go for - the capacity for multiple check-outs...

 

As a second priority, it would be handy if the CVS gave us the control to say file A can be checked out multiple times, but file B CANNOT. This can make merging easier if conflicts in particular files end up being particularly nasty.

 

One example in MFC programming of this we've found at work is we never let the resources.h and .rc files be multiple checked-out. Because there are bound to be conflicts, and trying to merge changes back together in those buggers is a REAL kick in the ballsack!

[razorace]

I didn't know that CVS has a checkout system option or that it makes a difference for the merging process. :| Oh well, I'm still new at this CVS thingy anyway.

[RenegadeOfPhunk]

Hmm...

 

Well, looks like the term 'multiple-checkouts' is a MicroShaft specific term.

(I mainly use Visual SourceSafe)

 

In CVS, the equivalent is basically an unlocked system which merges in changes the best it can.

 

...but since people don't have to 'mark' when they start altering a particular file in the unlocked system, I don't think the auto merge function will be able to get it right as much as the 'multiple check-out' system I'm used to does.

 

...the end result being we'll have to do a bit more manual merging than I'm used to.

 

Plus there is no record of who is working on what file! (Is that correct? That gives me shudders!!)

 

But, looks like this is how it is for online, free CVS - so, oh well!

 

Looks like it has to be a totally unlocked system then!

 

...gives me the creeps a bit. (It's fairly different to how I'm used to working), but what the hey!

[razorace]

Yeah, we're going to have to experiment with the system a bit to figure it out.

 

I'm mainly worried if the commit function does a update scan before attempting to commit. Otherwise, we could have accidents where recent revisions are reverted when someone doesn't update before commiting.

[RenegadeOfPhunk]

I would CERTAINLY hope it does! Or we could end up in SERIOUS s**t!

 

To me, it seems like going about things backwards anyway.

 

Surely it would be easier to make the user at least mark when they start working on a file. (And at the point of marking, your forced to get the latest version of that file from the repository).

That way it wouldn't need to do a scan to determine if they have updated when they should have done - it knows if any other changes have happenned on that file independantly in the mean time and can force a merge...

 

but oh well. We have to work with what we have avaliable...

 

Yeah - we defineltly need to do some tests...

[RenegadeOfPhunk]

If we do these tests, and we find that it's fairly easy to start writing over other people's changes accidently, I think we may have to consider restricting it to (single) checkout's.

 

...either that, or discover a new, better - but still free and online - system.

 

I know, I know - it would end up being a REAL pain in the rectum. We tried to keep it to single (locked) check-out's at work initially - but it turned out to be too much hassle. And we were only 4 of 5 guys who were all sitting in the same room!

 

Were potentially talking about many more people scattered all over the globe!!

 

(But remember, at work, we had the alternative of the multiple-checkout system - which is NOT exactly the same as totally unlocked, it's quite different in many important ways...)

 

 

But what's worse? Causing people extra hassle when they have to wait to check out a file, or leaving open the possibility of having work totally erased from the respository if people forget to do updates when they should? (And with the number of people potentially working on this - I think it's VERY safe to assume that's going to happen at least ONCE...)

 

But anyway - we do need to do these tests and see what the deal is. But if there is ANY doubt - I think we HAVE to consider (single) checkouts - i.e. locking the respository...