PDA

View Full Version : OJP (Open Jedi Project)


razorace
09-17-2003, 02:47 AM
I'm bumping the OJP decision over here since OJP is a JKA project.

The original thread can be found here (http://www.lucasforums.com/showthread.php?s=&threadid=104564).

To continue the discussion, I'm going to suggest that we use SourceForge for our work. I've already seen another JK2 mod on their and cleared it with Raven. All we have to do is get an account.

In addition, I'm going to suggest that we allow my Mouse Sabering work to be in OJP (as a cvar of course).

razorace
09-20-2003, 08:08 AM
Ok, bad news. I checked the license agreement stuff for sourceforge and I'm afraid that we can't really use them for our hosting needs. They have a requirement that we can't restrict commerical use of our code AND can't restrict the "free redistrobution" of such code. This means we wouldn't have control to restrict smacktards and LEC from using our code without permission. That's not really cool.

Any other suggestions for possible hosts for CVS system for the project?

razorace
09-21-2003, 10:04 AM
Ok, good news. I beleive I've found a good CVS repository at www.freepository.com and it has some additional nice features that will help the cause.

Namely, we have to give out a password to join the project AND the project admins have complete control over who has what read/write privs.

Hopefully that will encourage more people to get involved with the project since we seem to have a lot of people that are unsure of our ability to protect our code from the code whores/script kiddies.

As for the command stucture, I think we should give each contributer an vote(s) on the OJP 'Council' (possibly based on contributions made) and let the public (and non-contributers) just provide input. This will mean that contributers have the final say.

I suggest that we approve code/general feature improvements on a majority vote and gameplay improvements on a super majority vote.

In addition, I think we need to lay down some rules for submission. My primary concern is the distrubing trend in the JK2 community of people "withdrawing" their work midway thru a project. For a project such as OJP to success, I don't think we can really tolerate that. If someone "removes" a feature, it could have a domino effect on the project.

While we will respect the rights of individuals to their work, I suggest that we have a submission disclaimer that states that after your work has been submitted, there will be no unsubmitting it. Meaning that the group can continue to use your work (with full credit of course) even if you withdraw from the group.

What do you guys think? Too restrictive or only reasonable?

RenegadeOfPhunk
09-23-2003, 12:49 AM
Razor,

I agree with all the points you have made above - including the clause about not being able to withdraw previously contributed work - makes sense.
The respoitory site you have linked to also looks like a good choice.

I'd just like to clarify what the overall aim of the OJP is though. You probably feel that you have explained it well enough - and if I've not got it, I apologise. I did read back over the old thread, but the different things being said by various people have confused me a little.

Overall, it seems the aim of the OJP is to provide a standard 'library' of bug fixes / improvements etc. That's fine - I get that. And I see the need for these bug fixes / improvements to be regulated and controlled.

Now - from what I've read - the idea is that mods are built 'on top of' OJP - i.e. using the OJP code as a base. If this is the case - then woohoo - this is great!

...but if this is the case, we really do need some solid rules in place to 'police' this. It may seem nit-piky to do so, but this will be ESSENSIAL if this is going to work. Not trying to say any rules I say have to be used, just saying that definete, specific rules HAVE to be drawn up and known by all.

And yes, it is going to get tough at times, and disagreements are going to take place - this is inevitable. But I believe it will be REALLY benificial to all JA mods in the long run.

In fact, OJP is starting to sound a LOT like an idea I put forward quite a while back. I don't think it was very practical at the time I suggested it. But now that we effectively have a clean slate, I think it's a lot more feasible.

I guess the two most important things to make sure of is:

1. Credit needs to be officially given where it is due.
2. Additions to OJP 'material' will need to be regulated by the OJP members.


I think one thing which would help in this regard is a big, phat:
Official OJP webiste
All mods using OJP code would need to link to this site.
This would list all kinds of details - to make VERY certain that credit is given where credit is due. The website would list all contributors to the OJP project. Clicking on the name would give you a full rundown on the features this person has contributed and which mods they are used in.
(Incidently, it would also list anybody who has been deemed to be abusing the OJP.)


I would also suggest the following 'rules' to any mods who make use of the OJP system. (Some of these will have already been mentioned, but I'll include them again anyway just for clarity).

1. To use OJP code, you must contribute something 'of worth' to the project.
Of course, 'of worth' is a relative term, but as has been stated, we would need some way of deciding these things between ourselves. I would suggest a small number of leaders who hopefully can deal with most stuff, but if the leaders do anything which the majority of contributors don't agree with, their desisions can be over-ruled by majority vote.
(THe only reason I don't think ALL desisions should be made by majority vote is that:
a. It would be really hard to try and organise so many votes on (hopefully - if OJP is a success) such a regular basis.
b. I have a sneaky suspicion a LOT of the contributors would not want to get too involved in the administritive side of things anyway, and could end up actually discouraging people to bother contributing in the first place)

2. If contributing features clash in some way, they need to be standardised
For example, two people might contribute class systems. It wouldn't be desirable or practical to have both systems included into the OJP, so some sort of compromise would need to be reached, possible involving cvar-ing various parts of both systems.
Again, it would be up to the leaders (with power to over-rule from all contributers) as to how this is done.

3. Mods using features from the OJP cannot 'significantly' alter the used features.
This basically means in ways which the original authors disapprove of. If they REALLY want to make some alteration to the feature, they discuss it with not only the original mod maker, but with the OJP as a whole, and assuming it is approved, it not only becomes an extra option for their mod, but it must become part of the OJP code. (i.e. avaliable to all mods)

4. Mods made from OJP code must clearly state (somewhere) that they are OJP mods
Ideally, I think we should have some kind of official logo which needs to be displayed prominantly on any official websites, menu's etc. (Think the Intel logo on PC cases, adverts etc.)

We may also want to enforce the listing of every single feature used from the OJP base and give individual credit to each person for that feature directly in the readme's etc. However, tHis could become a bit of a logistical nightmare. Also, I don't think we could trust individual mod makers to go to the effort of getting all the details right. So even if this isn't done in all cases, all this info is on the OJP site which they MUST link to from their mod - that's simple enough to do! (Readme, official sites etc.)

5. Any mod built from the OJP must be 'substantially' different from other OJP mods
This rule is to combat so-called copy-cat mods. In practice, this means that if your mod does nothing more than take a few of the OJP features without doing much else, then you have not done enough to make your mod UNIQUE.

What makes a mod unique? Not just features, but game rules. game design. etc. etc.

Now, of course this is where some disagreements could crop in. But this is always a posssibility no matter how far we go with this, so I say we may as well go all the way... (in for a penny, in for a pound - as my Dad likes to say! ;) )



Yes, these rules are kind of restrictive. They have to be there to make sure that the OJP works like it needs to. Will this mean that no-one will bother contributing? I really don't think so - because at the end of the day there are so many plusses to being involved in the OJP, that it would be worth putting up with the rules.
In fact, the only people I see who would be too upset to deal with it are people who can't keep their ego's in check. And as far as I'm concerned, these are exactly the kind of people we DON'T want in this project.


OK - so now I'm going to use a couple of case examples from JKII and see how they work out with the system I've just described above.
I'm aware that using personal examples might end up backfiring on me, but it's just the easiest way to explain the practical context of the rules I've just listed.


Case 1 - ProMod
Undeniably, the biggest and most unique feature in ProMod was the non-random, competitive saber combat system. Unfortunately, this mod was never as popular as it could have been - because a lot of players were interested in what could be described as 'bells and whistles'.
Sure, if they could have both, then great, but poor Artifex only had so much time as a modder to add all this stuff (and we are all in the same boat there...).

So, let's imagine that Artifex makes ProMod 2 for JA. He adds his main features to the OJP. Now, sure - people are free to take his combat system in their mods. But, he can also take some of the 'bells and whistles' features and incorporate them into his. i.e. everybody ends up with better mods.

IMPORTANT POINT - these other mods aren't going to be ProMod rip-offs because for them to qualify to base themselves off OJP code, they must have been deemed to be significantly different to other already existing (or currently developing) OJP mods.

However, it is possible that Artifex may not need to work on a specific mod.
After contributing stuff such as the Combat System to the OJP, Artifex may find many mods that use his systems in ways that are very pleasing to him. He may then decide that he really doesn't need to do extra work on ProMod, since these other mod(s) essentially do what he was going to do anyway.

However, the only reason he would do this is if he was satisfied he was getting sufficient credit for his work where it was being used. Would he get proper credit? YES - it's a rule of the OJP. It's clearly mentioned on the OJP webiste. In fact, go and click on Artifex's name, and you could potentially find a whole slew of great mods which make use of the official Artifex combat system. (A nice touch might be to allow each contributor to recommend other mods where their systems, in their opinions, were used well.)

Basically, I'm trying to portray a concept where contributors may not actually have their own mods, but instead add great technical features to the OJP which end up benefiting and enriching all mods WITHOUT a feeling of over-competitiveness or resentment.


...to further emphasise this point, let's imagine a senario where someone only adds one feature (the feature has to be 'significant', but still only one) and then uses - let's say - 10 other features from the OJP to make their mod.
Now to me, this is perfectly 'legal' -assuming of course the whole mod concept is significantly different (so they also get credit for game design - assuming the game is good of course!), but at the end of the day the mod is more an OJP mod than theirs. i.e. they can't really call it THEIR mod in the traditional sense. (After all, they only contributed 1 feature of theirs against 10 others from the OJP.)
If they have given proper credit to the OJP and listed only their one feature as theirs, then - job done. However, if the OJP feels the particular mod maker hasn't done a good enough job of making sure people know they did not write the whole mod themselves (i.e. people going on forums and raving about what a great job so-and-so did on ALL aspects of the mod), then the OJP needs to take action etc.

Personally, I think this open approach will lead to some great mods. (This comes from my belief that great game designers are not nessesarily the greatest coders...). And as long as credit is not stolen, there is no harm, and no foul.

(An alternative to this is only allowing people to use as many OJP features as you contribute. i.e. you add one, you get to use one. Of course this means you have to start weighting contributions etc. I would still prefer to do things how I have described above...)


Case 2 - Movie Battles
I'll use my own JKII mod as an example as well, since I'm familiar with it ;)
Also, I can firmly state the mod makers motives with accuracy!

I am very interested in making Movie Battles 2.0. However, what drove me away from JKII modding was:

a. Not having the time needed to add ALL the features I wanted in the mod.
b. THe feeling that I was constantly competing with other mods. Personally, it just drove me up the wall.

OK, so, I start Movie Battles 2.0 by contributing my main features to the OJP - assuming they are accepted. These would be LMS system, team and class model-forcing etc.

I would like to think my mod would not be just a copy-cat of other mods. To list just one point, I'm not a believer in lots of cvars, so in my mod lots would be locked down. (For starters, the LMS system would not be optional...)

Ok, now I get to use other OJP features which would enhance my mod - thus saving me a hell of a lot of time and effort. I haven't STOLEN them, I have earned them by contributing to the OJP - and I must publicly admit they are not my features anyway!
(In fact thinking of it as just 'my' mod would be a mis-conception. Once you use OJP features, you are effecively working on an OJP mod - i.e. it's not solely your own anymore. If this is too bitter for you, then you won't have joined OJP in the first place...)

At the same time, other mod makers can go ahead and use - for example - my LMS system in their mods. This is fine by me. I get credit when it's used, and I know that no-one can use my features to make a copy-cat of my mod. (It's in the rules).



Sorry about the long post, but I felt it was nessesary to get across what I'm proposing.

WHat do you all think? The rules may seem long-winded, but their not really. The bottom line is 'We all use each-others stuff in a fair way'. The rules are only to draw border lines around the technicalities...


Renegade

razorace
09-23-2003, 04:51 AM
Thanks for joining the conversation Phunk. I was starting to sound like a loony without other people posting. People keep talking to me privately instead of on the boards. :P

In fact, OJP is starting to sound a LOT like an idea I put forward quite a while back.

Well, it is pretty similar to what you suggested just with more empise on "open" source. :)

Official OJP website

I really like your idea. However, doing website design/updates/etc isn't my cup of tea. We will have to find someone who is willing to do that stuff.

1. To use OJP code, you must contribute something 'of worth' to the project.

Now, this is where you and I disagree on things. I think we need to have some system in place to allow newbies and people who aren't planning on contributing to view the code.

I suggest that we meet in the middle on this and allow people (who aren't on our blacklist) to view the code (and keep track of that). However, to USE the code in a publically released mod, you have to follow OJP rules and contribute any desireable features into OJP. It's concievable that there could be a mod that was unique, significantly different, and DOESN'T have anything that could be contributed to OJP.

Due to way freepository works, you need a password to join a "public" project. As such, we could keep detailed records of who accessed the code and why.

I would suggest a small number of leaders who hopefully can deal with most stuff, but if the leaders do anything which the majority of contributors don't agree with, their desisions can be over-ruled by majority vote.

Great idea, I suggest we do that.

2. If contributing features clash in some way, they need to be standardised

Agreed.

3. Mods using features from the OJP cannot 'significantly' alter the used features.

Mmm, you're going to have to explain the purpose of this one to me. I can understand requiring people to contribute bug fixes but I'm not really clear what you're getting at with this one.

4. Mods made from OJP code must clearly state (somewhere) that they are OJP mods

Agreed. I suggest we have a OJPcredits.txt included with the OJP code to make it easy to properly credit people.

In addition, any features that come from OJP should be specifically credited as such in the mod AND IN ANY PUBLIC RELATION MATERIALS (unless you specifically created that feature). This will prevent a situation where someone with a popular mod will get "the credit" for features that he didn't make (JediMod <-> OmniMod/JediMod++/JediPlus)

5. Any mod built from the OJP must be 'substantially' different from other OJP mods

Agreed.

Sorry about the long post, but I felt it was nessesary to get across what I'm proposing.

As long as you're covering new territory with your long posts, that's completely acceptable....Well, that's assuming that it's readable. :)

I'm going to suggest some additional rules:

1. Before releasing a OJP mod version publically, you need to clear your mod with the OJP leadership.

This is to ensure that your mod is in compliance with OJP rules. This needs to be as convenent as possible for modders so we don't scare people off with this requirement.

2. OJP-based mods must include the required OJP files.

The required files would include a OJP credits text file and a OJP readme that includes the rules, the blacklist, and a introduction of the project.

I'm going to start working on those files now.

RenegadeOfPhunk
09-23-2003, 07:16 AM
Hey - thx for listening to my ideas Razor - this is great :)
To be honest, if it wasn't for the possibility of OJP, I probably wouldn't even be considering modding for JA...


I suggest that we meet in the middle on this and allow people (who aren't on our blacklist) to view the code (and keep track of that). However, to USE the code in a publically released mod, you have to follow OJP rules and contribute any desireable features into OJP. It's concievable that there could be a mod that was unique, significantly different, and DOESN'T have anything that could be contributed to OJP.


Hmmmmm - yes, I see.
I think you have a good point. Even just from a practical context - if contributors can't see the code until they have contributed, that would mean that members of the OJP would have to merge in new code! Or we could have some kind of system where the appplicants show us the working feature(s) before we give them access to the OJP...
...but this produces extra work and hassle - so I agree, let's principly give anybody access to the source.

And as you say, if we give out permissions, we can avoid people who are known to be a problem. (Although we must be fair about this - we'd have to be careful about denying someone access I think).

The only thing that worries me a bit is the idea that people could quite easily take OJP code, slightly change it to make it look like it was original work (or at least claim any similarities are co-incidence) and essentially claim it for their own.

Sure, we would have a record of all people who have accessed the OJP, but people can always use more then one persona on the internet can't they... At least forcing people to contribute first makes this much harder to happen.

But I guess we'll see how it goes...



3. Mods using features from the OJP cannot 'significantly' alter the used features.

Mmm, you're going to have to explain the purpose of this one to me. I can understand requiring people to contribute bug fixes but I'm not really clear what you're getting at with this one.


Hmmm - yeah, maybe this is not a practical rule to enforce at the end of the day - and possibly not nessesary. This was a rule meant to stop mod fragmentation, but since we already have the rule about no copy-cat mods, maybe the above rule is one too far.

Basically, I was thinking along these lines:
'If you have used a feature from the OJP and improved on it, you should put those improvements back into the OJP, since that is where you got it from in the first place...'

But maybe this isn't nessesary thinking about it - and could actually stifle progress. Maybe it would be better if we forget that one!


1. Before releasing a OJP mod version publically, you need to clear your mod with the OJP leadership.

This is to ensure that your mod is in compliance with OJP rules. This needs to be as convenent as possible for modders so we don't scare people off with this requirement.


Agreed. I think people should be able to 'submit' mods as early as possible - even before they start coding infact. Because at the end of the day, I can't think of anything worse than slaving away on a mod for a few months only to be told at the end of it, or near the end, that I can't release it because I didn't think of mod X or Y! Hell, I'd probably put two fingers up and release it anyway in that case!

So I think people should be able to pitch their mod as early as possible. And then assuming they don't deviate massively by the end of development (or any deviation doesn't cause it to become a copy-cat mod), then any changes are acceptable.

And we'd need to be quite organised about this. If we appprove mod X, but then find out that mod Y is starting to look a lot like mod X a couple of months down the line, we may need to take steps etc.


2. OJP-based mods must include the required OJP files.

The required files would include a OJP credits text file and a OJP readme that includes the rules, the blacklist, and a introduction of the project.


Yeap - sounds good.

I'm willing to perform any admin duties that need performing - I'd really like to see this get off the ground.

...OK - so who's up for webbie duty? :)

Renegade

RenegadeOfPhunk
09-23-2003, 08:28 AM
About the website:

There are always quite a few modding sites that spring up for a game. I'd say the OJP site is basically a special type of modding site. i.e. we don't need to restrict it to just OJP business. We could have all kinds on there - mod reviews, forums etc. etc.

Basically, since your garuanteed visitation by a hell of a lot of coders, I could easiely see the OJP site becoming the central site for JA modding. I'm sure that we could find some web guy who'd be interested in working on such a potentially high profile site...
...how about the nice people at jediknight.net? :)


I just think a big, central, well presented website is VERY important to make sure that the 'credit where credit is due' requirement is met:

Player 1: 'Isn't feature X cool? 'Modder Y' did a great job on that eh?'

Player 2: 'Err, no. Actually it was 'Modder Z' who made that feature. It just got included in Modder Ys mod'

Player 1: 'That's not what I heard...'

Player 2: 'Well, I can prove it to you'

Player 2 gives Player 1 a link to the OJP site where it says - officially - who was responsible for what. Argument over. No ambiguity.

razorace
09-23-2003, 09:55 AM
The only thing that worries me a bit is the idea that people could quite easily take OJP code, slightly change it to make it look like it was original work (or at least claim any similarities are co-incidence) and essentially claim it for their own.

Sure, we would have a record of all people who have accessed the OJP, but people can always use more then one persona on the internet can't they... At least forcing people to contribute first makes this much harder to happen.
True, but I have some countermeasures planned. That comboed with our records should hopefully give us enough to ward off the code whores.

Of course, I can't talk about the countermeasures on a open channel like this. :)

Basically, I was thinking along these lines:
'If you have used a feature from the OJP and improved on it, you should put those improvements back into the OJP, since that is where you got it from in the first place...'
Ok, that makes more sense. I've added that to the rules draft.

And we'd need to be quite organised about this. If we appprove mod X, but then find out that mod Y is starting to look a lot like mod X a couple of months down the line, we may need to take steps etc.

Agreed.

I'm willing to perform any admin duties that need performing - I'd really like to see this get off the ground.
I suppose you could ask the jediknight.net dudes (and others) if they want to be involved. I kind of have my plate full with the rules draft, the repository, and the possible features list. :)

While you're at it, ask them if they could host a forum here for the project. This thing is going to be too big for a single thread soon.

Emon's checking out server options.

Things are looking up. I've gotten multiple people either interested or at least willing to contribute to the project. :)

I've got a draft of the readme and rules set up. Want me to post it so you can work it over?

As for OJP moderators, it looks like me, you, and Emon are probably going to be the starting moderators.

Anyway, that's all for today. Sorry if I'm hard to understand. I'm tired.

Goodnight!

RenegadeOfPhunk
09-23-2003, 10:06 AM
Great stuff Razor - I'm in :)

I'll talk to some people and see what I can do about getting a site and forums up...

And sure - post up an initial rules draft when you are ready...

Wudan
09-23-2003, 01:53 PM
1. Rules Scare People. I'm basing it off of the fact that I'm scared by rules.

2. Maybe just 2 rules - proper credits of the latest version of OJPsource available at the OJP site included with your mod, and no mods released using OJP without contributing to OJP. I don't think OJP's 'grand vizier' or whatever needs to sniff and hug each OJP released mod. I think the key focus should be on encouraged contribution.

3. Last, a source recommendation - each new added feature has a run down and sig comments "//Wudan - " with info - I'd think it extra special if the bulk of new features were in extra source files, as opposed to cluttering up existing source files. I understand that a certain degree of integration is necessary, but it should be kept to a minimum, so many features can be added without the source getting uber confusing.

RenegadeOfPhunk
09-23-2003, 02:10 PM
I know what your saying man, but rules aren't here to scare people - they are here to make it very clear what were doing.

To just say 'Make it fair' is just not specific enough. One person's definition of fair is not another persons. And we can't use everyone's definition at once, so we have to come up with a common set of rules.

A good example of this are the rules which govern these forums. There are actually quite extensive rules governing what you can and can't post here. And there are eager admins on the prowl ready to enforce these rules...!
Is this a bad thing? Most people certainly aren't 'scared' by these rules - they accept them as part and parcel of posting on a forum.

...for my part, I don't actually read every single word of the rules of these forums. (Yes, I am BAD!) I get the basic jist though - don't be a jerk!
But they can't just say 'Don't be a jerk!' in the forum rules! They have to be MUCH more specific than that. They have to be able to refer to a specific section of the rules which covers that particular part of 'jerk-like' behaviour for specific cases...

Same with OJP. The rules aren't something to be used like a whip whenever you feel like being vindictive. It just makes it perfectly clear what were doing.

It may seem rules will stifle the open nature of things. But really, I think the opposite will happen. A firm set of fair and agreed rules will allow many people to contribute freely and not be worried about how their work could be (potentially) exploited.


As far as the specific issues you've raised about the rules, sounds like your biggest beef is with this one:


5. Any mod built from the OJP must be 'substantially' different from other OJP mods


OK, let's take a theorietical situation. The OJP is fairly mature and there a lots of good features in the 'library'.

Modder X comes along, takes all the features, adds a few new emotes and calls it 'X's super mod'. (Prefectly legal without the above rule)

Modder Y comes along, takes all the same features, adds a few new saber colours and calls it 'Y's super-duper mod' (Perfectly legal without the above rule)

Modder Z comes along, takes all the features, changes some #defines for weapon bullet speeds and calls it 'Z's woppie-de-doo mod'. (Prefectly legal without the above rule)

...do you see this as an acceptable situation? This is not a problem of giving credit where it is due (we'll assume they are following all the other rules), the problem is we now have 3 OJP mods which are so similar, I would have no problem with saying that they dont' really deserve to be seperate mods. The new emotes, the new saber colours and the new weapon speeds should be cvars in the same mod.

I think this makes sense to most people, and the above example is a little OTT to illustrate the point, but this is exactly what the rule is meant to combat. I actually think most people will take this as a given using common sense - so hopefully we would rarely even need to enforce it - but it needs to be there non-the-less.

..and remember, ALL contributors have a say in this...


I think I need to clarify something here - the new emotes, new saber colours and new bullet speeds wouldn't be the contributions that got X, Y and Z membership in the first place. (Or at least i seriously doubt these would count as good enough - individually at least. The ability to add saber colours would count though I guess...)

X, Y and Z have already contributed 'satisfactory' features to the OJP before, which means they get to release mods which take advantage of OJP source.

Now, you can argue that X, Y and Z, being decent coders to get in in the first place - would not try and make such mods. They would have no problem adding these minor things as cvars into the main OJP.

In which case, great! This makes it even LESS likely we would ever need to enforce the rule. But the above situation is still potentially possible, which means we still need the rule defined...

razorace
09-23-2003, 09:24 PM
I agree with Phunk on this. While rules can scary people off, we need to have rules in place to make it clear what is and isn't acceptable.

The people's view of what is acceptable varies wildly. For example, I actually talked to the person known as BOFH about this. He seems to be under the impression that any modding work is automatically the property of LEC after release (due to the crappy EULA) and therefore giving credit to other modders is a matter of personal opinion. This means that if you get on his bad side, he thinks it's "ok" to remove any "credit" from his derivative mod.

Everyone that is working on OJP disagrees with this rational and have to make rules that make this very clear.

For those comments and for a varity of other reasons, I've already put him on the OJP Blacklist.

razorace
09-23-2003, 11:37 PM
------------------
OJP Rules Handbook
------------------


Version: 0.1




=================
Table of Contents
=================

0001 - What's New?
0002 - Introduction
0003 - Decision Making
0004 - Getting Access
0005 - Usage
0006 - Smacktard Open License
0007 - The Blacklist


==================
0001 - What's New?
==================

0.1:
The rules handbook is born!



===================
0002 - Introduction
===================

OJP is here for the community. Our primary goal is to provide a feature platform for JKA mods that insures that every creator is given full and proper credit for our work.

We operate on a "semi-open" source system. We try to allow as many people as possible to access our work and contribute. However, since there are a lot of people that can't play nicely or respect the works of others, we have some strict rules to keep everything fun and helpful for everyone.

We're looking for, and accept, interesting and well done features that the modding community in general would be interested in. Work must be done in a clear, understandable manner and documented to a reasonable degree.

The only things we can't accept are pure maps and models. They take up too much space and would make it difficult for our dial up users to easily and quickly download project files. However, we take especially well done graphically work (like a far superior saber blade effect graphic) or models that have technical uses (like an improved hit collision player model). If you are unsure on whither your work is acceptable or not, just ask one of the moderators.

To prevent major complications, we can't allow anyone to "desubmit" work after it has been integrated into the project. Otherwise, we'd have to spend insane amounts of time removing features that disgruntled contributors want removed. This is a requirement for ALL submissions so please keep that in mind before submitting.

This doesn't mean that you surrender your rights to your work. We consider your work to BE your work. We will continue to respect your work whither you continue to be a part of the project or not. We will make every effort to protect your work from smacktards and illegal commercial exploitation.



======================
0003 - Decision Making
======================

While we do accept input from the community, we can't allow the community to out voice the contributors. As such, OJP is run by a group of moderators that volunteer their time for the cause. Since most people don't want to be involved in the day-to-day running of the project, the moderators regularly vote on and handle issues. A simple majority rules here.

If there is something that the project contributors don't agree with, they can overrule the moderators by a supermajority vote.



=====================
0004 - Getting Access
=====================

To keep out the undesirables and to protect our work, we require everyone to ask for access to the OJP source code. To get access, simply send an email with the following information to one of the moderators:

- Name
- Any aliases/nicks/handles you use.
- Reason for wanting to access the code
- Previous modding works
- Features you might contribute to the project

Please be honest as possible. If we find out that you intentionally lied to get access, we will ban you.



=============
0005 - Usage
=============

You are allowed to:

- Analysis OJP works to learn how things operate.
- Use our code in your mod IF you follow the SOL (Smacktard Open

License)

You are NOT allowed to:

- Distribute OJP source works.
- Financially profit from OJP source works in ANY way.
- Cut and paste code without following the SOL.

We are pretty strict about the usage of our source work to create new works. For anything that is released publicly, you have to comply with the SOL (Smacktard Open License) or clear it with OJP moderators.


=============================
0006 - Smacktard Open License
=============================

To correctly use OJP works or derivatives you MUST do the following:

- Get your work approved by to one of the moderators BEFORE you release it. Please email ahead before you send large files thru email. Thank you.

- Include the two main OJP files with your work. This means this file (OJP_rules.txt) and the readme (OJP_readme.txt)

- Make it clear that your work is OJP based work in and OUTSIDE the mod. Talking about an OJP feature in a forum as if you created it is unacceptable.

- Submit any community useable features to the project. OJP's success depends on users taking AND giving to the project.

- Any bug fixes or improvements to OJP code should be submitted back to the project.

- Your mod MUST be significantly unique to be releasable. Simply adding a couple of cvars and emots IS NOT ALLOWED. If you have a project that is very similar to another project, try cooperating with that project.

- Thou Shall Not Take OJP's Name in Vain. Meaning, for the love of god, don't name your mod something like OJP+++ or OJP v2.0. WE WILL hurt you.


If you don't follow these guidelines, we may be forced to take actions to prevent abuses of our works. These actions might include:

- Getting your work removed from download sites.
- Removing your submission privileges.
- Banning you from the project and putting you on the Blacklist.
- Legal Action.

We suggest to you keep in constant communication with OJP to allow everyone to coordinate their projects. We don't want you to waste months of hard work to find out that your mod is exactly like ____'s mod.



====================
0007 - The Blacklist
====================

All of the following individuals have violated one or more of the OJP rules (or simply cheesed us off) and are not allowed to use or view the OJP source code/materials. Intentionally giving OJP source code/materials to these individuals will result in you being added to the blacklist.


BOFH/Spectrum - Banned for not giving proper credit to coders in the community, changing handles to avoid retribution, abusing file master privileges to hype own mod, and using backstabbing tactics to acquire modding material.

RenegadeOfPhunk
09-24-2003, 12:18 PM
The doc looks good Razor. It covers everything and it makes things very clear - good job!

The only critisism I have is that some parts could be worded a little less aggressively - although in most cases it's OK.

But this bit I think should be taken out:

(or simply cheesed us off)

It gives the impression were going to exclude people from the project if they even look at us the wrong way!

Sure - their may be a situation where we need to ban somebody if nessesary, but I'd like to think this would be the last course of action - after trying to discuss any problems and seeing if there are other ways we could sort it out first.

...and we certainly couldn't ban somebody just because we didnt' like them!

But apart from that, it's all good.

razorace
09-24-2003, 01:12 PM
Noted, feel free to make changes and post them or email them to me.

Scarlett
09-24-2003, 03:07 PM
I don't really have any input to give as to how this whole thing works (right now anway).... but i think it's a great idea. I'd love to contribute to this. Razor suggested i dontate my effects work to it, so i'll do that. I'd also like to work on material specific effects and entity collision sounds and stuff like that... mostly astetic related. Most people would probably think my gameplay and interface ideas are a bit extreme... so i don't know about those. ;)

RenegadeOfPhunk
09-24-2003, 03:33 PM
Well - this is the good thing about the OJP Scarlett.
If you've contributed some good and worthwhile stuff to the OJP, then you get to become a member who can potentially 'produce' an OJP mod.

(I think the term 'produce an OJP mod' is the best way to describe the process. It's better than just 'making a mod' - this sounds like your making it all yourself from scratch...)

Of course you must follow the rules - most importantly giving full credit for the features you use.

Your game ideas may be 'extreme', but as long as they were original and not a copy-cat, then that's fine. You are free to try and make a good, unique game which adds to the OJP 'range' of mods...

reaper1576
09-24-2003, 10:11 PM
shaping up realy nice razor nice work

razorace
09-24-2003, 11:14 PM
Thanks Reaper, but I have had some help. :)

Scarlett
09-25-2003, 12:13 AM
If you've contributed some good and worthwhile stuff to the OJP, then you get to become a member who can potentially 'produce' an OJP mod.
I'm not interested in "producing" a mod based on this, i'm working on my own. I was just wanting to contribute some of the things i've done into the offical OJP base project is all.... i don't know where you got all those ideas about my intentions from...

razorace
09-25-2003, 05:47 AM
Originally posted by Scarlett
I'm not interested in "producing" a mod based on this, i'm working on my own. I was just wanting to contribute some of the things i've done into the offical OJP base project is all.... i don't know where you got all those ideas about my intentions from...

Uh, fair enough. I'm sorry if I made that sound differently.

I've got several issues that I'm going to put into the next version of the rule handbook:

1. We need to say something about the fact that this is technically applied on top of Raven's code. Basically, something about the way the OJP rules ONLY apply to the works created by OJP contributers. We're simply distroing parts of the Raven code for simplicity. We have every respect for Raven/LEC's rights to their works.

2. Remove the charges of "not giving proper credit to coders in the community" and "changing handles to avoid retribution" since I don't really have direct evidence to back that stuff up. I'll also reword the charges. The ban still stay however.

3. Add a section about the process to submit features to the project.

RenegadeOfPhunk
09-25-2003, 06:26 AM
i don't know where you got all those ideas about my intentions from...


OK - my mistake.
...I was only speaking hypothetically anyway, just to underline the possibilities.

Whatever you could contribute would be great :)


About your points Razor, agreed to all.

I've sent out some messages to a few people about website and forums - hopefully we'll hear something back soon.

AV4T4R
09-25-2003, 11:01 AM
Hi guys.. really interesting ideas!

Renegade it's 1 mounth i'm searchingfor you .. eheh can u cnotact me in some way?

icq :35433605

i need to speak with you for a couple of things ( related and not-related to JK )

Emon
09-26-2003, 02:34 AM
Those rules aren't as necessary as you think. You'll be scaring people with them. The only reason BOFH was able to "steal" JediMod was because Dest stopped producing it, and because it directly affected end users, getting him fame, which he probably wanted. If someone rips off OJP, whoopdee ****ing doo, no one's going to use it, it's blatantly a rip off, why steer away from the accepted standard? When's the last time you saw someone rip off an open source library for C or C++ like libpng or libjpg? Exactly. They'd get no fame, they wouldn't have any reason to do it. And developers in particular understand the importance of mainstream. I wouldn't start using some jackass' OJPOmni++ 2.5 because he thinks it's better. Source should be available to all, you shouldn't need to e-mail us to get it. That hinders development and scares people away, I know it would for me.


I think there should only be two ways to participate in coding. First is having CVS access, unrestricted, this is for the full time contributors. A listing of current tasks should be kept up to date on a website or sticky thread in a forum. If you keep access unrestricted, it allows anyone to modify anything that isn't being worked on. It would suck to have to go to an administrator and let him chmod a directory or something so you can access it.

The second is submitting patches. Another reason to keep public CVS wide open. A lot of people aren't going to want to join the team, only submit a patch or two. Just about a month ago, a guy I was talking to about window managers for Linux made and submitted a window snapping patch for Fluxbox in about an hour. He submitted it, made it free for download, and then the developers either chose to accept it or reject it some other time. I think that's exactly how OJP should work. Anyone can download the CVS and make any patches they want, and put them up anywhere they want, of course that would all be unofficial, we would have to accept it and add it to the code if we wanted. Now you're probably thinking someone's going to take advantage of this and try to steal some fame or some crap like that, but, as a developer, would you start using patches rejected by the official team? Anything good we will accept, but people should be allowed to do what they want with it, unless they're selling it or something.

Anyways, that's my rant. I'm basically trying to point out that adding rules and restrictions will slow development. People are scared away by that sort of thing. Especially now, when we are starting out, we'll be seen with the attitude of, "Heh, they want me to ask for permission? Who do they think they are??" Quite frankly, we're like nobodys now, we are in no position to be restricting those who want to help us.

razorace
09-26-2003, 04:37 AM
Well, Emon has a point as well.

It's really just a matter of how worried you guys are about people using your works, with or without credit, and whither you want to try to help the community out with the similarity clause. But if you're not willing to have additional rules, the chance of people abusing the project is higher.

I'm basically fine with full open as long as people don't use my works commerically. However, I think the similarity clause would help things quite a bit.

I'll go with whatever the majority wants. :)

However, I'm against the task list concept. While I am recording a list of possible fixes, additions, etc, I've found from experience that people will NOT do anything if you give them a task to complete. I have no problem with simply having a "suggestions" list but anything beyond that WILL NOT WORK. The only way things get done in the modding community is when people are directly interested in doing it.

RenegadeOfPhunk
09-26-2003, 09:08 AM
At the end of the day - the OJP is run by majority. We have a pretty good idea who the initial contributors are going to be. So let's see what everyone else thinks. If most people don't want any kind of rules for mods built off the OJP, then I'll go along with that.
I'll state that I think it's potentially a bad idea, but I'm happy to go with the majority on this one...

i.e. I would rather have an OJP which had no rules and some risk involved than have no OJP at all because no-one could live with any rules...!


I think it's fine to make the OJP source available to all without some kind of 'request' e-mail. That makes practical sense as well.
(btw though, with our old proposed system, once you had access - I believe that meant FULL access. I don't believe we were proposing people had to re-request every time that wanted to look at a particular file!)

But I still think some kind of 'rules', for building completely new mods from OJP source are worth-while having.


When's the last time you saw someone rip off an open source library for C or C++ like libpng or libjpg?


While I'm not exactly sure what those library's are about, I'm guessing they are meant for professional software development. Well, were in a different position because were not in the professional development arena. And so saying no-one has ripped off these libraries is not a direct analogy between what might happen to the OJP.
I agree, it would make no sense for a professional to 'rip-off' open source code. Their not coding for fame - their getting paid to do a job...

The fact is were talking about modding for a computer game - there is a different spectrum of mentality. The incident you mentioned above is a clear example of this. (I'm a bit confused by the fact you seem to have stated a clear example of abuse of open source which is known to have happenned, and then said 'So let's not have any rules this time round'?!)

Will it slow down development? Ermm, potentially I guess it might do - a small bit in some cases. I guess I have to give you that one. But I'd say it's worth it - when the alternative is what happenned before.

Will it scare off people? Were you scared to post on this forum because there were some rules that go along with that activity?

Will people freely contribute to the OJP with NO safe-guards in place against using the code without credit, or suddenly 10 copy-cat's of their mod popping up?

Patches are something different - these are not affected by the rules for building new mods. In fact, as far as patches I would say no hard and fast rules at all. I think maybe we want to be sure that the patch is actually an improvement of somekind to the game - maybe have a coding standard (but I think the admins would have to possibly accept a little bit of code 'clean-up' duty) - but apart from that - anything goes I'd say. Let's let anybody contribute whatever they like. The more, the merrier.

But I think building a new mod off the OJP source is a different story...


Quite frankly, we're like nobodys now, we are in no position to be restricting those who want to help us.


This is looking at things backwards. The rules were proposing should be benifical to all - not just the people who happen to admin it.
And we wouldn't be restricting anybody who wanted to help us. At least that wouldn't be the intention - if we did restrict people who wanted to help, then that would be our fault.
The intention would be to restrict those who want to abuse the open nature of development...

t3rr0r
09-26-2003, 11:41 AM
guys, not sure if you know about this, but you may want to take a look... http://pcgamemods.com/2309/

RenegadeOfPhunk
09-26-2003, 01:05 PM
Haha
:D

Well, that IS funny!!

...co-incidence?!
(Anybody know this guy?)

t3rr0r
09-26-2003, 02:20 PM
they're only saber hilts, too...

and judging by the date, it is probably safe to assume it is not a coincidence.

RenegadeOfPhunk
09-26-2003, 02:39 PM
If it IS a co-incidence, (it's a bit unlikely, but it's possible after all) then fair enough. It's not a problem, we'll work something out.

If it's NOT a co-incidence though, well, I rest my case on the maturity of some modders... :rolleyes:

I think we need to talk to him first though.
(Who knows - maybe he was just trying to get the ball rolling, in an unorganised kind of way!)

I'll leave a quick comment when I get home...

bliv
09-26-2003, 05:30 PM
http://www.lucasforums.com/showthread.php?s=&threadid=112195

Not really wanting to point the finger at anyone but if you scroll down that thread a little you can probably work out what I think.

Azymn
09-26-2003, 07:11 PM
I agree with what I think bliv thinks.

razorace
09-26-2003, 07:11 PM
I've sent the following to the dude. I've also contacted the major file servers about the issue. I haven't ask them to remove the files yet as I want to hear this dude's side of the story first. No need to take forceful action if it was just a honest mistake.

Hello,

We've just noticed that you've posted a mod with the name OJP (Open Jedi Project).

We have been using this name for sometime now. We don't want to cause problems with duplicate mod names and we'd like to hear your side of the story. However, we have proof that we've been using this name for sometime now and are willing to take this evidence to all the major file servers if we find that you're just attempting to steal/slam our name. Please contact me ASAP.

Thanks,
Razor Ace

Emon
09-26-2003, 09:39 PM
Originally posted by razorace
It's really just a matter of how worried you guys are about people using your works, with or without credit, and whither you want to try to help the community out with the similarity clause. But if you're not willing to have additional rules, the chance of people abusing the project is higher.

I'm basically fine with full open as long as people don't use my works commerically. However, I think the similarity clause would help things quite a bit.

However, I'm against the task list concept. While I am recording a list of possible fixes, additions, etc, I've found from experience that people will NOT do anything if you give them a task to complete. I have no problem with simply having a "suggestions" list but anything beyond that WILL NOT WORK. The only way things get done in the modding community is when people are directly interested in doing it.

1. If someone rips it off, just get the mod sites to take it down. Any decent administrator is smart enough to see something like that, and to avoid a legal mess, they'll probably comply.

2. They couldn't use it commercially because the EULA prohibits commercial use of any mod. The only way is if someone bought a Q3 engine license and somehow got our code in there, but that's like impossible.

3. No, I don't mean assigned tasks, I mean just keep a list of what people are doing on a forum or website so that other people don't go mucking around in it by accident. Like bob12435 can be like, "hey guys I'm going to do some new physics thing" and then it gets posted on the forum so no one else mucks with his files.

RenegadeOfPhunk, libpng and libjpg are exactly what they sound like, libraries for loading PNG and JPEG files. They're completely open for any kind of software development.

I understand there's a different mentality (and what examle were you talking about where I said it was abused??), but still, think about it. This is a very large project with a lot of developers. It's the first. If someone wants to rip us off, let them try. Everyone's going to know it's a ripoff, so no one's going to use it. I sure as ****ing hell wouldn't take some dumbasses modifications from like the GTK and use them in my software, I want the real thing, and I know everyone else who's a decent developer would too.

I'm not sure what to think of that guy's hilt pack, but from his posts, he just sounds confused.


My basic thought is that rules are going to scare people away. Public CVS access is a must. If anyone tries to steal it from us, let them try, we will just smite them. Let's assume our path is rather rocky, so let's say it will happen. But how many times can it happen? Once? Twice? Over the course of (hopefully) many years? That doesn't sound very threatening, nor does "omgom guys I maed teh ojp-- mod it r lek teh ojp but I changed teh menuz!", etc. If it becomes a serious problem, then we can take action, but right now we are in no position to be making demands of developers who want to use our stuff or contribute.


Edit: Also to support my belief that this is not a problem, look at GtkRadiant and Q3Map2. They both have the source code readily available, there has never been a problem. If some jackass ripped it, called it OmniGtkRadiant or something, would you use it? No, of course you wouldn't, same with Q3Map2. People want reliable stuff, not some immitation crap.

RenegadeOfPhunk
09-26-2003, 10:57 PM
Everyone's going to know it's a ripoff, so no one's going to use it. I sure as ****ing hell wouldn't take some dumbasses modifications from like the GTK and use them in my software, I want the real thing, and I know everyone else who's a decent developer would too.


Hmmm. It's possible were getting crossed wires here Emon. When you refer to the 'rip-off', sounds like to me your refering to a different open source project who rips off our code and then hands that out to other mod makers (?). If so, that's not what I'm talking about.

...I'm talking about someone taking OJP code, claiming it as their own and making their own mod out of it, changing enough of it so that many people are fooled into thinking it's original work and then releasing that mod to the public, without any recognition to the original authors.

In this case, it's not developers (decent or otherwise) who are being presented with a 'rip-off', it's the gamers themselves.

Can this happen? YES - it HAS happenned. You've already mentioned the 'incident', and I don't want to mention it directly again (because that's when things start to get heated up around here - which CLEARLY shows it was indeed quite a BIG problem).



1. If someone rips it off, just get the mod sites to take it down. Any decent administrator is smart enough to see something like that, and to avoid a legal mess, they'll probably comply.



I think it's easier to get the guidelines clear right from the start, rather than having to write to every single mod site and tell them to start ripping files down.

Why not try and stop those files getting put up in the first place?!
OK - you may argue there is little we can do about it if somebody wants to do this - especially if we want it to be as open as possible. And yes, you may be right. But why not at least make it very clear this is against our 'rules' (and when I say OUR, I mean ALL contributors, not just a handful of 'high-and-mighty' admins), and if you do this, were going to take steps. If we do make this clear, it is possibe they may not try to begin with, saving not only us, but the mod site admins a whole load of grief we and they don't want!



look at GtkRadiant and Q3Map2. They both have the source code readily available, there has never been a problem.


I am almost certain the code for these programs will come under the GPL - which the Quake I and II engine open source code are also under.
Check here (http://www.gnu.org/copyleft/gpl.html) for the 'rules' of that license.

(I did try and find out for sure whether this was the case directly, but half the links I found to try and get more details about gtkradiant and Q3Map2 weren't working - so I gave up!
But put it this way - I don't know of ANY 'professional' open source code which DOESN'T include some kind of licence similar to the GPL...)

If you know better in these specific cases you've mentioned, then by all means post a link and I'll happily take it back. But I'd be very surprised if you do...

Look, I'm not trying to say we should be like ultra-professionals - just for the sake of it. I know this is just a mod were working on. I don't see this as legal stuff. Because at the end of the day (I know Razor disagrees with me), I don't think taking legal action over mods is either practical or justified.

...these 'rules' were talking about - as far as I'm concerned - are just about:

a. A certain level of common cortosey and respect

b. Reassuring people that if they contribute, the OJP will do whatever it can to make sure they will get the appropiate credit whenever their feature is used / played.

c. Try and stop copy-cat mods appearing all over the place.

Now the copycat mod thing - possibly - is the least important out of the three. But still - why not try and stop this? Basically, if you've made a realtively minor change or addition, please don't go and make a whole new mod.
Instead, please just add it back into the OJP.

...is that really SO much to ask?

Emon
09-26-2003, 11:22 PM
Whoa! Okay, hold up, you didn't have to type more than the first few lines. I understand what you are talking about now. I thought you meant a duplicate of OJP, not someone claiming the code as theirs.

This is really easy to fix. In our license agreement, which we can put on our site or on our CVS thing, we just say that if you use code without credit, we can take legal action. The only other thing I can see to stop this is to limit distribution of the source code, which may severely hurt the development of the project, and like I said, scare people away, and would also seem kind of elitist I think, and demanding.

If someone still tries to dick with us, well, there isn't much we can do, other than talk to the mod sites to get them to take the stuff down. If we wanted to threaten with legal action or something, any mod site not run on Geocities is going to comply.

RenegadeOfPhunk
09-26-2003, 11:29 PM
This is really easy to fix. In our license agreement, which we can put on our site or on our CVS thing, we just say that if you use code without credit, we can take legal action.


This is all Razor and myself have been saying from the beginning! Well, I'll let Razor speak for himself. I know that's what I meant at least...

I'd thought I(we) had made ourselves pretty clear too... :confused:

(Although I still think legal action is a little over-the-top, but whatever).

Oh well, at least were all on the same page now :)

Emon
09-27-2003, 02:31 AM
Oops! :o

I'll start work on a small website.

razorace
09-27-2003, 02:32 AM
The problem is, simply telling people to give "proper credit" isn't going to work. A lot of the problems with "the incident" was that there was credit given but it wasn't enough to prevent glory hogging.

If you think credit hogging is more acceptable than some useage rules, that's fine. But we're going to have to accept the conceqences either way.

Personally, I'd rather error on the side of caution and only have the cream of the crop material (since those are probably the only people able/willing to submit) rather than have to suck it up when people totally abuse my work.

Besides, I don't feel like having to babysit crappy modders when they submit code that is in no shape to be intergrated into the project.

Emon
09-27-2003, 02:36 AM
And the only other option is limited source code distribution, which I am strongly against.

Please correct me if I am mistaken, but BOFH actually did credit a lot of the code he used. And besides, this is one guy, it's not worth it to drag everything down because something like that might happen again. And did those who got the code stolen ever bother to contact sites to get it removed, or did they just flame BOFH in the forums, because I seem to remember that.

razorace
09-27-2003, 02:45 AM
I'm not for limited source code distrobution either.

However, I have no problems with us denying access to known troublemakers. And the only way to do that is to require everyone to contact us before giving out the password. With the repository I got set up, I have to pass out a password to the repository anyway.

Emon
09-27-2003, 02:51 AM
What's to stop someone from contacting you under an alternate alias? It's not going to work. If someone wants the source code, they are going to get it.

razorace
09-27-2003, 04:27 AM
True, but there's nothing wrong with at least trying to keep them out. If we keep records and find out that a banned individual has gotten the code, we might be able to track it back to whoever did it. Plus, we could act immediately against the banned individual instead of having to try to be "fair".

EDIT: Plus, we can do additional things like knowing who's using our code legally and so on.

Any luck with sourceforge?

Emon
09-27-2003, 04:40 AM
No, that won't matter. You cannot prevent someone from getting the code if they want it. It's much easier and more effective to just get the crap taken down, this is going to hinder development for legit coders. Especially when you want to take all these precautions because of one guy who, at least I haven't seen in many ages. Are you trying to inflate his ego or what? We should let it go and not be intimidated by idiots.

SourceForge hasn't replied, but I can try a few other places.

razorace
09-27-2003, 05:54 AM
How's it going to hinder legit developers? All you gotta do is email one of the moderators and tell them who you are and why you want access. If they're too lazy to do that, they're going to be too lazy to configure their copy of CVS to access the repository or too lazy to pimp their code up to an acceptable level anyway.

On the useage side of things, the rules I've suggested have two main purposes:

1. To help ensure the rights (and credit) of the modders to their work. A lot of people are very concerned about this. If strict rules are the difference between people contributing and not contributing, we need to have the rules in place.

2. To hopefully limit the widespread of "me too" mods that hurt the JK2 community.

If we're not too concerned about either of the two, that's fine. We need to do whatever is the most likely to get good modders to pretipate. I think that the good modders need to feel that their code is going to be properly creditted than allowing super free access.

Scarlett
09-27-2003, 06:39 AM
Just some input:

About the whole credit issue. I think we shouldn't be so egotistical about it... i say screw it. Sure a credits list for the project is desirable, but if someone uses our work i don't think we should be so insistant on them giving their sources away. Sure it's ideal, and we should request that it be done, but honestly not everyone's going to do it no matter what you say. Hopefully when this thing takes off it'll be really popular and thus, if someone takes code from OJP and uses it in their mod people are just going to know where it came from anyway.

And about how open the source code is... i think it should be fully open. Downloadable from the website, and up to date with the latest build that's been released. I really can't see it any other way. As Emon has been saying, i really think that could potentially slow down production too.

Also, maybe this has already been figured out, but this is how i was thinking the whole source code updating process would be handled:

[list=1]
The client sends a moderator an email with the source code that they're wanting to contibute to the project
Then the update will have to be offically accepted
If it is accepted, it'll be added to the base project as a new update (by a moderator)
Then a beta test will be sent back to the client, for them to test it out to make sure it was implimented properly
The client will then have to reply, confirming this
Then the new build is released to the public
[/list=1]

razorace
09-27-2003, 08:52 AM
That seems fair.

That's one vote for "screw it. Open Source TO THE EXTR3M3!!!!".

I'm undecided. I just want to do whatever most people can get behind.

RenegadeOfPhunk
09-27-2003, 09:54 AM
Well, to me it seems most people are saying:

a. Rules are scaring a load of us

b. Some don't think the rules can actually be 'enforced' that easiely anyway in the first place.

I think a. is unfounded. 99% of us do not need to be worried by the rules, because most modders I've met have been perfectly nice and reasonable people. i.e. the rules will most likely not end up affecting most of as at all.
...at most, you might get the odd suggestion about - I donno - about maybe this feature should be cvar'ed or slightly altered because it clashes with this feature already in the OJP etc.etc. Maintenance type stuff - just to keep the OJP nice and organised. That's all it will be for most of us.

THe main 'rules' are only to combat a minority who wish to abuse stuff. Who knows - that minority may not even be a problem this time round. But I think it would be unwise to leave things open for that kind of abuse this time round again.


Concerning b., however, I think people may be somewhat correct about this - and why it's not really worth trying to make things TOO restrictive in an effort to try and make this 'water-tight', because I don't think this is possible.
I think it's enough to have the rule in place and say 'We will do whatever we can to enforce this'. This will deter some people. Maybe not all - granted. But there is NOTHING we can do about the very possibility of rips without making the source much less OPEN. And I agree with Emon here - this is the whole point of the project in the first place.

SO I say give out access freely, but make sure the 'rules' are nice and clear, and let people know we will take 'some kind of action' if they don't follow them. There ARE steps we can take - it's not like people will be able to have completely free reign here.

Assuming the OJP becomes fairly universally recognised, that in itself gives it some 'pulling' power around the community etc.

Emon
09-27-2003, 01:33 PM
I can see you wanting to stop the "me too" mods (which, by the way, were gameplay based, we aren't going to be making any gameplay changes probably, removing any possibility of that), but having people e-mail for the source code is not going to help! I bet you we'd end up authorizing every damn e-mail and it won't have mattered any way. Tracking? Please, what's that going to let you do? It all boils down to you contacting a site and making them take the mod off, how is knowing who e-mailed you going to help? They could have sent an anonymous e-mail. Sure, you can trace it, but how does that help! Oh no, you can tell a guy lives in Germany that stole our code! Whoop dee ****ing doo, we still call up LucasFiles and tell them to take it down.

Afterall, this is all over ONE person who I haven't seen in a long time. If we're doing this entirely to stop BOFH from stealing our code, then please, grow up. It's also inflating his ego!

If something severe happens, then let's limit the code distribution. But for now, I don't see a damn reason to.

Additionally, I think we should release the code in actual mod form for end users. JA's got more map entities, but not enough. It would be nice if mappers could make maps to use OJP's public releases. Since it doesn't make gameplay changes, it would be ideal for servers that don't run mods and want to run some fancy levels. And also, we'd have to release only major revisions, because no one wants to update OJP every other week.

RenegadeOfPhunk
09-27-2003, 02:36 PM
Additionally, I think we should release the code in actual mod form for end users. JA's got more map entities, but not enough. It would be nice if mappers could make maps to use OJP's public releases. Since it doesn't make gameplay changes, it would be ideal for servers that don't run mods and want to run some fancy levels. And also, we'd have to release only major revisions, because no one wants to update OJP every other week.


I agree, we should definelty have an official OJP mod released and playable by the public.

Actually, my idea I was thinking about would be to possibly have a couple of different versions. I haven't really thought this through thouroughly yet - so don't dismiss the idea straight away! - but I was thinking of something along the lines of:

OJP Basic
------------
This would be JUST bug fixes and anything which are improvments, but don't alter basic gameplay - like you've said Emon.

OJP Fun
----------
This includes all the OJP basic stuff - PLUS...
all the 'cool' extra (gameplay changing) features cvar'ed up. This is for the less serious gamer who just wants to chill out, and doesn't bother too much about conformity etc. (There are a lot of players like this)

...and maybe even...

OJP Pro
---------
With some established tweaks. This one would probably end up being quite a sticking point for some people, and could end up being like a 1.03, 1.04 patch senario!! :eek:
So, not even sure we want to go there - but it's a possibility anyway...


I just seems to me that if we only release an OJP mod which doesn't alter gameplay AT ALL, there could be tons of features which never get seen in the OJP mod.

Then you have to rely on these features getting used in other mods. If they happen to never get used, or only get used in rather obscure mods, then - doh - they basically went to the trouble of adding a feature that didn't really get used - even if the feature was actually quite good!

SO I think having 2 or 3 versions of the OJP mod sorts that out.
i.e. if you do add something to the OJP, you are almost certainly assured to have it show up in at least 1 of the OJP variations.
And you cater to a wider variety of gamer too.

Of course,I wouldn't start making 10 different 'original' OJP mods - that's a bit OTT, and you've just started the whole fragmentation thing yourself!! But I think 2 or 3 types are reasonable...

Wudan
09-27-2003, 02:42 PM
Well, Re: Fragmentation - that's going to happen anyway.

You can't tell people to be original - it's something they'll have to do themselves.

I plan on radically changing gameplay in my mod, I agree with Emon that gameplay shouldn't be changed by the OJP - but I think that certain fixes and improvements could be made without destroying gameplay (because gameplay is in shambles as it is).

Whatever I want to add on top of that is my business :)

RenegadeOfPhunk
09-27-2003, 02:46 PM
Whatever I want to add on top of that is my business


I totally agree...
...as long as your not 99% similar to another OJP mod - which I think is reasonable to ask...

(or some high percentage - 98% would probably not be good either! ;) )

Since you plan on 'radically changing gameplay', sounds like you'll have absolutely no problem with meeting that requirement.
Can't wait to see what you come up with btw...


(because gameplay is in shambles as it is)


This is a totally objective opinion.
(I don't have one yet - I've just bought the game this second. I haven't even got round to installing it yet! lol :) )
But I've spent enough time in the Jedi Academy forums to know that there are very much two sides to that story...

Emon
09-27-2003, 04:43 PM
Yes, there are definately two sides, and it looks like it's boiling down to patches. Some people think patches are bad, I disagree. I think the only reason it was bad for JO was because LEC pulled the plug, and Raven started working on JA. That, and **** just happens, some people made some bad choices or mistakes, it isn't garunteed to happen again.

Emon
09-27-2003, 04:45 PM
Originally posted by Wudan
You can't tell people to be original - it's something they'll have to do themselves.

That's sort of what I was getting it, thank you for stating so. Really guys, making people e-mail you for the source code isn't going to stop look alike mods.

RenegadeOfPhunk
09-27-2003, 05:08 PM
I agree - I am no longer suggesting people e-mail us for access to the source code initially. I'm totally down with that. I have been for quite a few posts now.

What I am proposing HAS to be organised fairly well is the releasing of NEW mods built from OJP source code.

I guess this should require some kind of request e-mail, along with the description of the mod etc.
But anyway - let's just decide what permissions are needed first. Once we know that, then we get a bit more nitty-gritty and decide exactly how they should work...

Emon
09-27-2003, 05:23 PM
What do you mean, new mods built with OJP?

Razorace and Wudan, what are your mod ideas? I'm also thinking about a mod I'd like to do, and if our plans aren't far off, I think it would be to the best for all of us to combine efforts. Basically, I want to take what's in JA, fix it (if not fixed in patches), and improve upon it. Right now I'm thinking of scoping the E-11 and bowcaster, and bringing back some guns from DF and JK.

RenegadeOfPhunk
09-27-2003, 05:39 PM
Blimey!
...what have we been talking about this whole time?! :confused:

Please check my very first post in this thread:


Overall, it seems the aim of the OJP is to provide a standard 'library' of bug fixes / improvements etc. That's fine - I get that. And I see the need for these bug fixes / improvements to be regulated and controlled.

Now - from what I've read - the idea is that mods are built 'on top of' OJP - i.e. using the OJP code as a base. If this is the case - then woohoo - this is great!


If this wasn't the idea, you maybe should have mentioned something earlier...

I don't mind disagreeing on things - but if your not going to read my posts properly, this makes things very difficult.

If the idea ISN'T to build new mods 'on top of' the OJP source, then I see it as a very limited concept. Sure - it may have appeal to a few developers who have very similar ideas on what they want to do. But what about the rest of us who DO possibly want to change gameplay a bit? Even drastically?

Are we just plain out of luck? i.e. the OJP can't really do anything for us?!


Emon - if you just want to get a few people together to make a mod, you don't need a big, old open source project for that, you just need to get a mod team together!!

Emon
09-27-2003, 05:46 PM
I don't know, I read your posts, but I got confused some how.

That's definately the idea behind OJP, it always has been. I'm confused, when was there confusion on that??

RenegadeOfPhunk
09-27-2003, 05:57 PM
LOL!

...when you said this:


What do you mean, new mods built with OJP?


I think everybody is confused now - certainly including myself!!

Tell ya what - you tell me whatever language your speaking, I'll go off and learn it (it seems to be like English, but slightly different) and then we'll carry on the conversation!


I'm sorry - I'm just getting a bit fustrated here. I think I've been making myself pretty clear...

When I say 'new mods built from OJP source code' - I mean 'new mods which use some OJP source code'. Is that clear?

Is anybody else finding me incomprehensible?!

Emon
09-27-2003, 06:13 PM
Sorry, I was referring to this comment of yours:


What I am proposing HAS to be organised fairly well is the releasing of NEW mods built from OJP source code.

I guess this should require some kind of request e-mail, along with the description of the mod etc.
But anyway - let's just decide what permissions are needed first. Once we know that, then we get a bit more nitty-gritty and decide exactly how they should work...


In response to that, I think people should have to e-mail us simply telling us they are using the source code in their mod, so that we can keep track of it. Well, it wouldn't necessarily have to be required, but it would be a benefit to both parties if they did.

Another great thing about building mods on OJP, is that you could have levels built with new code and entities that will run on any mod built off OJP, which I hope to be almost all. :) One of the cool things about the code setup in the original Jedi Knight, was that you could add any kind of code you wanted, on a per-level basis. Q3 lacks this, and OJP could help as a remedy.

RenegadeOfPhunk
09-27-2003, 06:21 PM
OK - I think were communicating now :)


Another great thing about building mods on OJP, is that you could have levels built with new code and entities that will run on any mod built off OJP, which I hope to be almost all.


Yes - this is a GREAT plus to having the OJP in place - totally agree.


In response to that, I think people should have to e-mail us simply telling us they are using the source code in their mod, so that we can keep track of it. Well, it wouldn't necessarily have to be required, but it would be a benefit to both parties if they did.


Yes, this is the right way to think of it.

If we can keep track of the mods which are using OJP source, then if we see two mods which are 99% similar we can just say 'Hey guys - it looks like your mods are going to be practically the same - might you consider joining forces?' It may turn out that there were more differences than we realised - or they may indeed join forces. Whatever. At least we can TRY and organise things so that overly-similar mods don't get made - because that doesn't help anybody. Not the mod makers, or the end users - the players.

Ok -so do we agree that - ideally - all mod makers who want to use OJP source in their new mod need to touch base with the OJP admins - so we can organise things? That's all I'm saying...

Emon
09-27-2003, 06:27 PM
Sounds good.

Only reason I can see that someone wouldn't want to use OJP is the view that it's bloated, and would have large VMs. But this isn't going to affect actual speed, only load times perhaps. At least noticably. Only truely anal coders like ASk will have a problem. ;)

Scarlett
09-27-2003, 06:35 PM
Actually, my idea I was thinking about would be to possibly have a couple of different versions.
I don't really like that idea. It seems like it'd be best to just keep everything in one version. As long as any beyond-patch gameplay changing aspects are done outside of BG code, we can easily make them Cvar options... i think that'd be the best way to go.

RenegadeOfPhunk
09-27-2003, 06:36 PM
:)
Yes - the OJP code itself is going to get quite large!

People making new mods from the OJP source code are free to 'strip out' whatever they don't need though I guess. At least I don't see why this is a problem.

...and as long as all the OJP additions have been clearly marked with nice clear, searchable comments, it should be as painless as possible to do this - ideally as least...

RenegadeOfPhunk
09-27-2003, 06:44 PM
I don't really like that idea. It seems like it'd be best to just keep everything in one version. As long as any beyond-patch gameplay changing aspects are done outside of BG code, we can easily make them Cvar options... i think that'd be the best way to go.


Well - partly, this depends on what people see as the scope of the OJP.

Seems that some people just see it strictly for bug fixes and improvements which don't affect basic gameplay.

However, I saw it as more encompasing than that. For example, I am ready to add an LMS (Last Man Standing) system to the OJP. But this - of course - DOES affect basic gameplay...

First of all, is this kind of work (e.g. LMS) welcome to be added to the OJP?

Second - assuming it is - do we release the OJP absolutely chock-full of cvars? To me - that seems like a total mess. I dont' agree with that. Pro players - for one - would NEVER play it - because they would never know what type of game they were playing when they joined an OJP server - they would rather not have the bug fixes - no matter how good - and just stick with the base game.

So splitting it up into at least 2 types of mods allows us to take on any and all 'improvements' without turning the released OJP mod into a cvar nightmare!

Emon
09-27-2003, 06:46 PM
I don't like the multiple version idea, either. Just have internal and external releases. Internal is very frequent, external leaves out the minor revisions so people don't have to update so damn much.

Gameplay changes through cvars would give end users a little more incentive to run the mod. But restrict them to balance issues, nothing major. Through this, OJP could patch any gameplay issues that Raven doesn't or cannot get (like if LEC pulls the plug), and, hopefully, become an unofficial patch, and at the same time support all sorts of new user made levels. (Competitive players wouldn't bother with this mod, as they almost always like everything vanilla, but I personally think that kind of strict competitive play sucks anyways).

I have a lot of faith in this project. I think that if it goes the way we want, it could be the sole factor in determining the long term condition of JA.

Emon
09-27-2003, 06:49 PM
ROP, I see your problem with the cvars, but I believe multiple mods is a bigger problem. It's confusing, they're not compatible, just... I don't like it. We aren't going to be making six hundred changes here, so it won't be a huge mess.

RenegadeOfPhunk
09-27-2003, 06:54 PM
Emon,

Can you please just double-check you've read my last post thouroughly.

I'm not talking about different versions as in v1.0, v1.1, v2.0.

I'm talking about two different 'builds' of the OJP.

One which is limited to only bug-fixes and non-gameplay changing improvements. (Sounds like this is what your most interested in)

...and another build which could have all the other additions (e.g. LMS, extra force levels, jetpacks etc. etc.)

...unless were not intending the second kind of additions to be allowed in the OJP at all. In which case I think that's a bit limiting. And actually going against the whole 'open source' concept you've been speaking so strongly for...

RenegadeOfPhunk
09-27-2003, 06:57 PM
ROP, I see your problem with the cvars, but I believe multiple mods is a bigger problem. It's confusing, they're not compatible, just... I don't like it. We aren't going to be making six hundred changes here, so it won't be a huge mess.


I believe the opposite.

I think it's FAR worse to have one mod chock-full of cvars, than having two builds.

Either that, or we have to think about limiting the amount - and the SCOPE of the features we can have in the OJP - which I don't think is very appealing, and goes against the idea of 'open source'...


And it's not just the literal amount of changes, it's also the SCOPE of the changes.

You seem to be under the impression no-one was going to add features which changed basic gameplay.

However, I was already planning to do so. (LMS)

If you do accept the LMS code, and you add a cvar for it, then say goodbye to the so-called 'professional' JKII players who just want to play the game as it is - no massive gameplay changes from base should be even possible.

If you still accept the LMS code, but don't include it in the final mod - what was the point of me contributing it in the first place?

If you don't accept the LMS code - then you limit the whole idea of the OJP. It would still work, and it would be fairly good - but why not allow all changes and make 2 builds?

Could you explain exactly how 2 builds will cause such confusion?! Seems pretty simple, clear and effective to me...

but again - it's majority rules here - so whatever everybody else thinks...

Emon
09-27-2003, 07:08 PM
Originally posted by RenegadeOfPhunk
Emon,

Can you please just double-check you've read my last post thouroughly.

I'm not talking about different versions as in v1.0, v1.1, v2.0.

I'm talking about two different 'builds' of the OJP.

One which is limited to only bug-fixes and non-gameplay changing improvements. (Sounds like this is what your most interested in)

...and another build which could have all the other additions (e.g. LMS, extra force levels, jetpacks etc. etc.)

...unless were not intending the second kind of additions to be allowed in the OJP at all. In which case I think that's a bit limiting. And actually going against the whole 'open source' concept you've been speaking so strongly for...

1. I know what you mean, I know you mean different builds, and I still disagree.

2. Things like LMS, jetpacks, and whatever aren't what OJP is for, that's for the mods built on OJP. OJP is for things like new entities, bug fixes, new collision detection, maybe like new and fixed AI, and maybe very small gameplay changes to fix balance issues, making it an unofficial patch. Speaking of patches, that could be used as a guideline for what should go in. If Raven wouldn't add it in a patch, maybe it shouldn't be in OJP. Patches rarely severely alter gameplay or add new elements to gameplay, only fix them, which, as I have followed, the limit to gameplay changes for months now.

3. It's limiting, sort of, because it goes beyond the scope of OJP. We want, or at least I want it to help developers to make their own gameplay changes, not let them use ones we've created. If we go by your idea, we'll start to see some lookalike mods. And how does this go against open source? Open source just means the source code is freely available to anyone, in a nutshell.

4. "Chock-full of cvars"... As stated above, we'd only be making minor changes, there would be no more than like a dozen new cvars. I don't see that as "chock-full".

And limiting what goes into OJP is, as stated above, not against open source. This is primarily a mod for developers, not end users. Rather, it is for developers directly, end users are affected indirectly.

RenegadeOfPhunk
09-27-2003, 07:15 PM
Ok - I see what your saying.

Basically, I've seen the OJP slightly differently than you have.

Yes, if we are limiting the OJP to non-gameplay changing features, then fair enough. We don't need two builds - I agree.

However, I'll be a bit disappointed if this is the case. I saw the OJP being a little bit more ecnompasing than that.

...but if this is the case, then so be it...

I think we can do what you want to do AND MORE with the 2 build concept. And I don't see it as confusing - at all infact! But whatever everybody else thinks...

Scarlett
09-27-2003, 07:19 PM
Alright, i can see your point about having different builds, Renegade, rather than all the options... i didn't think about some of those things. But let's just limit it to two, eh? One for enhancements alone and another of additions and the enhancements. So when there's a new update that's an enhancement, it'll be implimented into both builds.

Emon
09-27-2003, 07:21 PM
Hey, I understand what you mean. But think about it. If we make all those changes, there's no real point in having other mods, and we're going to see a lot of copycats.

Take for example various C/C++ libraries. LibXML only loads and parses XML stuff for you, it doesn't interface with your code. LibJPG will load JPEGs for you, but it won't start drawing them on cubes for you in OpenGL. Every project's got to have some sort of boundaries, for OJP, it's gameplay changes.

RenegadeOfPhunk
09-27-2003, 07:24 PM
Alright, i can see your point about having different builds, rather than options... i didn't think about some of those things. But let's just limit it to two, eh? One for enhancements alone and another of additions and the enhancements. So when there's a new update that's an enhancement, it'll be implimented into both builds.


This is EXACTLY what I am proposing. Just 2 builds - that's fine.

All the stuff in the 'enhancement' mod would also be fully included in the 'additions' mod - exactly.

In this sense, they are compatible mods.

The ONLY reason for the two builds is because your more serious JKII gamer wants to know what he's playing when he joins a server...

RenegadeOfPhunk
09-27-2003, 07:31 PM
Hey, I understand what you mean. But think about it. If we make all those changes, there's no real point in having other mods, and we're going to see a lot of copycats.


Not nessesarily true Emon. Not all mods will nessesarily just blanketly use all the features from the OJP. And this was the whole point of the copy-cat clause we've been talking about for a while.

I, for one - know that the mod I would plan to make from the OJP would not just casually copy ovver all the features. In fact, I'm fairly sure I wouldn't want half of them! My mod is about Movie Realism - so a lot of it wouldn't be applicable (one small example - RGB sabers - I wouldn't want them - I would only want colours seen in the movies).

If you read my first post, I used two case examples to illustrate how I saw it working.

Your analogies between libraries and the OJP only work if you consider the OJP actually as a library. It doesn't nessesarily have to be JUST that...

Emon
09-27-2003, 07:35 PM
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
09-27-2003, 07:44 PM
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
09-27-2003, 07:54 PM
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
09-27-2003, 07:59 PM
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
09-27-2003, 08:05 PM
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
09-27-2003, 08:08 PM
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
09-27-2003, 08:23 PM
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
09-27-2003, 08:29 PM
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
09-27-2003, 09:33 PM
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
09-27-2003, 09:42 PM
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
09-27-2003, 09:52 PM
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
09-27-2003, 10:04 PM
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
09-28-2003, 12:21 AM
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
09-28-2003, 02:26 AM
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
09-28-2003, 02:36 AM
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
09-28-2003, 03:17 AM
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 [Code Improv #]. We can leave the explainations of Bug Fixes and such in the project documents.

- Try to document your code as much as possible.

Emon
09-28-2003, 03:31 AM
Good idea.

You can also be extra fancy and do this:


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


;)

Emon
09-28-2003, 04:34 AM
Preliminary site layout from 1:30 AM, I think the comments emphasize my fatique... (http://emon.geekvision.net/OJP)

razorace
09-28-2003, 06:08 AM
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. :D

RenegadeOfPhunk
09-28-2003, 09:14 AM
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
09-28-2003, 09:39 AM
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
09-28-2003, 10:43 AM
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
09-28-2003, 10:55 AM
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
09-28-2003, 11:03 AM
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
09-28-2003, 11:56 AM
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...

RenegadeOfPhunk
09-28-2003, 12:09 PM
Also consider this:

With a locked checkout system, individual users don't nessesarily HAVE to wait till that file is checked back in...

You could just go ahead and adjust that file locally anyway - even if it is checked out. Just make sure you mark each of your changes well.

Then - when the other user checks back in the file you need, you make sure the file you were working on is backed up somewhere.
Then you check out the file you need, which means getting the latest file from the repository with all the other users changes.

Then you merge it manually your end - finding all your changes in your backed up file and putting them into the latest file from the repository.

OK - it's more hassle. But at least the repository is SAFE.

...put it this way, I'd personally rather go though the kind of hassle mentioned above than have a potentially unsafe repository...


I know we haven't done the tests yet! But I'm just getting down all the possibilities just in case the tests expose problems with a totally unlocked system...

Wudan
09-28-2003, 12:13 PM
Feh. It's going to require COORDINATION. Which is why I say the bulk of your functions should be in external files, for instance, if I made a new file for g_ code, I'd call it g_wu_whatever.c - and I'd have some step by step code pastes for hooking it up to the main codebase. It's the least ugly way to go about it.

Every other way, checking, single code-base, etc - they just seem too problematic and klunky. I just want to code.

RenegadeOfPhunk
09-28-2003, 12:16 PM
Wudan,

I totally agree - external files...
...WHERE possible!

But many alterations can't be nice and neatly bundled up in seperate files.

I certainly see very little of the changes meant for Distribution 1 being able to be kept to seperate files.
Maybe more in Dist. 2 could be neatly packaged up in sep. files, but I seriously doubt ALL will...!

If the change requires all sorts of little code changes all over the place, you can't put them in seperate files!

So we need some kind of CVS system. I don't think this is in doubt. THe CVS system is meant to give you the co-ordination you mention - that is it's whole point!

And it obviously works! No big, complex open source project COULD work if CVS didn't!!


Were only talking about the specific details of the setup of the CVS system here...

Safety of the central resository vs. the convinience of the end user.
Personally, I think the safety of the respoitory should get top priority...

Emon
09-28-2003, 01:11 PM
Wudan, doesn't your idea make it a pain in the ass to put stuff back together? What exactly is wrong with just adding to the regular code, as long as it's neat and well documented?

ROP, what exactly do multiple checkouts do? Because I'm not quite getting it. How do you have two people checking out one file, and still get the new code from each person when you merge it? Wouldn't one overwrite the other?

RenegadeOfPhunk
09-28-2003, 02:32 PM
Multiple checkouts (in Visual SourceSafe) are 'similar' to an unlocked repository, except you still have the concept of checking out.

Checking out a file doesn't stop other people checking out that same file, but it means:

a. When you check out, you get the latest file from the repository. THis means that the system knows at what point you started altering the file, and what state it was in when it gave it to you.

b. When you check the file back in, the system has an exact record of who changed what and when inbetween. So it doesn't need to scan the file your checking in to make sure you have any alterations you should have. It KNOWS straight away whether you need to do a merge - because it knows when you checked out, and if anybody else has checked out AND in since then.

At this point it would attempt to do an automatic merge. As long as their are no conflicts, it can handle all this automatically. You only have to start manually merging stuff in if there are conflicts - but this doesnt' actually happen as often as you might think...


It's probably best not to think of multiple checkouts as checking in and out as you know it (i.e. totally locking out other users) - it's more a system of marking when alterations are made by different users -combined with automatic code merging.

It's an unlocked system in the strictist sense, but it's a very safe and organised unlocked system.
I know it works - I've used it pretty much every day for the past 5 years!!

But anyway - this is probably irrelavent anyway. Sounds like the CVS system were using doesn't have this 'marking' concept - at least not to the same extent (and SourceSafe obviously isn't free!) - so we have to make do.

And who knows - maybe this system CAN accurately work out when things need merging and make sure someone can't just overwrite stuff. We can find this out through some fairly simple tests

If this is the case - all is good...

Emon
09-28-2003, 04:10 PM
Oh, that's cool. I think Subversion (http://subversion.tigris.org) is adding that in future verisons, they are aiming at replacing CVS.

RenegadeOfPhunk
09-28-2003, 04:25 PM
Subversion looks cool.

I don't think it does anything like the 'multiple' checkout stuff I've been talking about (at least I couldn't see anything like that in the description - current or planned...)

But it looks like it's an overall improvment on CVS in some areas...

I think I've had it lucky using SourceSafe! Seems the free, online stuff is either fully open or fully locked down - no real inbetween...

Emon
09-28-2003, 04:34 PM
You think SourceSafe is pretty good eh? I've heard horror stories about it, and I've heard it's one of the few things Microsoft has gotten right. Oh well.

CVS should be fine. We're only a mod team, I don't think we need much more.

RenegadeOfPhunk
09-28-2003, 04:41 PM
Well - don't get me wrong - it has it's problems. Things can start to get unglued when you start branching stuff AS WELL as multiple check-outs! lol - but that's just asking for trouble anyway!

At the end of the day, we've had very little trouble with it at our place.
Were certainly not worried about work being over-written in the repository - AND were not restricted to single check-outs...

Yeah - CVS will do the job. But if we think it might be likely that we could over-write stuff accidently, I think we should just bite the bullet and lock the repository down. With no 'inbetween' to choose, I think that's the best alternative.

...that's just my opinion though.

...and we still need to get it set up and do the tests first anyway...

Emon
09-28-2003, 04:51 PM
Correct. I'll look into Asynchrony today. There are some other places similar to SourceForge, but I don't believe they will approve of our project, as they are all true open source. Asynchrony hosts closed source projects, infact there is no approval, it's instant.

Emon
09-28-2003, 05:41 PM
What's the news on our hosting? I'll have the page done today.

If, for some reason, JK.net cannot host us, Kedri at Massassi made it quite clear last I talked to him that he would be fine with us being hosted over there.

RenegadeOfPhunk
09-28-2003, 05:56 PM
I'm still waiting for a reply from ChrisC3P0.

I've just sent an update request message to him...

razorace
09-28-2003, 07:28 PM
I have a repository with CVS (as in the cvshome.org version) @ freepository.com set up. It just needs to be tested now.

razorace
09-29-2003, 03:23 AM
Say, here's a idea. Why not make a universe cvar list while we're messing with stuff? A simple cvar.txt in the documents folder would do the trick. You could simply add descriptions/cvars when you discovered what they do.

recombinant
09-29-2003, 03:42 AM
sorry... i've been out of the loop here for some time, but this project sounds like it has a lot going for it. I'd like to assist if possible.

It seems to me that if you're going to create an "Open Jedi Project" then it should actually be open, in line with the concepts of Open Source. If it's not really open then it's probably a good idea to call it something else. Additionally it would be necessary to give consideration to the Raven/LA license. However, as wudan mentioned, definitely requires management of the changes, but the changes would be subject to approval, etc.

I'm sure you already know this, but with regard to CVS, it's quite a radical change of concepts from VSS. I've been a VSS user/admin for quite a while now, and we're moving to CVS in our organization. The idea is that you don't actually check out files like in VSS... a "check out" in CVS is akin to a Get in VSS, which can be a bit confusing. The merge happens after you work on the file locally.

But getting back to the concepts of the project, it sounds like it's going to be a great asset to the mod community.

razorace
09-29-2003, 04:40 AM
Well, I got bad news. After checking out the freepository.com system some more, I don't think it's going to be what we need. Getting direct CVS access in Windows is INSANE. You'd have to install a CYGWIN shell and crap and that is too goddamn complicated. In addition, the webpage system is far too primative to be useable.

I'd say our best hope lies with sourceforge since their system can be easily accessed with WinCVS (as far as I know). I know I've seen a JK2 mod on the site so I don't think we'll have a problem getting it there.

Or, we could try getting someone to manually host a CVS server for our purposes.

RenegadeOfPhunk
09-29-2003, 09:33 AM
I've got a message back from ChrisC3P0.

He says he can give us hosting. He can't set up the forums until the website is up and running. (That's the policy).

So - Emon - you may want to get in touch with Chris directly to sort out the website. Just send him a quick PM I guess.


recombinant,

oooo. Someone who has used a 'normal' CVS system AND VSS. Cool. Maybe you know of a free CVS system appropiate for what were trying to do which has some kind of 'multiple check-out' system - or something equivalent...
(btw - Did my explination of multi checkouts make sense?)

About the 'totally' open thing - well - again, I'll go with the majority. Maybe it's even just a case of not calling them 'rules' as much as 'guidelines' - or whatever.

razorace
09-29-2003, 09:58 AM
Bingo! 'normal' CVS does a check to make sure that you don't accidently revert someone else's revision if you haven't updated before committing. I believe that commit will not work (gives an error) if your code isn't 100% up-to-date with the CVS repository.

http://www.cvshome.org/docs/manual/cvs-1.11.6/cvs_10.html#SEC83

Unfortunately, you need direct access to teh CVS system for this to work (since the program has to store a lot of data locally to do this) and freepository.com's method for direct access is too complicated for our purposes. Hell, I'm not even willing to do it. It involves installing a unix shell and crap. Not worth it. :)

We need a repository where we can use winCVS or something that's easy. Since it sounds like we're going to 100% open access, security isn't much of an issue.

RenegadeOfPhunk
09-29-2003, 10:23 AM
AHA!

Yes - 'unreserved' checkouts sounds like the CVS equivelent of the 'multiple' checkout concept I'm used to.
And it looks like it's (reasonably) safe. I'd still be wise to do quick tests, but at least the concept is there...

Phew! That's a relief!

OK - so now we just need to find a system that isn't a total nightmare to work with...?

razorace
09-29-2003, 10:34 AM
See, I was pretty sure that was the situation. The book I was using was written in tutorial form so it was like impossible to just flip thru and find specific information on the commit system. The 4:00am tired didn't help either. :D

Anyway, I'm hoping that sourceforge will accept us. I'm pretty sure WinCVS works with it.

RenegadeOfPhunk
09-29-2003, 11:10 AM
Yeap - sorry Razor, you were right - it was just a difference of terminology...

Reserved and unreserved (CVS)

as opposed to

single and multiple (VSS).

It'd be nice, recombinant, if you could confirm that for us - since you seem to be familiar with both systems. BUt certainly looks like it to me from the stuff Razor has just linked to...

Wudan
09-29-2003, 12:43 PM
mmm starting to sound good mmm

RECOMBINANT!!! Where've you been?

recombinant
09-29-2003, 06:04 PM
Originally posted by razorace
Anyway, I'm hoping that sourceforge will accept us. I'm pretty sure WinCVS works with it.

Yes... for Windows systems it seems that WinCVS is sort of the standard, and Sourceforge's system evidently works well with WinCVS. It's definitely not a trivial setup, however, and it can be a challenge. I'm still working on it. ;)

Honestly, I've only had a little experience with CVS so far, and I'm not the CVS admin at work. However, there are a few people here I can use as resources, since they've used CVS, specifically with Windows as a client.

I'm very familiar with multiple checkouts in VSS, and it's a similar concept to CVS - basically more than one person checks out a file and VSS attempts to merge when you're done. If it can't figure it out, you get the esteemed privilege of doing the merge manually. :D

But CVS basically lets you work all you want - there is no real checkout per se like VSS ("Hey, I'm working on this file and you can't have it until I'm done!"), but that's the whole different mindset behind CVS. VSS' multiple checkout system is the closest analog.

Sorry I couldn't be more help at this point... if I find out more I'll let you know.

:D

recombinant
09-29-2003, 06:09 PM
Originally posted by Wudan
RECOMBINANT!!! Where've you been?

Oh, I've been lurking about.... lots of stuff going on and I had to drop some extracurricular activities to maintain my sanity.

BTW, we released the software product I've been working on since last year (remember my month-long disappearance back in March???).

...and of course we're now working on version 1.01. ;)

RenegadeOfPhunk
09-29-2003, 06:11 PM
OK - thanks Recom.

Well - from what I've read, I think the ideal set-up in the CVS system would be 'unreserved' check-outs.

I guess we just need to give it a thorough testing and see how robust it is. It sounds like it should do the job...
at least if it does what it says on the tin :D

Wudan
09-29-2003, 07:05 PM
I'm still betting that we have to do some lean mean manual merging before the sun sets on this project.

Hellfire Jedi
09-29-2003, 07:15 PM
This is a bit offtopic but, on JK2 section of PCGM, there was a OJP zip. The guy had a fit, Sergio/Eldritch changed it to Saber Hilt Pack. The zip is still called "ojp.zip."
Once agian, sorry for off topic.

razorace
09-29-2003, 07:28 PM
The components that will be in both distros will probably have to be manually merged (partially) once distro 2 changes significantly from distro 1.

But, hey, it's better than doing everything manually. :D

razorace
09-29-2003, 07:39 PM
Originally posted by Hellfire Jedi
This is a bit offtopic but, on JK2 section of PCGM, there was a OJP zip. The guy had a fit, Sergio/Eldritch changed it to Saber Hilt Pack. The zip is still called "ojp.zip."
Once agian, sorry for off topic.

Thanks for the update. We already knew about the name stealling but I didn't know about this new file until now. I'm still talking to the admins about it. :)

RenegadeOfPhunk
09-29-2003, 07:42 PM
...well...

There are two ways to approach the two distributions.

btw - can we give the two distributions / builds different names? 1 and 2 don't really tell you much. I'd suggest:

Dist. 1 = OJP Base
Dist. 2 = OJP Plus

...or whatever. Someone can probably come up with better names...

Anyway - you can either keep the two distributions totally seperately. That means your eventually going to have to merge Dist. 1 (OJP Base) into Dist. 2 (OJP Plus) whenever we need to do a new release. Could be a bit of hassle.

The alternative is to put ALL changes into the same code base - but wrap up all OJP Plus stuff in a preprocessor #define. Something like:

#ifdef _OJPPlus

/* OJP Plus feature */

#endif


NOTE: This is how extra debug code is handled. It's wrapped up in _DEBUG preprocessor defines...


Then, all you have to do is set up two pretty much identical projects in VC++. One with the OJPPlus define, and the other without. No big merges needed.


Again, this is pretty much how debug and release work. The release build does not include the _DEBUG preprocessor define


We can ask individual contributors to wrap their features themselves, but some will probably miss it - so I think the admins would need to check each new feature and do this if it's been missed. I'm quite willing to do this myself. This won't be that hard as long as you can check the history and see exactly where the differences are (Personally, I'd find this less hassle than doing a massive merge each release time)
And at the end of the day - we really should be checking each feature anyway - for many other reasons too...

I also see this as a safer method...

Two different respositories and merging could still work. But I see the preprocessor define way as neater, and also less overall hassle...

razorace
09-29-2003, 08:05 PM
I don't know. I think two seperate code branches would be easier in the long run. I imagine the plus version will have a LOT more code in it than the basic version. Forcing people to do a crapload of ifdefines around all their plus work would be a big hassle. Having to merge stuff semi-manually (you can merge branches into the "main" project with some automation) would be a lot less work overall.

I suggest we simply make the basic version a branch of the primary code trunk (the plus version). That way we can add whatever we want to the basic code and then easily merge that data into the plus version.

As for actual binary releases, we could just release them seperately or as a package. A package deal would probably be best to avoid jedimod/jedimod++ confusion.

razorace
09-29-2003, 08:08 PM
In addition, I suggest we only use MSN messenger for realtime communication. Idling in a IRC channel waiting for people is too much of a hassle.

My MSN messenger address is razorace@hotmail.com. Feel free to contact me if you need something.

Emon
09-29-2003, 08:18 PM
Originally posted by razorace We need a repository where we can use winCVS or something that's easy. Since it sounds like we're going to 100% open access, security isn't much of an issue.

I'll look into my sources. Bwahah!

I'll finish the website today. The page on there now was an old test, I seem to be in a paradox of finding the perfect method for rendering the page on all browsers, so I said screw it, I'll just use tables or something. CSS layers can bite me.

ROP, when I put together the site, I'll think of good names for the distros.

Razorace, either MSN, ICQ or AIM, whichever most people have. I say not MSN because MSN is supposedly going to not let third party IM clients work with their protocol anymore, and there's no way I'm using theirs. I still think IRC is better, it's especially great when we all have to talk at once. We can use IM for just one on one, but for a team meeting, IRC is a must.

RenegadeOfPhunk
09-29-2003, 08:35 PM
Yeah- I say use ICQ...


About how we manage the two builds, well - I'm not overly fussed at the end of the day.

I would have thought that we would really need to double-check all the features going into the OJP anyway - between us. In that case, the #define way wouldn't really be much extra hassle. You'd get pretty used to adding the #defines quite quickly I reakon...

(Again - I may be assuming too much about the CVS system. In VSS, it's very easy to quickly scan through and see ALL the differences between new code and the old code. In fact, standard procedure is to peer-check someone else's code before they can add it. We could still check aded stuff - only we'd have to do it after it's been added. But that's better than nothing...)


If were NOT checking each addition - well - then I guess the branching method overall WOULD be better.

...but even with the two branches, it's possible that someone may put a feature in OJP Base, when it should be in OJP Plus- or vice versa. If were not checking each feature, we could easiely miss that.
But then I guess you just deal wth it at the time.

Ok - well - either way will work. I'm happy enough to go with branching...

razorace
09-29-2003, 09:29 PM
I'm suggesting MSN because it supports multiperson conversations easily and quickly. As for the third party blocking, I think M$ gave it up. My copy of trillian runs MSN perfectly.

CVS does allow for diff checking. I was simply suggesting a branched system as I know that the process for merging code from the branch to the main is at least partially automated. I'm not so sure that would work for completely seperate modules.

Emon
09-29-2003, 09:35 PM
I still would prefer IRC, and I think some others here would, too. Especially since you can just use an applet on the site and not bother with any client.

RenegadeOfPhunk
09-29-2003, 09:36 PM
ICQ supports 3 or more way conversation doesn't it?

Anyway - I'm not too fussed - although I prefer ICQ, but I'm easy.

recombinant
09-29-2003, 09:58 PM
An IRC channel would be way cool...

razorace
09-29-2003, 10:36 PM
ICQ supports multi recipents but A) that doesn't work as well as a real conversation chat and B) doesn't work in Trillian.

I don't like IRC because there's no way to tell if someone is online or not with idle whoring all the major channels

Sides, if you're too lazy to install MSN or trillian, you're probably too lazy to install WinCVS, and therefore too lazy for the project.

Emon
09-30-2003, 12:37 AM
WHOIS reveals idle time on Holonet. :D But really, it's not going to be that important. If he's idle, he's not talking now is he?

I was fooling around with some graphics, and I got the following. The black box is where the ad would have gone.

http://emon.geekvision.net/OJP/template.html

Mozilla = Great.
Opera = Great.
IE = TOTALLY ****ED UP! :mad: It can't render PNGs with transparency, WTF

razorace
09-30-2003, 01:42 AM
Idle time or not. I don't want to have to have an addition window open just to idle until there's someone to talk to. Plus, this constant virus/portscanning crap when I connect to the network is pissing me off.

I use IE and I seem to see everything, it's just that none of the buttons are pressable yet.

Emon
09-30-2003, 01:48 AM
The banner isn't ugly and white?

razorace
09-30-2003, 02:39 AM
It's white but it looks pretty good as is. Now if only the buttons worked....

Wudan
09-30-2003, 12:37 PM
I'm casting a vote for IRC.

RenegadeOfPhunk
09-30-2003, 01:00 PM
Well - looks like IRC is the fav.

Although I agree with Razor - I think it's a pain in the arse it doesn't automatically detect when someone is idle and give you some kind of an audio alert when someone joins or becomes active again.

I easiely find myself stepping away from IRC for a sec - getting distracted - and then suddenly remembering I'm idling in the room - check, and find I've missed loads of the conversation.

...so to avoid missing anything, I have to keep bringing the IRC window to the front again and again and again and again and again.... zzzzzzzzzzzzzzzzzzzzzzzzzzzzz

...but oh well. I can deal with it...
*sulks* ;)

razorace
09-30-2003, 06:17 PM
Well, tuff, I'm not going to idle in some channel all day so you guys don't have to install trillian or MSN. If you want do the IRC thing, that's fine, but I'm sticking with the IM services. :P

Emon
09-30-2003, 06:49 PM
Um, ROP, I can think of two solutions for that.

1. Scroll up.
2. Look in your log file.

...yeah...

RenegadeOfPhunk
09-30-2003, 06:56 PM
Emon,

Depending on how long I've been away, that's a LOT of catch up, which wouldn't be nessesary in other chat programs.

...I just think other chat programs are far more practical - and just make more sense.

...did the maker of IRC not know how to trigger a sound?!

Anyway - whatever. I think it'd be hilarious to have agreed this much and then not be able to agree on a friggin' chat program!

...so in the interests of sanity (namely mine), I'll leave it up to the rest of you! I'll use whatever...

Emon
09-30-2003, 09:13 PM
Um, how is that different from catching up in an IM client? If you're doing 1 on 1, then obviously they are waiting for a response, same in IRC... If you are doing a chat on MSN, then what, you can wait for the person to get back? You can do that in IRC, too. Just ask the person. I don't understand what is so hard about that...

And most IRC clients let you do sound triggering for all sorts of events.

razorace
09-30-2003, 09:26 PM
A. If noone is around, you don't have to have a freakin' window open all the time.
B. It has a consistent user online alerting. You don't have to worry about the person changing nicks and so on.

Emon
10-01-2003, 01:09 AM
A. I can understand this, but I also don't understand why you can't minimize it to the task bar like most IM clients.

B. You mean changing nicks to indicate that you are away? Who cares? Not only is that not a big deal to change your nick, or even use the proper away mode, but it's not an important feature. Who cares if MSN gives you a little window that says "lol dude I r teh away!!!11"

razorace
10-01-2003, 01:41 AM
A. I can understand this, but I also don't understand why you can't minimize it to the task bar like most IM clients.

Cause you gotta watch the window to see if someone is there. :P

B. You mean changing nicks to indicate that you are away? Who cares? Not only is that not a big deal to change your nick, or even use the proper away mode, but it's not an important feature. Who cares if MSN gives you a little window that says "lol dude I r teh away!!!11"

No, I meant when people come online. IRC doesn't handle that very well at all. There's no "user is online" stuff in vanilla IRC.

Plus, I don't like the fact that logging into IRC automatically makes my firewall work overtime to block all the script kiddies.

You can do IRC all you want if that's your thing. However, I'm not going to waste time or taskbar space trying to watch the channel and do my thing at the same time. Sides, you guys are rarely there when I'm awake, so it's just going to be a major thorn in my side.

Emon
10-01-2003, 01:48 AM
Originally posted by razorace
Cause you gotta watch the window to see if someone is there. :P



No, I meant when people come online. IRC doesn't handle that very well at all. There's no "user is online" stuff in vanilla IRC.

Plus, I don't like the fact that logging into IRC automatically makes my firewall work overtime to block all the script kiddies.

You can do IRC all you want if that's your thing. However, I'm not going to waste time or taskbar space trying to watch the channel and do my thing at the same time. Sides, you guys are rarely there when I'm awake, so it's just going to be a major thorn in my side.

1. Most IRC clients can be setup to beep or have their icon flash when there's activity.

2. But what's the point of the user online stuff?

3. My point is that IRC is far more efficient and easier for group meetings and discussions, it was never created for one on one communication.

razorace
10-01-2003, 05:22 AM
Originally posted by Emon
[B]1. Most IRC clients can be setup to beep or have their icon flash when there's activity.

Most but not all. Trillian's IRC function is VERY inconsistant. Plus, it flashes for log ins, log outs, when you're idling and when people are just talking about crap.


2. But what's the point of the user online stuff?


So you know when certain individuals come online. I don't want to be bugged by window flashing whenever guest@java.com enters the channel or when a net split occurs, I just want to talk to people on the project instead of having to check the window 50 zillion times when people are whining about how JKA MP sucks.


3. My point is that IRC is far more efficient and easier for group meetings and discussions, it was never created for one on one communication.

Have you even tried MSN messenger? Its group conversation option covers the exact same base as an IRC chat and it's much less of a hassle to use than idling. And you can simply close the freakin' window (without lossing the ability for other people to know you're online) when you're not interested in the current conversation.

idontlikegeorge
10-01-2003, 07:20 AM
Well, maybe when you guys stop arguing about the rules - or lack of rules - and the method of communication, you can start the project! I'd be interested to see what you guys got in store!

Sorry for posting, as I doubt I have the coding abilities to actually contribute, but it seems there is a lot of bickering on little stuff - I mean it's good to come to agreements on the project plans and all, but imagine how many lines of code you could have made instead of the essays y'all have put into this thread? :p

Just a third-party observation. I mean no flame, I consider you guys to be respectable, knowledgeable forum dwellers here - and that's a rare thing indeed. So just a thought.

razorace
10-01-2003, 07:54 AM
Well, we're still waiting on sourceforge for a repository and Raven for the qvm code. We're basically stuck in the water until then. That's why we're talking about this stuff heavily now so we don't have to worry about it later.

RenegadeOfPhunk
10-01-2003, 08:42 AM
Deciding what the rules for the OJP are - or whether we need rules in the first place - needs to be done. And it needs to be conclusive enough for everyone to agree on. So I don't see a problem with getting a bit 'involved' with that.

But - hehe - this chat program stuff is quite funny! :) Whenever I wonder if certain aspects of my personality are too stubborn - I only need to visit this thread to put it in perspective! ;)

Anyway - I wasn't acutally aware you could set up audio alerts in IRC - that would improve matters for me at least. So I'll look into that...

razorace
10-01-2003, 10:27 AM
:P So sue me. I'm sick of idling in IRC channels.

Anyway, I've found the first bug fix for JKA (outside of Raven of course). pwn3d!! I'll post about it tomorrow...after some sleep.

Basically, I found out what was wrong with backward walk animations for several of the different saber stances. It's a easy txt file fix.

Wudan
10-01-2003, 12:23 PM
Well, when coordinating on a coding project, IRC is very cool.

A) I don't feel the necessity to keep responding, like with an IM client - I can just hop in the channel and answer questions - if you're not there, and perhaps you're somebody I NEED to talk to, I'll find you on one of the IM programs I have laying around.

B) idle? not idle? I'm supposed to be coding, not chatting away the hours with a bunch of guys who have nothing better to do than argue about a preffered chat medium. EVEN IF I found one of you guys online, getting you to stop whining and join a conversationg would just be too much work - I just want to code, people, let me code! GIVE ME THE CODE!

C) Sadly, I don't think constantly conversing with the other OJP contributors is a very necessary thing - WHILE coding - maybe when I've finished a set of functions and I want to pop in and show you guys what I wrote, then I'd be interested.

D) If you can't tell, I'm frothing at the mouth to begin coding. I want to code, NOW.

recombinant
10-01-2003, 02:12 PM
yeah... you'd better wipe your chin. it's a little unsightly with all that drool...

:D

Emon
10-01-2003, 02:22 PM
I think Wudan said it pretty well... It's nice to hop in and out, and maybe discuss a coding problem or two, with MSN, you've got to organize a stupid chat every time, that would be extremely annoying.

I'm home sick today, so I'll try to finish the web site.

razorace
10-01-2003, 08:00 PM
All you gotta do is click a button and invite people into your chat. It's far less annoying than having to idle in the hope of talking to someone.

Emon
10-01-2003, 11:08 PM
You're missing the point... But whatever. It doesn't matter.

New website! (http://emon.geekvision.net/OJP) I finally got a good design I like, I felt the Obsidian Temple theme and the name of our project fit pretty well together. Most of it's done. I still have to try to change the scrollbar color so it blends better, and fix a few multiple browser issues. Oh, and the bottom image is a placeholder. :)

More later, time to go watch TNG...

razorace
10-01-2003, 11:20 PM
Originally posted by Emon
New website! (http://emon.geekvision.net/OJP) I finally got a good design I like, I felt the Obsidian Temple theme and the name of our project fit pretty well together. Most of it's done. I still have to try to change the scrollbar color so it blends better, and fix a few multiple browser issues. Oh, and the bottom image is a placeholder. :)

Looks good, but what's the whit gap above the new name banner for? A news ticker? Plus, none of the menu buttons work. Is that intentional?

More later, time to go watch TNG...

Sweet.

Anyway...

As I mentioned before, I got fixed animation.cfg file to fix the "bad animation while walking backwards with a single saber ignited" bug. I suggest that we make this the first addition of OJP and release it as version 0.01 of OJP.

But first, we need official names for both distrobutions and we need to settle some of the usage rules. Namely, should make OJP based mod have to contain the OJP readme files as part of their release packages? Or should it be optional as long as they make it clear that the mod is OJP based?

Emon
10-02-2003, 12:47 AM
Originally posted by razorace Looks good, but what's the whit gap above the new name banner for? A news ticker? Plus, none of the menu buttons work. Is that intentional?


Anyway...

As I mentioned before, I got fixed animation.cfg file to fix the "bad animation while walking backwards with a single saber ignited" bug. I suggest that we make this the first addition of OJP and release it as version 0.01 of OJP.

But first, we need official names for both distrobutions and we need to settle some of the usage rules. Namely, should make OJP based mod have to contain the OJP readme files as part of their release packages? Or should it be optional as long as they make it clear that the mod is OJP based?

1. Above the name banner? You mean below it? It's just null space, I liked the way each segment on the page looked, seperate instead of together. Like stone slabs.

2. Yes, the buttons don't work because there is no content to link to yet. :)

3. The animation.cfg thing sounds good. I also made some modifications to it a while ago so that guns were raised and fired from the shoulder, it looked so slick. Totally new animations may be better, but this may be good for now.

4. I think we should use the major.minor.release version system. Pretty self explanitory. Major revisions are indicated with the first space, then minors, then releases. Releases usually refer to the same thing just fixed or changed a little, minor is a small new feature, major is a big new feature or total change, which is pretty rare. Most logical system I think... Also, I think we should try to keep the public releases to minor, so people don't have to update so damn much.

5. I'm about to fill in the content for the page, and I'll include the rules and all that jazz, then you guys an look it over. How's that sound?

razorace
10-02-2003, 02:02 AM
Originally posted by Emon
[B]1. Above the name banner? You mean below it? It's just null space, I liked the way each segment on the page looked, seperate instead of together. Like stone slabs.

Above it. There's just a square whole. It looks intentional.

3. The animation.cfg thing sounds good. I also made some modifications to it a while ago so that guns were raised and fired from the shoulder, it looked so slick. Totally new animations may be better, but this may be good for now.

Well, I'll have to see the file before I can approve of anything. If it works great without any issues, adding it will be no problem. I should note however that both of these probably need to go in the Distro 2 release since animation.cfg changes can cause problems without it being used both server and client side. My bug fix will probably not cause any problems since MP doesn't use that animation anyway.

4. I think we should use the major.minor.release version system.

Sounds good.

5. I'm about to fill in the content for the page, and I'll include the rules and all that jazz, then you guys an look it over. How's that sound?

Fine by me, but you didn't answer either of my questions. :D

Emon
10-02-2003, 03:43 AM
Oops, sorry. :) Yes, I think the readme should be required. It's likely that any OJP enthusiast would make it quite clear that it was made on OJP, it would increase our popularity a little (I know I would!), but if they don't want to, just make them include the readme. One file, no big deal.

More site updates (http://emon.geekvision.net/OJP). All I have to do is fill in the content, maybe add some more visual goodies and optimize file sizes of the images. The box you speak of is the space for the JK.Net ad, I took the info from the DF site. It should display properly... Everything is looking flawless for me in Mozilla/Firebird, Opera and IE. :D

razorace
10-03-2003, 12:31 PM
1. I suggest that we try to make a master cvar/command list that people can add to over time. I'm trying to talk to Kurgan about it to see if he wants to get involved.

2. I think our readmes/docs will look much better and be easier to read if we use something other than .txt files. Should we maybe go with .rtf or .doc files instead? It's not like it's a compatiblity issue. Everyone is going to be on the windows platform anyway. :)

Emon, any news from sourceforge? It's been at least a week. I suggest emailing them if they haven't responded yet.

Emon
10-03-2003, 08:02 PM
More like two weeks. I'm fairly certain they aren't accepting us, but a notice would be nice. I'll contact them. I'll also look into Asynchrony's features.

What's Kurgan's thing?

razorace
10-03-2003, 08:50 PM
Hmmm, why? They accepted =X= mod.

Kurgan is wanting to work on a master cvar list. It would be great if we actually had one for JKA. :)

Emon
10-03-2003, 10:39 PM
You mean of all the cvars in the game? cmdlist and cvarlist don't report everything, so waiting for the source code might be easier.

razorace
10-04-2003, 12:18 AM
That doesn't mean we can't start on one. Besides, we're probably not going to get the SP source anyway.

razorace
10-04-2003, 08:07 AM
------------------------
Open Jedi Project (OJP) Readme
------------------------

Release Version: 0.0.1

NOTE: This readme might not be part of an official OJP release zip since this file is required with all OJP based projects. If this isn't an official OJP release, this file will probably only partially apply.


========================
0000 - Table of Contents
========================

0000 Table of Contents
0001 Introduction



===================
0001 - Introduction
===================

The Open Jedi Project is a code/modding colaberation with the intent of maximizing the features and fun factor for all Jedi Knight Academy mods. We work together by contributing fun, interesting, and useful game features so that everyone can benefit. We operate on what's basically an open source system. See the Smacktard Open License section for more information.

Our design philosophy is to make everything as seperated and customizable as possible to allow developers and players to choose what features they wish to use.

We currently have two seperate distrobutions, Basic and Enhanced:

Basic is a server side only mod/codebase. It includes map enhancements, bug fixes, etc that does NOT affect gameplay. The Basic OJP mod can be found in the /OJP directory of this zip file.

Enhanced is a server/client side mod/codebase. It includes all the additional features of the Basic distrobution but also includes client side modifications, gameplay enchancements, etc. The Enhanced OJP mod can be found in the /OJP+ directory of this zip file.


======================
0002 - Installation
======================

Just unzip this file to your JKA game directory.



============
What's New?
============


v0.0.1:

Enhanced:

BUGFIX1 - Animation.cfg fix for BOTH_WALKBACK2
Fixes an animation bug seen when walking backwards with an ignited single saber in SP.

New File - bwwalkfix.pk3
Includes BUGFIX1



========
Features
========

Basic Includes:
Nothing at the moment.

Enhanced Includes:
BUGFIX1

---------
Bug Fixes
---------

BUGFIX1 - Animation.cfg fix for BOTH_WALKBACK2
Single Player, Enhanced, Animations
What It Does:
Makes the walkward walking animation for the ignited single saber stances work correctly.

Special Notes:
To make the patch work, you simply need to copy the bwwalkfix.pk3 into the /gamedata/base directory of your JKA install directory.
This fix will be obsolete once a game patch comes out. Remember to remove this file before you patch the game.
This might cause problems when playing multiplayer. If you have any problems, just move the file out of the /base directory.

Technical:
Fixes the animation BOTH_WALKBACK2 to play the correct number of frames.


==============
Using Our Work
==============

We have few rules for using our work as part of your own projects:

1. You must include this readme in any public releases of your mod. This doesn't apply if you're only using OJP features that you wrote yourself.
2. You must treat your fellow coders and the project with respect.
3. You may NOT use our work for ANY commerical purposes without the author's direct permission.

Please don't violate these rules, they are here for everyone's benifit.

We will have a public CVS server to allow you to view the source code as soon as we can. In addition, we are still waiting for the MP SDK so there will probably not be anything to see for a while anyway. :)

We suggest that you:

- Submit any cool features you might think other modders/players would like to the project.
- Keep in contact with us about your project. The more information we have, the better we can coordinate OJP to help you and the community. We also like to know that people are using and enjoying our works.



=======================
Submitting Stuff to OJP
=======================

We are looking for any cool, fun, or helpful code/visual effects/etc you might have.

However, we are NOT looking for maps or player models (although we might be able to use some very skilled modeller help) at the moment. They take up a lot of space and can be downloaded seperately.

Before you consider submitting, take note that we won't let you desubmit or remove your works from the project. Allowing people to do so would cause too many problems for the project. While your work will remain your work, submitting stuff to OJP means that you give us the rights to use your work as part of the project perminately.

In addition, your work won't nessicarily be turned on or even in every compiled version of OJP. Some features will be disabled by default to allow people to just fire up and play OJP without confusion.

That being said, if you have something to submit, just contact one of the OJP moderators.

DO NOT JUST EMAIL STUFF DIRECTLY TO THE MODERATORS! ASK FOR PERMISSION BEFOREHAND!

If we think your material could make a good addition to OJP, we will give you write access to the CVS repository (not yet availible) and allow you to make the nessicary changes yourself.


Submission Material Guidelines:

- Document your work as much as possible. Be sure to add mentions of your work to the readme and other project documents.

- Make your work as clean and tight as possible.

- Follow the coding guidelines. Try to keep your code as seperated from other code as is reasonable. Label EVERY coding change (from basejka) with approprate coding tags. If you're creating a new feature, you'll get to determine what the tagname will be. Try to pick something that is simple and easy to search for.

- NEVER DELETE FILES/DIRECTORIES/ETC FROM THE CVS REPOSITORY. If it is nessicary, the moderators will handle it.



=======
Credits
=======

Coding:

Original Jedi Knight Academy Source Code: Raven Software


OJP Administration:

Original OJP Documentation: Razor Ace


Special Thanks:

Raven Software
George Lucas
Lucas Entertainment Company (LEC)



===================
Contact Information
===================

OJP Project Moderators:

Razor Ace - razorace@hotmail.com



End of Line.

RenegadeOfPhunk
10-04-2003, 09:52 AM
Looks good Razor.

In relation to OJP contributors not deleting files and /or directories in the respository. I would hope the CVS would allow us to set individual user rights appropiately - so that only admins can even attempt to delete stuff...

RenegadeOfPhunk
10-04-2003, 09:58 AM
Emon,

Once your happy with the website, either let me know and I'll contact ChrisC3P0 - or you can contact Chris directly...

razorace
10-04-2003, 10:19 AM
Originally posted by RenegadeOfPhunk
Looks good Razor.

In relation to OJP contributors not deleting files and /or directories in the respository. I would hope the CVS would allow us to set individual user rights appropiately - so that only admins can even attempt to delete stuff...

Hmm, I'm not sure about that. We'll have to find out.

Wudan
10-04-2003, 01:05 PM
Jeez Guys, you could at least READ what razor wrote ...

Makes the walkward walking animation for the ignited single saber stances work correctly.

WALKWARD? how tired were you ... ?

Emon
10-04-2003, 03:09 PM
1. I already set a PM to ChrisC3PO, no response yet.

2. The project I applied for on SF was rejected, they just didn't tell me. I had to log in to see. It's probably because of a custom license I had whipped up based off the libjpg/libpng, which just prohibits commercial use. I suppose we can leave it out, though. If you wanna get sued by LEC...go ahead.

3. Where's the license section in that, Razor? I've searched Google, and I can't find it anywhere.

4. With OJP "basic" being only server side, how will that limit new entities? What if I wanted to make changes to the FX system...? What about new AI, vehicles, etc? Surely that is not only server side in JA. If you want to keep this server side, say good bye to any co-op levels or singleplayer levels built on this distribution. I know plenty of people would like to work off JA's vanilla gameplay, not anything we would add to the full distribution. Mappers I'm talking about, not coders. It was my view that the basic distribution wouldn't make any gameplay changes other than those for balance, a lot of people would like all sorts of new mapping features without having to install some full mod.

5. I'll start putting this on the site, put it under the Legal section, and continue my ad campaign in the About section. :D Also, fix all those spelling and grammatical errors Razorace has ;)

Oh, and ROP and I agreed that a class based player system (JA has it, but let us assume we can improve it and make it for all game types) would be a good example of a "generic" gameplay addition to the full distribution? I think we agreed we shouldn't be adding any terribly unique gameplay features, not anything that should be unique to one mod. If we do, I think we'd be venturing away from the generic, open code base thing we've been looking for.

RenegadeOfPhunk
10-04-2003, 04:01 PM
I think it would be 'convinient' if the basic distribution was kept to server-side - just because it can appear all the more transparent to the players.

...but I don't think we should make this a 'hard' requirement.
If there are really cool things we end up wanting to do that should be in the 'basic' build, but end up requiring client-side changes - I say we go ahead and make client-side changes...


And yeah - adding to and extending the class system is a good example of the kind of stuff wanted for the 'enhanced' build...

Extending it to other gametypes is a good idea...

Another very small example:
the classes in Siege seem to be limited to one model choice per class, per team. (Unless I'm missing something)
I think it would be nice to allow a more varied model choice for each class...

Emon
10-04-2003, 05:39 PM
Yeah that's the problem. The more transparent it is to players, the more they will accept it. I was thinking about a middle distribution, if we really want to keep it client side, but that may make it too complicated.

I think we can probably get away with the client side changes...

Think about the advantages of server side:

No client download
Virtually transparent to the player


The disadvantages:

Limited coding in vehicles, AI, etc.



Client side modification advantages:

New AI, vehicles, save games, singleplayer and co-op stuff


Disadvantages:

Few megabyte download



We have to decide which is more worth it. Transparent server side with few big additions, or client side, where we can win a lot of people with co-op and new, limitless singleplayer gaming? Most everyone likes at least some singleplayer, and I can't count how many times, before, after and during JO/JA that people have begged Raven/LEC for co-op gameplay. I think if we can get a good co-op or SP base going in MP, we'll start to attract some huge crowd and support.

razorace
10-04-2003, 06:01 PM
Originally posted by Wudan
WALKWARD? how tired were you ... ?

Ok grammar nazi. :)

Seriously, you're correct. I didn't proof it at all before posting in and I was tired at the time. I'll fix it sometime today.

Yeah that's the problem. The more transparent it is to players, the more they will accept it. I was thinking about a middle distribution, if we really want to keep it client side, but that may make it too complicated.

I think we can probably get away with the client side changes...

Let's keep it down to two distrobutions. Since you're the only one who has shown interest in the Basic distro so far, whatever you want goes. :)

Besides, server side only mods are so limited that I wouldn't even consider trying to mod one. The only reason why Vulcanus/Jedi Academy Mod were so "popular" were the additional server options anyway.

Emon
10-04-2003, 07:08 PM
Why thank you. :) Basic = sv and cl, then.

Oh, and I'm going to make it very clear that this is not an admin mod in any way, shape or form. A lot of people hate admin mods, and accuse them of being the major factor in the downfall of JO. Obviously, it would not be good for us to look like an admin mod...

RenegadeOfPhunk
10-04-2003, 07:17 PM
this is not an admin mod in any way, shape or form.


I second that.

razorace
10-04-2003, 08:08 PM
I assume it's because too many admins abused the additional admin commands?

Wudan
10-04-2003, 08:26 PM
Yes. ChosenOne, the author of JediAcademy Mod, isn't going to put the abusive admin commands this time.

Emon
10-04-2003, 08:32 PM
Kick and ban. That's all you need.

razorace
10-04-2003, 08:34 PM
But wasn't his mod like 80% abusive admin commands? What would be left? Emotes and an small admin improvement?

Emon
10-04-2003, 08:41 PM
Shrug. Dunno.

Where's the license? It's not in the readme you posted, and I cannot find a "Smacktard Open License" anywhere on Google.

razorace
10-04-2003, 08:59 PM
Sorry about that.

That was what I was calling the custom licensing agreement that we are write/using. I removed the term when I figured that it would make things sound more complicated than they are.

Emon
10-04-2003, 09:11 PM
Alright. I have a license left over from the SF submission that I thought covered our needs pretty well, and was clear, short and concise. I'll put it up soon.

razorace
10-05-2003, 02:59 AM
Well, I finally got the direct CVS repository access to work with freepository.com. Getting it set up to work is a little complicated but easy once you figure it out. Plus TortoiseCVS (a open source Windows Explorer extension) makes it extremely easy to go the basic CVS commands right from Windows Explorer.

All the basic commands seem to work ok dokie.

Contact me if you want to try it out. Since this particular system is very barebones and a bit picky about direct CVS access, we'll probably only be using it until Emon can score us some better hosting. You'll probably have to work with me a bit to figure out how to get it to work. :)

BTW, the first rule of freepository is BE VERY, VERY CAREFUL WHEN USING THE WEBBROWSER SYSTEM! It doesn't provide any warnings for deleting entire modules. The issue is currently on the bugzilla for freepository.com, but I suggest that noone (except for member control) use the webbrowser system until that is fixed.

RenegadeOfPhunk
10-05-2003, 11:36 AM
Well - it is a bit involved to get it set-up on your individual machine. Although I think Razor and I have found a way to make the process slightly easier .via environment variables...

The TortoiseCVS set-up is pretty sweet. The basic functions are very easy to perform - and make things very clear.

We've done a quick test - and the system IS safe. If you try and commit changes without having the appropiate updates from the repository - the CVS system stops the commit, and forces a merge...
...perfect! :)

It would be handy to find a nice Diff program to help with any nessesary manual merges - but isn't strictly nessesary. The CVS system points out any conflicts directly in the file itself...

Overall -I'd say this system is good to go - thx to Razor's good efforts... :)

razorace
10-05-2003, 11:47 AM
Well, the diff program issue is just a matter of figuring out which freeware diff program is the best for our purposes.

As for the convenence of installing the bugger, I think we could probably write down the install instructions and make a zip out of all the nessicary files.

If the Sourceforge application goes thru, it should become REALLY easy to set up. :)

Again, for anyone that's interested, I've already set the repository up with several OJP documentation files to get the ball rolling.

razorace
10-05-2003, 11:18 PM
Ok, I'm just merged Emon's improvements into the readme. I'll post it here but remember that the most up-to-date version is on the CVS repository.

Here's a question for the group. Should we include the source code with the binary releases or should we just have the CVS repository host the code?

I think it would be best to just leave it on the CVS repository. It will keep down the workload, size of the release zips, and confusion level for people that just want to play the OJP mod. In addition, forcing people to take a little effort to get the source will probably weed out a lot of the undesirables.

razorace
10-05-2003, 11:44 PM
------------------------------
Open Jedi Project (OJP) Readme
------------------------------

Release Version: 0.0.1
JA SP required: 1.0.0.0
JA MP required: 1.0.0.0

NOTE: This readme might not be part of an official OJP release since this readme is required to be included all OJP based projects. If this isn't an official OJP release, this document will only partially apply.


========================
0000 - Table of Contents
========================

0000..................Table of Contents
0001..................Introduction
0002..................Installation
0003..................What's New?
0004..................Features
0004.1...........Bug Fixes
0005..................Using Our Work
0006..................Submitting Stuff to OJP
0006.1...........Submission Guidelines
0007..................Credits
0008..................Contact Information
0009..................Legal Stuff




===================
0001 - Introduction
===================

The Open Jedi Project is a coding/modding collaboration with the intent of maximizing the features and fun factor for all Jedi Knight Academy (JKA) mods. We work together by contributing fun, interesting, and useful game features so that everyone can benefit.

We operate on what's basically an open source system. Open source basically means that the source code is freely available and accessable by all. See the "Using Our Work" section for details about rights and permissions.

Our design philosophy is to make everything as separated and customizable as possible to allow developers and players to choose what features they wish to use.

We currently have two separate distributions planned, Basic and Enhanced (can anyone think up some better names?):

Basic has two main features. One is bug fixes and balance fixes, neither which will severely alter game play. They are designed to be the "unofficial patch" for bugs and game play problems. Basic can still be considered vanilla Jedi Academy. The other main feature is map enhancements. Things such as new entities, expanded AI, vehicles, scripting and effects system can allow mappers to create far more immersive and fun maps. Since Basic also aims towards recreating all the single player entities and code, it is possible for mappers to create full featured cooperative and singleplayer games and levels using the multiplayer engine. This allows modders to make other enhancements such as new weapons, AI, etc., not possible using the singleplayer engine.

Enhanced is a superset of Basic, meaning it has anything and everything included in the Basic distribution. The difference is that it adds many significant gameplay alterations. It is a playable mod, but also a code base for other developers. To decrease the possibility of mods based off Enhanced loosing originality, we are keeping our game play feature list generic and flexible. New features will be generic, expandable, and flexible so other developers can easily adopt them to their mods. It won't venture out side of Jedi Academy's principle game play, so there won't be anything that makes this drastically unique in terms of pure game play. Players get a full mod that shares the same basic principles and ideas that stock Jedi Academy offers. Developers get a solid, flexible code base that includes the basic, fundamental features you would want to find in most mods, allowing them to spend their time on what makes their work truely unique. An example of a feature for Enhanced would be an extended version of the player class system seen in Siege, one that is available in more game types, and is far more flexible.

NOTE: This release only includes the basic package as there's nothing in the enhanced version yet. The separate distributions will come into play after the MP SDK is released for JKA.

We have a website pending. Please be patient.


===================
0002 - Installation
===================

Just unzip this file your jedi Academy directory.



==================
0003 - What's New?
==================


Version 0.0.1:

Basic:

Bug Fix 001 - Animation.cfg fix for BOTH_WALKBACK2
Fixes an animation bug seen when walking backwards with an ignited single saber in single player by correcting the number of frames.

New File - OJP_fix1.pk3
Includes Bug Fix 001.



===============
0004 - Features
===============


------------------
0004.1 - Bug Fixes
------------------

Bug Fix 001 (BUGFIX1) - Animation.cfg fix for BOTH_WALKBACK2
Single Player, Enhanced, Animations

What It Does:
Fixes an animation bug seen when walking backwards with an ignited single saber in single player by correcting the number of frames

Special Notes:
This fix will be obsolete once a game patch comes out. Remember to remove this file before you patch the game.
Might cause problems when playing multiplayer. If you have any problems, just move the file out of the /base directory.




=====================
0005 - Using Our Work
=====================

We have few rules for using our work as part of your own projects:

- You must include this readme in any public releases of your mod. This doesn't apply if you're only using OJP features that you wrote yourself.
- You must treat your fellow coders and the project with respect.
- You may NOT use our work for ANY commercial purposes without the author's direct permission.

Please don't violate these rules, they are here for everyone's benefit.

We have a public CVS repository set up to let you directly access the OJP source materials to keep up-to-date with lastest additions to the project. However, the process to access the repository is a bit complicated, so please email one of the moderators for assistance.

In addition, we are still waiting for the MP SDK so there will probably not be anything to see for a while anyway.

We suggest that you:

- Submit any cool features from your work that you think other developers may benefit from.
- Keep in contact with us about your project. The more information we have, the better we can coordinate OJP to help you and the community. We also like to know that people are using and enjoying our works.



==============================
0006 - Submitting Stuff to OJP
==============================


We are looking mostly for new code features, but are not limited to that. We are usually looking for generic, flexible, and adaptable features that anyone can work into their own code. Features that are drastically unique or special probably do not belong here, because we believe in keeping individuality and uniqueness among mods.

We also accept patches. If you see something in our code that has a problem, you can submit a patch for it. A patch would usually be replacement code or files.

Before you consider submitting, take note that we won't let you desubmit or remove your works from the project. Allowing people to do so would cause too many problems for the project. While your work will remain your work, submitting stuff to OJP means that you give us the rights to use your work as part of the project forever.

In addition, your work won't necessarily be turned on or even in every compiled version of OJP. Some features will be disabled by default to allow people to just fire up and play OJP without confusion.

That being said, if you have something to submit just contact one of the OJP moderators.

DO NOT E-MAIL MOD MATERIALS TO STAFF MEMBERS WITHOUT ASKING FIRST! Just contact one of us, tell us a summary of your patch or feature, and if we think it fits the project, we'll accept it.

If you think you would like to actively participate in developing OJP, we can give you write access to the CVS repository, so that you may work on it yourself. This doesn't have to be a commitment, but if you would like to just submit features or patches seperately, go ahead.


------------------------------
0006.1 - Submission Guidelines
------------------------------

- Document your work as much as possible. Be sure to add mentions of your work in the readme and other project documents.

- Make your work as clean and tight as possible.

- Follow the coding guidelines. Try to keep your code as separated from other code as is reasonable. Label EVERY coding change (from basejka) with appropriate coding tags. If you're creating a new feature, you'll get to determine what the tag name will be. Try to pick something that is simple and easy to search for.

- NEVER DELETE FILES/DIRECTORIES/ETC FROM THE CVS REPOSITORY. If it is necessary, the moderators will handle it.



==============
0007 - Credits
==============

Coding:

Original Jedi Knight Academy source code: Raven Software


OJP Administration:

Documention: Emon, Razor Ace

Original OJP Concept: Razor Ace

OJP Organizational Planning: Emon, RenegadeofPhunk, Razor Ace


Special Thanks:

Raven Software
George Lucas
Lucas Entertainment Company (LEC)



==========================
0008 - Contact Information
==========================

OJP Project Moderators:

Razor Ace
Email: razorace@hotmail.com
MSN: Razor Ace (razorace@hotmail.com)
ICQ: 618641
AIM: razorsaces
Yahoo: razorsaces

RenegadeOfPhunk
Email: renegadeofphunk@3dactionplanet.com
ICQ: 253305779 (Knobby)



==================
0009 - Legal Stuff
==================

We are making no claim on Raven Software's, ID Software's, or LEC's intellectual properties. The above rules only apply to the additional works created by OJP contributors. Ravesoft's, ID's, and LEC's code and additional materials is only included for ease of use. All applicable licensing agreements still apply. Please don't sue us.

End of Line.

razorace
10-07-2003, 04:29 AM
I've determined a way to get access to the CVS repository with a LOT less effort than before. It's now in the "high easy" catagory of difficult.

There is also stuff in the repository (but not much). Let me know if you want to get access.

stubert
10-09-2003, 01:26 AM
looks like we're about to duplicated eachother's work


http://jk2.zerocomedy.com/phpBB2/index.php?sid=5bb19aa76298ba9e873b6043b9d4b7b6


come talk to us


i've even tried to get a sourceforge project space and was denied... maybe we should put our heads together


cheers


-stu

stubert
10-09-2003, 01:27 AM
i invite you guys to consider joining our project, we have a much less cluttered webspace and will be fully gpl compliant

Emon
10-09-2003, 03:40 AM
...what? I don't even know what your project is.

And you cannot be fully GPL compliant, because the editing EULA violates the GPL, as well as OSI's definition of open source.

razorace
10-09-2003, 05:23 AM
I don't think you got the message about what OJP is about. It's not just a general mod for JKA but a development platform as well.

Anyway, we already have a CVS repository up and running and have already checked out the legal side of things. From our analysis, any mod based on the JKA code can't ethically or legally be distributed as GPL due to it being based on JKA code. The EULA bans commerical profiting which isn't covered by GPL.

We've also checked out SF, but it looks like it simply won't take projects that can't be 100% open source (meaning no restrictions on commerical usage).

From what we can tell, =X= mod was dishonest (or confused) when they signed up for SF since most of their project data is either not legal or simply wrong.

However, we wish you luck on your mod and encourage you to get involved in OJP as active contributors or users.

Emon
10-12-2003, 12:19 AM
I just had some oral surgery yesterday, so I'm quite a bit groggy this weekend, but I'll try to finish the menu files, sound packs, the installer (hopefully with the JO map extraction), website, etc. within a week.

razorace
10-12-2003, 01:39 AM
Awesome.

razorace
10-12-2003, 07:18 PM
Ok lamer. Get to work! :D

RenegadeOfPhunk
10-12-2003, 07:57 PM
Guys,

URL:
OJP.jediknight.net

...ok?

razorace
10-13-2003, 01:31 AM
seems fine to me. Please PM the server login information to me and Emon.

razorace
10-16-2003, 07:24 AM
Ok, ladies and gentlemen, we just got our first submission! It's a eopie (the farting creature from episode 1) vehicle model by chairmaster.

You can check it out here (http://www.geocities.com/quakersnl/eopie.zip). It's not completed yet but it's looking pretty good so far.

Its filesize is small and I think a lot of people would like to use them in their maps if they could.

Emon
10-16-2003, 09:39 PM
Not sure if it belongs... My idea was giving mappers the code backbone, not the models. Seems like bloat.

RenegadeOfPhunk
10-16-2003, 11:12 PM
I agree - I'm not sure things like models should be included in the main OJP distributions themselves.

But, I could very well invisage OJP compatible and / or OJP 'approved' model packs, map packs etc - avalilable as seperate downloads...

razorace
10-16-2003, 11:20 PM
So how are mappers suppose to have an unifed platform for additions vehicles/npcs?

Chairwalker
10-17-2003, 12:26 AM
To include things like hilts and player models would indeed be wrong.
But vehicles are more like tiny additions.

If there werent some sort of pack, maps would have to include every custom npc its using, wich wouldnt be very good for file sizes.

At first i thought about having some sort of vehicle pack, but why not just use OJP ? They'd both practicly do the same.

razorace
10-17-2003, 12:48 AM
I agree. Should I maybe post a poll in the mapper forum to see what they think?

Emon
10-17-2003, 03:23 AM
Maybe, although most people probably don't know what OJP is yet.

Unified platform is only needed for code. I'm all for a model pack, but including it with the regular distributions is bloat. It's not like everyone is going to be using the same models. They can just include them in their own PK3.

razorace
10-17-2003, 03:37 AM
Well, that's true. However, it would be much easier if we had a unified platform for it. Just like map textures. If it's something that a lot of people would want in their maps, it would probably be worth it to be a part of the project.

As for bloat, if it got over say, 2 megs, we could just make it a seperate distro release package.

I'll post a poll and see what happens.

Emon
10-17-2003, 03:52 AM
Textures is a horrible idea. They will get really big, really fast. Most mappers don't use the same models or textures unless it's something like a TIE-Fighter or a vehicle. Textures are so different from each other.

razorace
10-17-2003, 04:25 AM
Sorry, I didn't mean to imply any sort of map texture library. That would be insane. I was referring to how it's much easier to use the default JKA textures vs. adding additional ones. :)

Well, maybe an JK2 texture install program would be ok...

Emon
10-17-2003, 07:16 PM
Yeah, I'm trying to figure out how to do that with DevStudio 9 (InstallShield). But it has a terrible bubbly interface that's too user friendly and I can't figure out a damn thing. Reminds me of Bryce.

ASk
10-17-2003, 10:16 PM
I believe that if you have .NET, you can use the Setup project creator there (at least in Enterprise Architect edition)

b) good diff util: get UnxUtils , it comes with a straight port of unix's 'diff', as well as 'grep' and other useful stuff, or you can get WinDiff, which I like less and Wingrep, which is low-featured.

Emon
10-17-2003, 11:51 PM
VS .NET is a monstrosity of a program, I don't feel like wasting that kind of space, especially when Intel's compiler sucks anyway... I just need it to it to read from PK3s, CABs, or both.

RenegadeOfPhunk
10-18-2003, 12:04 AM
VS .NET is a monstrosity of a program


:D

While .NET has it's problems, you've obviously never worked on a massive coding project with particular emphasis on GUI development over several years and trying to co-ordinate between several developers - or you may have a bit more appreciation of why some of the 'bloat' is nessesary...

I LOVE listening to different coding 'camps' talk about the other 'camp' like they don't have a braincell between the lot of them. Makes me laugh... ;)

Emon
10-18-2003, 02:35 AM
I was talking about storage space...

Many people think .NET is going to flop horribly, the framework that is. I think they're right.

RenegadeOfPhunk
10-18-2003, 03:21 AM
Oh I've no doubt your right - .NET WILL flop.

You MAY need to redefine the word 'flop', or it may actually flop.

...but either way you will almost certainly get the satisfaction of saying 'I told you so'.

Sorry, got a bit deep there.

Anyway - sure. .NET sucks. Sure thing
...and were now pretty off topic...

Yey!

razorace
10-20-2003, 02:35 AM
Yes ladies, please keep the chit-chat on IRC or MSN.

Thanks.

razorace
10-20-2003, 06:03 AM
Well, according to the small poll I created over in the mapping forum. People do seem to be interested in a vehicle pack for map development.

Should we go ahead and give it a try? I'll handle the additional paperwork. :) And if we do decide to do this, how "compete" does a vehicle have to be to be included? Chairmaster's model pretty far along but the animations need to be completed.

RenegadeOfPhunk
10-20-2003, 09:16 AM
Personally, I think OJP 'packs' should set the standard. All inclusions to the packs should be as complete as possible. So in this specific case, I would say anims would need to be complete...

Basically, we should have a minimum 'standard' of overall quality.
In essense, I think we should ask the question:
'Would this vechicle / model / map look out of place if it had been included in the original game'..?

And - just as everything else - this should be decided by majority.

Of course this will all be much easier to organise once the website is up and running...

Those are my thoughts anwyay.

razorace
10-20-2003, 04:58 PM
Fair enough. I'll go tell Chairmaster that we'll accept the model when he's hammered out the animations.

razorace
10-20-2003, 07:36 PM
Well, Indy is attempting to use the OJP label again. This time on jk2files. http://www.jk2files.com/file.info?ID=19800

I'm contacting the admins now. It would help if everything sends an email about it.

razorace
10-23-2003, 06:08 AM
Ok, I'm in communication with jk2files.com about the OJP name issue but the problem is expanding. News sites (http://jediacademy.ravengames.com/) are now posting about the name swiper's mod.

Since this is starting to spiral out of control, I think we need to get a OJP release out soon. Even if it ends up being just my bugfix and the basic OJP documentation. At least we'll publically establish our claim to the name and the concept of OJP to the masses.

Emon, are you going to be able to get any of your work done by, say, late thursday? If not, we can just save your stuff for the next release.

Phunk, you mind bugging jk.net for a forum? I know they wanted a website but it looks like it's not going to be done for a while and we're getting too big for this thread.

In other news, I've created another text file on the repository (OJP_vehicles.txt). The new files deals with documentation on creating/editing vehicles for JKA. There's only a few notes in there now.

razorace
10-23-2003, 10:55 AM
On another note, I think the Prequel sabers blades from Xalius Episode I Sabers (http://www.jk2files.com/file.info?ID=19778) look pretty good. Should I maybe talk to him and see if he'll submit them to OJP?

Anyone knowhow to control the flicker effect seen on the sabers? I'm pretty sure the prequel sabers have less flicker and the original trilogy have a bit more flicker.

RenegadeOfPhunk
10-23-2003, 11:39 AM
As far as this whole name-swiping thing, I suggest that we treat the name 'OJP' like an internal project name.
i.e. just a name you use so that you can discuss the idea before you come up with an actual release name.
...and we don't decide the actual release name till just before we release it. That way, idiots can't just nick the name for their own stuff...

Putting aside the possibility that this guy came up with the same name co-incidently (highly unlikely), he's used it to inconvinience us and just plain piss us off.
So if we have to start releasing stuff early, or changing any of our plans because of him, then he's achieved his aim.
...I say don't give the little s**t the satisfaction.

Let's just use a different name for release. (It IS just a name after all...) And the first time anyone hears the name is when it's already released...


AS far as those new sabers, they look pretty smart. I'm not sure if it's just me, but they almost look TOO thin! But I think their pretty good anyway. I've got no problem with them being submitted...

..and I'll talk to Chris about getting forums ASAP.

razorace
10-23-2003, 05:41 PM
Let's just use a different name for release. (It IS just a name after all...) And the first time anyone hears the name is when it's already released...

I'm voting a big fat NO on that. That's letting this bastard win and I like the current name.

As for a "early" release, that's not really true. I've been wanting to release for a while now, but have been waiting for Emon's menu enhancements. We need a release and a website so we can start pimpin' the project on news sites and getting non-moderator submissions.

AS far as those new sabers, they look pretty smart. I'm not sure if it's just me, but they almost look TOO thin! But I think their pretty good anyway. I've got no problem with them being submitted...

Yeah, I thought so too until I zoomed in on the blade in the game. It's pretty damn close to what it looks like in prequel trilogy except that there's not suppose to be a larger hilt emitter glow and the blade is flickering more than it should be.

The original blade looks more like something from the original trilogy. I think it would be pretty cool to allow players to select the "type" of blade (not just the color). I'll add that to the suggestion list. :)

Anyway, I'll email the creators about it.


..and I'll talk to Chris about getting forums ASAP. [/B]

Great.

PhoenixOblivion
10-24-2003, 07:48 PM
Ok guys your name swiper is taken care of... Turns out as part of his pack he used a saber hilt that i created completely from scratch.. Well, Jk2files doesnt allow my files to be posted at the moment (which includes packs with my files in them)... So i just made a nice little post in the comments... and today that pack isnt there anymore... Goodluck and Godspeed.

Wudan
10-26-2003, 02:08 PM
*Wudan senses a disturbance in the force.

razorace
10-26-2003, 07:34 PM
Originally posted by Wudan
*Wudan senses a disturbance in the force. Kyle: "You always sense a disturbance in the Force."

Anyway, Emon reports that the website is near completion, we just need the OJP webspace account information (Phunk please send it to me and Emon) and to fill out the site with information.

In addition, chairwalker has updated the eopie vehicle model with better animations. You can find it here. (http://www.geocities.com/quakersnl/eopie.zip) I think it looks good enough for release now. :) There's some issues with it, but I think most of it is due to the odd vehicle handling system. We can work on that when we get the SDK. :)

All in favor of adding eopie to OJP's vehicle pack?

All in favor of tagging/bagging our stuff and getting a first release out the door?

Wudan
10-26-2003, 07:37 PM
Double Post?

This can mean only one thing. Razor is gathering a post count to resurrect and evil dark Forum Troll.

razorace
10-26-2003, 07:38 PM
Originally posted by razorace
All in favor of adding eopie to OJP's vehicle pack?I!
All in favor of tagging/bagging our stuff and getting a first release out the door?I!

razorace
10-26-2003, 07:40 PM
Originally posted by Wudan
This can mean only one thing.

....that my dial up sucks?

razorace
10-27-2003, 07:46 PM
Ok ladies, we got another submission! This time it's from TiM with a simple mod that allows the hidden saber hilts to be used in MP.

You can find the file here (http://www.jk2files.com/file.info?ID=19974).

Since noone has commented. I'll just add stuff to the CVS repository unless people complain.

EDIT: I'll still let everyone know that I'm adding stuff of course. :)

razorace
10-30-2003, 12:17 PM
Ok, I figured out how to do the player class stuff so I'm working on converting the hoth cold suit (seen in SP) into a body part (with color selection!) in SP or MP.

I've already completed the work for the jedi_hm (human male) and the jedi_zf (zabrak female). All the stuff that has been completed so far is on the repository.

Once I'm done, I'll package up everything in OJP and we can have our first release! I'm guessing that I'll finish sometime tomorrow or day after tomorrow.

In other news, we're making progress on the website. There's a prototype up at a "undisclosed location" but it doesn't actually do anything yet. We'll keep you posted.

And finally, I noticed that this thread seems to have more post than the rest of the forum combined. Admins, we need our own forum!

RenegadeOfPhunk
10-30-2003, 12:52 PM
New OJP forum is ready:

OJP forum (http://www.lucasforums.com/forumdisplay.php?s=&forumid=542)

razorace
10-30-2003, 06:35 PM
Awesome!

*drives in*

babywax
10-30-2003, 10:06 PM
Ok, I figured out how to do the player class stuff so I'm working on converting the hoth cold suit (seen in SP) into a body part (with color selection!) in SP or MP.

Hoth cold suit is available in MP, I use it :)
Just select a race, and select a head, then select the last torso in the list and the last legs. Then, in the console, type "model" and press enter. One you get what comes out, you'll have something like this: model jedi_hm/head_e1|torso_f1|legs_f1 That's from memory but it should be something like that. Change the letter on the torso/legs to be the next letter in the alphabet and there you have it, hoth cold suit :)

EDIT: Oh, cool :)

razorace
10-30-2003, 10:23 PM
Yeah, I know. I've added icons and selectable colors in addition. Much easier.

{MOTL}thesaiyan
03-19-2004, 03:42 AM
I dont suppose there is an official OJP Website is there? I think you could probably get funding from the community by asking for donations via PayPal or something.


Dam I'm dumb, I remembered I had it bookmarked. I still think it should run under its own power and domain tho


http://www.bluecapacity.com has very reasonable Hosting Rates.

I do alot of editing for JA, though I tend to be critical of myself and have not released hardly any of it. I hope to contribute to the OJP when I have the time to do so.

razorace
03-20-2004, 02:22 AM
Woah. old thread. Please use the OJP forums from now on. They are here (http://www.lucasforums.com/forumdisplay.php?s=&forumid=542).

I'm not a webdesign fan so I don't really deal with website stuff. However, I'm against a PayPal account for "donations". We're not suppose to profit from any of this and having people donate money goes against that. Plus, PayPal is just going to jack you over with surcharges anyway.