Suggestion: Infiltration update to 2.91

[geogob]

I believe the limit is 255 or 256. That is the max number if I recall correctly a limit set by UT. I doubt with even the number of changes you want to make you will get this high.

I didn't mean a techincal limit, benmcl... I meant a practical limit.

Practical for server uniformity, practical for new users, practical for server admins, practical for inter-mutator dependencies, practical for inter-mutator conflicts... That was the idea behind my question/reflection.

Maybe I should take kyle's exemple and do longer posts

 

[Crowze]

What geogob said. The idea is that a sort of UTPG for Inf is formed who would continue development on the old version while SS works on the new. It would allow us, the community, to add what we think is missing and improve what we can about inf 2.9, and would allow Sentry to concentrate development on the new version or whatever you want to. If we got the backing of the whole community as well as SS, hopefully all servers would use an updated version. That would allow us to modify the base player classes, for example, and make additions and changes that would not result in mutator conflicts, and would make things simpler for server admins who don't have to worry about lists of mutators etc.. It doesn't has to be named 2.91 - I'd advise against it as it would imply that it was created by SS, Cleeus just threw that name out to give illustrate the kind of thing that would be done.

 

[{GD}Odie3]

Well, I would look at it like the Working to Keep Unreal Tournament Alive! (UTPG.org) Group and I hope SS would see this idea in the same way.

We have some great coders out there and this could really keep Inf pumping.

Hmm, this is what I said before on the first page.....

 

[Derelan]

I think we need to start implementing a max character count in posts....

 

[Cleeus[JgKdo]]

@Beppo
At the time i wrote my message i got X-posted by you and i wanted to think about a reply a bit more.

 

[Beppo]

You got that wrong Beppo. My intial idea was NOT to ask you or sentry studios to do this. It was to get another team to work on this. You should not have read it like "beppo, please fix that and that for us" but rather "Beppo, can we please fix that and that..."

I'm sorry to see that you did not see it that way. I quite willing myself to get into the code and find solutions myself. It's what I did with RealTargets and i don't mind doing it again.


Then I would like to raise another question. Is there a point where there can be too many mutators needed/available for a game?

No need to be sorry geo... you were not meant at all.
To the mutator question... from a practical standpoint...
no problem with using a hundred mutators if they are done in a way that they do not work against each other. This can already be the case for two mutators, so the actual number is no factor here. It all lies in the hands of the coders of these mutators if they can work together or not.
For weapon additions and stuff like that we have a system in place that - if properly used - will have no problems with other mutators at all. As said, just depends on who codes the stuff and actually how the stuff is coded.

To the UTPG for Inf...
why do you guys need to change the base player class? And why do you guys need to change the base class then all differently? Why do you guys not write a new base class that you guys then develop further and further and all your additional mutators then use the SAME new player base class for example? I guess you guys do communicate and so you guys would be able to coordinate this too. And this without the need to change the original player base class for example.
The BonusPack features a 'new' weapon base class for example that has all the needed fixes to get the HUD icons to show up etc. It has a new playervoice base class to fix the problem with one voice message. It has a new equipment menu that allows you guys to add your stuff to it. All bonus weapons are subclasses of the new base weapon class aso aso.
So it has several new base classes, and this all added by a mutator package. If you guys want to use these new base classes, then you will have all the fixes included too already without the need to code these fixes into your codes too.

So, what I'm trying to say is that noone needs to change the base classes at all. You guys can agree on a new base class that all of you then use in your additional packages. You guys mod a mod and if you guys form up a team, then you guys start almost at the same level than we did at the time we developed our base classes on top of the original UT ones. And your problem of having mutator conflicts is no longer a problem cause you would start to use a new base from that point on and would be able to change and adjust this new base at any time you want.

So, now tell me why should we, SentryStudios, change our base classes if you guys can do it too (edit: with your own base classes). It's not exactly the same but it's almost as if all modders out there would ask Epic to implement this and that feature to their base classes so that all mods out there can work this or that way.
Use INF as your base that you start modding on and you are the only one that gives you limits.

 

[Harper [Jgkdo]]

We don't want you or Sentry to change anything, all we want is your permission to change Infiltrations core classes ourself. It would be ridiculous to add a new layer when there is the smallest possibility that you can change the original one.

No need to be sorry geo... you were not meant at all.

Curious, who was meant?

 

[Beppo]

I guess I need to send you guys to some personal trainers to feel like modders again.

You guys want to mod, then use the given base and build your new content on top of it. That's how mods and modding works. Mods do not edit the base classes of the game they mod, they work with them or exchange/replace them with their own classes. But a mod never touches the originals.
Guess you know what this means. [edit]: for the case someone doesn't understand this little remark...
No, I will not give anyone outside SentryStudios the permission to change our classes. You can use the scripts within, release your stuff with proper credits and that's it. INF was build on top of UT, we never asked Epic if we can rewrite their base classes and break compability just cause it would have been easier... [/edit]

I don't want to see ten different versions of an edited INF_Core.u package in the end just cause ten coders had different opinions on how to change a specific class.
Make ten different versions of PlaceYourNameHerePackage.u and all is good and will result in ten new mods that can co-exist without a problem.

 

[Harper [Jgkdo]]

Plz stop insulting everyone

Now to the modding part. I consider myself a coder not a modder so I would prefer integrating things into Infiltration instead of modding around it. At least for the things a mod can't adress in the same elegant way as original code (I consider the Infiltration classes original)

And about different INF_Core files. That's why it will be a TEAM project hopefully with a beta testing server and a final release where all gathered suggestions, bugfixes and improvements are integrated.

 

[Beppo]

Sorry for insulting everyone... don't know where I did this but well...

Well I consider the UT codes original, I'm a coder, I'm a modder and no matter how 'elegant' some code changes would be, I would never even try to touch the originals.

And about different INF_Core files... SentryStudios is a team, has beta testers and beta servers. Still no valid reason to release a new version of BotPack.u.

Your TEAM will break compability for everyone outside the team. And this is something I will simply not give my permission to.

 

[Lt.]

SentryStudios is a team, has beta testers and beta servers. Still no valid reason to release a new version of BotPack.u.

__________
[edit: I agree with Beppo on all counts, we do not truly need a 2.91 version of INF specifically for coders. the modders in the community are smart enough to work on INF just like SS worked on UT.
I dont see how Beppo “insulted everyone”, if anything it was a compliment. Its just that we dont really need SS to release a new version, and there arent too many ways to say it.]

 

[Derelan]

Sorry for insulting everyone... don't know where I did this but well...

I find that offensive!

 

[Crowze]

But you aren't Epic, and Inf isn't UT. The UTPG team asked permission to change the base UT files, and Epic saw the gain in that. Why can't you?

The core files: Co-exist? Yes. Co-operate? No. THAT's what we're trying to get together: a set of fixes that work together.

 

[Beppo]

I find that offensive!

:tup:

 

[Beppo]

But you aren't Epic, and Inf isn't UT. The UTPG team asked permission to change the base UT files, and Epic saw the gain in that. Why can't you?

And you aren't the UTPG team and we do not have a new title 'on the shelves' and so no longer care for the old games we developed years ago...
I still care for INF and I don't want to let it get hacked, period.

The core files: Co-exist? Yes. Co-operate? No. THAT's what we're trying to get together: a set of fixes that work together.

If you guys want to develop INF further then go on. But do it with your own set of base classes if you need them. If you guys release new versions of original INF packages then all mutators and other additions that rely or depend on the originals get broken. With your new classes build on top of our originals everything else will still work too.

 

[Beppo]

Lt., appreciated, thx.

 

[{GD}Odie3]

Your TEAM will break compability for everyone outside the team. And this is something I will simply not give my permission to.

Okay, we have asked and we have a answer. I see this subject as being closed - IMO.

 

[geogob]

Okay, we have asked and we have a answer. I see this subject as being closed - IMO.

Yes the idea of continuing developement for future version of INF for UT99 is more and more out of the question.

On the other hand I like the idea suggeste by Beppo, to use new base classes... a mod of the mod. But then any kind of uniformity will be lost in the community. Some will run INF 2.9, other INF 2.9 - PLUS, other INF 2.9 with some mutators that are implemented in INF 2.9 - PLUS, etc. The idea of developing for Sentry Studios, under their supervision, to produce official releases was appealing for many reasons.

Doing a mod of the mod like you suggest here will not separate the community like some mutators did (and please, do remember what you said about that to developers like TOAD)... it would create an entire new community, getting most of it's players from the current INF community. This is not what I was looking for.

 

[Crowze]

Beppo, we aren't hackers. Some of the people interested in helping with this project have a lot of programming experience... simply put, we'd put together a team who knows what they're doing. It doesn't matter if we're not the UTPG team, you missed my point there - I think you're looking a gift horse in the mouth. And face it, you're very, very unlikely to release a new version of inf for the old UT engine, because you DO have another project underway.

New classes probably won't work. If you look at (for example) Olethros' CheckMag, it's a nasty little hack which replaces all weapons with his own versions. If we had the oppurtunity to edit the base weapon class, it would be so much neater and would probably not break compatibility with other mutators. That's part of what inheritance is about, isn't it?

Odie, I'm not going to let this drop because it's something I think both SS and the Inf community would benefit from.

 

[Beppo]

Nothing against Olethros and his work (he has done very cool things so far) but why do you need to make new versions of the given weapon classes to get an info about the used ammo?
Adding ie an inventory object that checks the current weapon and its ammo should be able to gather the needed information too. Maybe even a HUD mutator can do this.
A lot of possible ways. Maybe we should discuss about his/your solutions and possible other ways of doing it rather than discussing about 'let me edit the base classes'.
Cause you already see what happens... you get one mutator that implements a feature, replaces all standard weapons by new subclasses and the next mutator does the same, both breaking compability. Why not search a non-critical way before changing the bases?

If you guys (even as a team) start to change the base classes then others outside the team (inculding SentryStudios and me for example) cannot continue any kind of development for INF without knowing how your new base classes will look like or without having access to them during the development.
And who says that your changes do not need to change a bunch of other codes within the standard classes then too? In the end you change a little script part to allow a new feature, then you have to edit ie all other weapons to handle and use this feature. Why not develop a way to add this new feature without the need to change all weapon classes out there?

Again, nothing against you guys devloping new stuff for INF, it's highly appreciated. But why are you guys so focused on changing the base classes instead of programming a general way? Just because it is easier maybe?

I offered to help and you guys can count on it. So if you guys have problems, need infos or similar then I'm here. But giving you guys permission to break compability is another thing.

I don't want to 'lead' your team or to observe it, to check back every minute so that only features are implemented and changed that I/we agree on. Do what you want to do and if the whole thing comes out to be something that SentryStudios can back up, then we can talk about releasing it as a new version or something alike.