Stop messing up my scripts.

Stop messing up my scripts.

A dynamic game undergoing constant development and refinement, that attempts to balance playability with fresh and innovative features.

Moderator: Content Developer

Post Reply
User avatar
Pressure Line
Posts: 2283
Joined: 21 May 2007, 02:09

Stop messing up my scripts.

Post by Pressure Line »

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: Select all

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: Select all

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.
User avatar
1v0ry_k1ng
Posts: 4656
Joined: 10 Mar 2006, 10:24

Re: Stop messing up my scripts.

Post by 1v0ry_k1ng »

hey, thats my code- you just put some sleeps in!
User avatar
quantum
Posts: 590
Joined: 19 Sep 2006, 22:48

Re: Stop messing up my scripts.

Post by quantum »

needs moar comments

eg.

Code: Select all

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.
SirMaverick
Posts: 834
Joined: 19 May 2009, 21:10

Re: Stop messing up my scripts.

Post by SirMaverick »

quantum wrote:needs moar comments
That's true for every part of CA source code.
imbaczek
Posts: 3629
Joined: 22 Aug 2006, 16:19

Re: Stop messing up my scripts.

Post by imbaczek »

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.
User avatar
zwzsg
Kernel Panic Co-Developer
Posts: 7049
Joined: 16 Nov 2004, 13:08

Re: Stop messing up my scripts.

Post by zwzsg »

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.
User avatar
Pressure Line
Posts: 2283
Joined: 21 May 2007, 02:09

Re: Stop messing up my scripts.

Post by Pressure Line »

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) 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.
Post Reply

Return to “Zero-K”