View topic - Stop messing up my scripts.


All times are UTC + 1 hour


Post new topic Reply to topic  [ 7 posts ] 
Author Message
PostPosted: 15 Jun 2009, 10:58 
MechCommander Developer
User avatar

Joined: 21 May 2007, 01:09
Location: New Zealand
I know CA is a collaborative project. I know my work is PD, and thus free to use/modify/derive.

BUT FOR THE LOVE OF GOD, COULD YOU PLEASE STOP MESSING UP MY SCRIPTS WHEN YOU COMMIT THEM TO CA!

(1) Those sleeps are there for a reason. It stops retardedness like the shot coming from a different place to the fx.

Code:
if( gun1 == 0 )
{
   sleep 30;
   emit-sfx 1024 from rflare1;
   emit-sfx 1025 from rbarrel;
}
if( gun1 == 1 )
{
   sleep 30;
   emit-sfx 1024 from lflare1;
   emit-sfx 1025 from lbarrel;
}
if( gun1 == 2 )
{
   sleep 30;
   emit-sfx 1024 from rflare1;
   emit-sfx 1025 from rbarrel;
}
if( gun1 == 3 )
{
   sleep 30;
   emit-sfx 1024 from lflare1;
   emit-sfx 1025 from lbarrel;
}

gun1 = 1 + gun1;

if( gun1 == 4 )
{
   gun1 = 0;
}


(2) //linear constant 65536
It's not a suggestion (although i did forget to make the notation on some of my units, its not an excuse for commiting clearly [now] broken scripts.)

(3) wtfaimingcode. C'mon. What do you expect a function like this to do?

Code:
AimWeapon2(heading,pitch)
{               
   wait-for-turn torso around y-axis;
   wait-for-turn launcher around x-axis;
   return (1);
}


Use my models, use my scripts. Thats why they are there, freely available. But PLEASE, don't make me look sloppy and incompetent by failing to check that scripts actually work before you commit.

I thoroughly test my scripts, to ensure that the people who use my units get a quality, ready-for-use product. The least you can do is respect the work I put into writing those scripts and impliment them properly.
Top
 Offline Profile  
 
PostPosted: 15 Jun 2009, 14:58 
Map Creator
User avatar

Joined: 10 Mar 2006, 10:24
Location: waiting in line for The Expendables 2
hey, thats my code- you just put some sleeps in!
Top
 Offline Profile  
 
PostPosted: 15 Jun 2009, 15:04 
Moderator
User avatar

Joined: 19 Sep 2006, 21:48
needs moar comments

eg.
Code:
if( gun1 == 0 )
{
   sleep 30;  // It stops retardedness like the shot coming from a different place to the fx.
   emit-sfx 1024 from rflare1;
   emit-sfx 1025 from rbarrel;
}


If there is a line that looks unneeded and it's not commented, someone will eventually remove it. It might even be done by you, a few months from now.
Top
 Offline Profile  
 
PostPosted: 15 Jun 2009, 21:36 
Moderator

Joined: 19 May 2009, 20:10
quantum wrote:
needs moar comments

That's true for every part of CA source code.
Top
 Offline Profile  
 
PostPosted: 15 Jun 2009, 22:18 
Moderator

Joined: 22 Aug 2006, 15:19
just wanted to say that quantum is 100% right - code that exists for a reason only one person knows about is a bug, even if it's only of the documentation kind.
Top
 Offline Profile  
 
PostPosted: 16 Jun 2009, 02:45 
Kernel Panic Co-Developer
User avatar

Joined: 16 Nov 2004, 13:08
A more sensible method would be: If you don't understand what a bit of code do, leave it! And if you do remove it nonetheless, then check ingame that the behavior is the same after and before. But considering how CA dev and Spring dev intersect, this thread made me understand why Spring releases are getting increasingly broken.I'm sooo gonna be hated for posting that.
Top
 Offline Profile  
 
PostPosted: 16 Jun 2009, 07:08 
MechCommander Developer
User avatar

Joined: 21 May 2007, 01:09
Location: New Zealand
zwzsg wrote:
A more sensible method would be: If you don't understand what a bit of code do, leave it! And if you do remove it nonetheless, then check ingame that the behavior is the same after and before.


Exactly. Imo a part of the problem (at least in this [these?] case[s]) is that there is a mentality of simply committing things as fast as possible and then fixing things when people complain about them being obviously broken. iow using a 'change-> commit-> test-> fix-> commit' dev flow.

with an svn system (like CA) its just as easy to use a 'change-> test-> fix-> commit' process which works fine for things that are obviously broken. sometime non-obvious things do get broken, and its only through thorough multi-user stress testing that the bug or flaw can be revealed and tracked down, those are undesirable, but much harder to avoid. Whereas I identified the problems in OP in ~30 seconds of testing (things like a move cob command moving something 2x as far as it should are generally relatively easy to spot, same with turrets not waiting until they are aimed to start shooting)

tl/dr: Its not a race, when you act in haste, you make mistakes. test THEN commit, it only takes a minute to see obviously breoken behaviour.
Top
 Offline Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 7 posts ] 

All times are UTC + 1 hour


Who is online

Users browsing this forum: No registered users and 0 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group
Site layout created by Roflcopter et al.