Improved Hitboxes on FF?

[WiFiDi]

just a thought can the Hitboxes be improved anymore than they already are or are we at the limit of the engine.

[XPelargos]

Yes. Limit of the engine. Which is limited by the internet. Which is limited by the speed it takes an electron to travel thousands of kilometers. This isn't just a case of "Valve is stupid, hurr durr" this is a problem of titanic proportions.

The math that goes into interpolating where 24 players are in a server all with different pings is mind boggling.

[the_cake]

Certain engines do a better job than others. Source is around the very bottom of the list. goldsrc, every quake engine, warsow, and CoD are examples of good ones. I'm fairly certain cod has some client side mojo going on similar to what I mentioned earler.

The source SDK has a monolithic black box object dealing with the netcode, so there really isn't anything the FF devs can do other than messing with the hitbox sizes/shapes and bullet physics.

[KubeDawg]

Is that for all soruce SDKs or just the 2006 version? Would it be worth it to go to the orange box version to fix some of these issues?

[FDA_Approved]

If there's going to be any big changes such as engine. It's time for a new game. Noone is going to port FF to a newer sdk. And if someone has the resources and is willing to, they're a flat out moron. Lets be perfectly honest FF had it's run, and it's still going. But it's never going to come back, not FF. When the time comes where a community has the resources and wants to see old school fortress gameplay, it's time for a new game. Anything else would be an incredible waste of time.

[KubeDawg]

Time wasted having fun isn't really wasted. I'm not saying it's realistic or even feasible at this point, but I'm just throwing it out there that a newer SDK might be a solution to the problems we are discussing and as I know really nothing about the time and effort it would take to move this to the OB SDK, I couldn't tell you whether or not it's all just pipe dreams or something tangible. As I understood it, trepid jon did a good job at getting a good amount of this mod onto the OB SDK but that stopped. Maybe if we had more developers it would be something to strive for.

I think once HL3 is released and its fantastically new SDK is released to the public, that would be a better option than to just remake this mod. That's what I'd personally like to see as Valve are working hard to make it a lot easier for Developers to make their games in the future and since it only took a matter of months for the OB SDK to be released to the public, I would think that they're going to push even harder to make it available to everyone as soon as it is ready.

[FDA_Approved]

It'd still be infinitely better to make a new fortress on that SDK than to port FF.

Here's FF, it's old as shit and no one plays it! But it's on a new SDK!

We probly have a much better shot at drawing/maintaining a sizable crowd with a new game. Old fortress players will at least check it out. And at least plenty of new people will check it out because it's something new with cool graphics.

[KubeDawg]

But who would make it?

[FDA_Approved]

Who would port FF to OB? It's all hypotheticals right now.

And even if porting FF is easier than making a new game, I still think it'd be worthless.

[squeek.]

Originally Posted by KubeDawg

Valve are working hard to make it a lot easier for Developers to make their games in the future and since it only took a matter of months for the OB SDK to be released to the public, I would think that they're going to push even harder to make it available to everyone as soon as it is ready.

What evidence is there of this? After OB, there has been a gigantic silence on the modding tools front. Source SDK 2009 is likely to never be moddable at this point and it'd be 4 years old even if it was. Things like Hammer are archaic and still full of bugs that will never be fixed. It's sad that the most up-to-date engine version we could port to would only then be 6 years old instead of 7.

It'll be interesting to see how moddable a new Valve engine will be.

But porting FF to OB really wouldn't do too much as far as I'm aware. There are a lot of underlying problems in the FF-specific codebase, lots of code written before there was much understanding of the engine, and it is generally poorly organized (though some of this blame could go to the Source engine which is pretty crazily organized on its own). Porting what is good and rewriting/rethinking what is bad is something I've dreamed about for a while but it's daunting for a couple reasons: 1) I'm not confident that I really have the knowledge required to improve upon the existing codebase; 2) OB has bugs out of the box (most frustratingly, jittery movement) that'd we'd need to deal with and I'm sure there would be a lot that we'd find over time; 3) I am prone to losing motivation rather easily on big projects like that.

[the_cake]

In 2011 Gabe was talking about new development tools. Haven't heard word of them since.

It currently looks like valve plans to continue patching source with new graphics technologies until the end of time, so it's unlikely there will be anything fresh to work with.

Honestly, gogo latest open source quake engine (4 IIRC?) and custom development tools. squeek can do that in like a weekend.

[squeek.]

Quake engines scare and confuse me. I tried a few times to set up a development environment to mess around with for Quake 4 or Doom 3 or w/e and failed each time. Also, I believe the licensing requires that any derivative mods of the open-sourced Quake engines open-source their code as well. Not sure if that'd be a good or bad thing (maybe good?).

[Dexter]

if you make a proper mod without touching the gpl'd client, you dont have to provide source. for example urban terror using ioquake3 client

but yea fuck that lol

[the_cake]

That is correct, the GPL basically forces all derivative work to be GPL'd as well, very thoroughly and from many different angles. If you take, you have to give back. This is why the GPL is the most successful of the open source licenses.

In terms of it being good or bad, it works both ways. If I want to exploit the code, I can. If I want to prevent the code from being exploited, I can. These two opposites also exist in a closed source system. It's harder for me to find exploits since I don't have code access, but you only have the development team to find and fix bugs, as opposed to everyone in the world who wants a look. It's the same, just faster. Where the tables get turned is when the code ages; when you (actually) fix a bug, it's fixed. An exploiter can't "unfix" a bug. Over time the number of bugs/exploits approaches 0. This happens much much faster than in a closed source system. This is one reason time tested free software has a considerably better security record than similar close source software.

Then there's the issue of forking. Cae shit his pants when we played with the rocket physics on a private server, so I'd imagine that would be his primary concern. TBH, a fork is the ultimate form of brutal honesty. If you get forked, you're doing something wrong. It cuts to the chase. Instead of things having to get so bad that someone starts a new project, just fork the old one instead of wasting all the development effort from the previous project. That's how Firefox came to be. Does anyone remember the monolithic mess that was Mozilla before firefox came out? Apache, OSX (it's early ancestors were forks of BSD), OpenOffice, all forks. Historically almost all forks have gone on to be more successful that their originals. It's really a hard thing for a developer to accept that someone else can do a better job, but those who can usually work something out, those who can't get forked.

Anyway enough ranting for tonight, it's 2am already.

[KubeDawg]

Rgr, and here's the article about the new dev tools:
http://www.pcgamer.com/2011/02/23/va...ainful-to-use/

[squeek.]

And nothing has come of it in 2 years. Meanwhile, the improvements we know they have made to the engine since OB (an easy example is Mac support in Source SDK 2009 [Portal 2 engine]) is 4 years old and hasn't been released to modders. Seems more likely that the "new tools" will be for Source 2.

[squeek.]

Originally Posted by the_cake

Then there's the issue of forking. Cae shit his pants when we played with the rocket physics on a private server, so I'd imagine that would be his primary concern. TBH, a fork is the ultimate form of brutal honesty. If you get forked, you're doing something wrong. It cuts to the chase. Instead of things having to get so bad that someone starts a new project, just fork the old one instead of wasting all the development effort from the previous project. That's how Firefox came to be. Does anyone remember the monolithic mess that was Mozilla before firefox came out? Apache, OSX (it's early ancestors were forks of BSD), OpenOffice, all forks. Historically almost all forks have gone on to be more successful that their originals. It's really a hard thing for a developer to accept that someone else can do a better job, but those who can usually work something out, those who can't get forked.

I think FF/TFC/TF in general lends itself towards forking in the same sense that Linux distros get forked. Too many goals to fit into one universal package, so there are a million flavors. Imagine how many forks of TFC would have popped up if it was open source in its heyday. For games, though, it can become a pretty big problem pretty quickly, unless one fork totally dominates all the others (but then I'd be left playing my all bouncing projectile/scout fork by myself ).

Is there an example of forking in games? I guess modding itself is something of a (controlled) fork. Has Warsow been forked? EDIT: Xonotic was a fork of Nexuiz

[Dexter]

warsow hasnt been officially forked, only two real mods to speak of several years ago. First promod - it was a novelty that lasted less than a patch basically. there was also a mod that added tons of stuff + fixes to race called racesow that was around for a while but it wasnt a proper fork either. most of promod is no longer relevant or folded into baseline funny enough and racesow died out


also: promod caused a ton of whine 'omg it will split the community' for like 2 weeks it was awesome

[the_cake]

The success of forks of free/OSS software projects in general depend entirely on community (outside the gaming realm this can include commercial) support. If there are 20 forks of FF and 20 communities that each participate in said fork, there will be 20 forks. This is why there are many linux distros; there are many different uses of an OS so having one geared towards a specific or general purpose will draw it's own set of supporters. If you have something more general, this doesn't really happen. This is why apache or postgresql doesn't have a million forks.

If you have one community and many (or just a couple) forks, fork darwinism takes over. Whichever the most people congregate to will in turn see the most benefit while the others die out. Again it's brutal honesty. You can say whatever you'd like, in the end people will play what they want. What most people want will win over, every time. Then those who realise the projects that are falling behind and can swallow their pride will jump ship and join the most successful variant. This is exactly what happened with firefox.

[squeek.]

Yeah, you might have gotten me dead on about: "It's really a hard thing for a developer to accept that someone else can do a better job."

I love open source, but for some reason it doesn't sit well with me specifically about FF. Everything else I'm all for it, though. Maybe it's a suspicion that the fork that I'd enjoy is the one that would be dominated by the fork that I wouldn't enjoy. "A better job" can be relative in games, while it's far more objective in software.