[Kazan]

those mission specific hacks can be removed if you rework the mission


hasn't V ever heard orf beam-lock-all

[karajorma]

I'm usually against anything that would break backwards compatability but since these breaks would apply only to individual missions and wouldn't affect other campaigns I'm all for removing them.

[diamondgeezer]

Are they actually going to be causing a performance drain or are they just untidy for the coders?

[RandomTiger]

Originally posted by Kazan
those mission specific hacks can be removed if you rework the mission

1. It seems unlikely that V would put such a nasty hack into the code if there was an easy way around to get exactly the same effect.

2. If we rework the mission then theres no guarentee everyone will download it (even if it is part of our main vp) and we could well spoil the FS2 experence for one or many people.

One if and a bit of code every frame, so what?
Its not going to make a big difference.
If anyone disagrees put timerbars round the code and prove it.

[Kazan]

RandomTiger: there is absolutely no excuse for such hacks... period

[RandomTiger]

Originally posted by Kazan
RandomTiger: there is absolutely no excuse for such hacks... period

Yes there is, if your boss tell you do something and he pulls rank you have to do it. I've been there before and I got very angry but in commercial situations this kind of stuff happens. Usually because publishers are breathing down peoples necks and making unreasonable damands.

I totally agree, its a terrible thing and hacks like this often cost more in the long term than they save in the short term.

But consider my worst fear. We fix the mission, remove the code. Hyperthetical simon (who hasnt played the mission much or at all) downloads the exe, doesnt download the vp (this could be for many reasons).

Simon plays the mission, it plays badly because he has neither the fixed mission or V's hack. But the game doesnt crash, he just thinks its rubbish and doesnt say anything. We've spoilt V's game for someone and noone even knows.

[RandomTiger]

To justify removing this code I believe it must require one of the following to be true:

1. The code causes a significant slowdown.
2. The code is blocking developement.

[Flipside]

'-Disable [v] Hacks' on the launcher perhaps?

EDIT : Good point RT, it's not going to effect anything except in those specific missions.

[aldo_14]

Code: [Select]


if((Math.random()>0.5)&&(deadline.up****Creek())
       code.insert(hacks.getHacks());


Is there any way of checking & noting whether or not the original VPs' are in use?  Or, more specifically, is there any way you could shuntify the mission specific hacks into a seperate chunk of code ( can you subclass it atall?) that's only used if it's an original V mission / vp?  

sorry if this is daft, have no idea how the architecture of the code is or how much scope V left in for subclassing - and I've just spent the last 8 hours staring as other code, and my eyes feel like piss-holes in snow.......

EDIT:  (sigh)

[RandomTiger]

Deadlines dont have to == hacks but usually do and fs2_open will have hacks from FS1, FS2 and any other games it was used for. Im much more worried about overal structural problems we have.

Its a hack, good point, its a real shame, lets move on.

[CP5670]

But consider my worst fear. We fix the mission, remove the code. Hyperthetical simon (who hasnt played the mission much or at all) downloads the exe, doesnt download the vp (this could be for many reasons).

Simon plays the mission, it plays badly because he has neither the fixed mission or V's hack. But the game doesnt crash, he just thinks its rubbish and doesnt say anything. We've spoilt V's game for someone and noone even knows.

How about having a second "core" VP containing such required files only and including it with all major FSO versions? Since it will only have a couple of files (things like this, along with the updated campaign file and maybe a few other things), it would be small enough to go into the main package without affecting the filesize much.

[Bobboau]

no good reason to remove it,
other than it's ugly, but that isn't good enough
haveing this disabled by flags would probly make it slower than it already is (wich isn't much)
I only pointed this out for entertainment purposes

[RandomTiger]

Originally posted by Bobboau
no good reason to remove it,
I only pointed this out for entertainment purposes

It was worth pointing out, I just didnt want a pointless witch hunt to start on code that really isnt hurting performance or developement even though it is a horrible dirty hack.

[mikhael]

So basically, cleaning the code has been thrown out as a project goal?

[RandomTiger]

Oh dont be so dramatic!

Im constantly cleaning code, a week or so ago I purged software, glide, direct draw, texture sections in D3D, moved some D3D specific code under and general graphics interface.

Clean code that worth cleaning. Currently this code isnt hurting anyone and theres no way to fix it as far as I can see without causing Simon Syndrone.

This hack is not worth the time we have already spent on it.