variables and integers and scripts, oh my

I'm having a problem with script 2, it only runs the last section, no matter what i change mapvar0-1 to.

#include "zcommon.acs"

int mapvar0;
int mapvar1;

script 1 OPEN
{
	sector_setceilingscale(3,0,32,0,0);
}

script 2 (void)
{
	if(mapvar0 == 0);
	{
		if(mapvar1 == 0);
		{
			print(s:"Main train gate must be opened and service walkway must be lowered first");
		}
	}

	if(mapvar0 == 1);
	{
		print(s:"Main train gate must be opened first");
	}

	if(mapvar1 == 1);
	{
		print(s:"Service walkway must be lowered first");
	}

	if(mapvar0 == 1);
	{
		if(mapvar1 == 1);
		{
			print(s:"Powering up train engines");
			delay(20);
			print(s:"Proceeding to next installation");
			delay(50);
		}
	}
}

script 3 (int arg1)
{
	if(arg1 == 0);
	{
		mapvar0++;
	}

	if(arg1 == 1);
	{
		mapvar1++;
	}

}

I gather you're setting up outcomes for possible combinations of two variables - so I've set it out in a simpler way:

script 2 (void)

{
if(mapvar0 == 0)
if(mapvar1 == 0)
{
    print(s:"Main train gate must be opened and service walkway must 
    be lowered first");
}

if(mapvar0 == 1)
if(mapvar1 == 0)
{
    print(s:"Main train gate must be opened first");
}

if(mapvar0 == 0)
if(mapvar1 == 1)
{
    print(s:"Service walkway must be lowered first");
}

if(mapvar0 == 1)
if(mapvar1 == 1)
{
     print(s:"Powering up train engines");
     delay(20);
     print(s:"Proceeding to next installation");
     delay(50);
}
}

first off get rid of the semi-colons after the if statements since that signifies the end of the line and pretty much causes that line to be ignored which in turn will cause everything to be executed (UD's post still has them in btw)

edit: heh nevermind he removed them :P

Cyb said:

first off get rid of the semi-colons after the if statements since that signifies the end of the line and pretty much causes that line to be ignored which in turn will cause everything to be executed

Ah, that was my problem. I feel less like an idiot now. :P

Whoo hoo. More problems with variables. For some reason only the last part works.

script 9 (void)
{
	if(mapvar2 == 0)
	{
		print(s:"Two more remain");
		mapvar2++;
	}

	if(mapvar2 == 1)
	{
		print(s:"One more remains");
		mapvar2++;
	}

	if(mapvar2 == 2)
	{
		print(s:"Sequence complete");
		floor_lowertolowest(9,8);
	}
}

The problem is that it increses your variable mapvar2 and then continues to the next check which also results in True and same for the final check.

Change the order of your checks:

	if(mapvar2 == 2)
	{
		print(s:"Sequence complete");
		floor_lowertolowest(9, 8);
	}
	if(mapvar2 == 1)
	{
		print(s:"One more remains");
		mapvar2++;
	}
	if(mapvar2 == 0)
	{
		print(s:"Two more remain");
		mapvar2++;
	}

Or use the Else If statement:

	if(mapvar2 == 0)
	{
		print(s:"Two more remain");
		mapvar2++;
	}
	elseif(mapvar2 == 1)
	{
		print(s:"One more remains");
		mapvar2++;
	}
	elseif(mapvar2 == 2)
	{
		print(s:"Sequence complete");
		floor_lowertolowest(9, 8);
	}

Or better yet, use the Switch statement:

	switch(mapvar2)
	{
	case 0:
		print(s:"Two more remain");
		mapvar2++;
		break;
		
	case 1:
		print(s:"One more remains");
		mapvar2++;
		break;
		
	case 2:
		print(s:"Sequence complete");
		floor_lowertolowest(9, 8);
		break;
	}

Actualy all he needs is an else after each {} section. All better. The first "correction" btw is also invalid, hence the recommendation to use 'else' which guarantees you won't execute no matter what the order of checks is, although if done in the right sequence if could have worked. An else is also slightly faster since it avoids the extra 'if' checks. (ah I see he fixed it, but there is no elseif in ACS:))

if/else vs switch/case is a close call for something this tiny. It's not a hard and fast rule since switch also involves overhead that is not obvious. However, for long stuff switch/case tends to be an easier read, but if it's done a lot, then performance has to be considered:)

script 2 could also use some else(s) in there. The way it sits it can execute multiple prints. The revised one is syntactically incorrect, but will work too once fixed - "else" is still recommended in that one. Can be slightly smaller/faster by not checking the same state more than once.

Pfff, this is a simple ACS script deep, execute speed is neglectible here. Its not code for a nodebuilder :P

I disagree. You always have to be aware of the overhead. ACS can kill a level's responsiveness - trust me. It's a learning thing and this is as good a place as any to learn. Besides I said "if it's done a lot":P

Heh. I would have just put "terminate" inside each of the if statements. :P

Well you could (also return if this was a function()) but that's considered bad coding practice to do this randomly throughout a block of code. You'd have to work with lots of code to see why this sucks. It's similarly bad to use "goto" - both can be a bitch to follow.

It's another of those "rules" that you can break, but you should have a good reason and this isn't one of them.

Thanks codeimp, your first suggestion worked perfectly. Deep, don't confuse me. I'm not a leet coder.

I amd not a coder either. Well, I do know BASIC, and do kind of know the 3vils of goto, but I don't see why sticking terminate in there would do anything to harm the script.

deep said:

I disagree. You always have to be aware of the overhead. ACS can kill a level's responsiveness - trust me. It's a learning thing and this is as good a place as any to learn. Besides I said "if it's done a lot":P

I want to see that. With FraggleScript which is interpreted ASCII I'd expect this but any normal sized ACS script shouldn't be an issue at all. There are far worse bottlenecks in Doom's code which have more impact. If ACS execution time exceeds 2% of the total time required for one game tic it's a lot.

str message[3] = { "Two more remaining", "One more remaining", "Sequence complete" };

script 9 (void) {
       print(s: message[mapvar2]);
       if(mapvar2 == 2) {
                floor_lowertolowest(9, 8);
       }
}

Just another way it could be done (Maybe... I don't do so well when pulling it out of my head, I usually make small mistakes)

edit: heh, forgot a '{'
and a ';'

Graf Zahl said:

I want to see that. With FraggleScript which is interpreted ASCII I'd expect this but any normal sized ACS script shouldn't be an issue at all. There are far worse bottlenecks in Doom's code which have more impact. If ACS execution time exceeds 2% of the total time required for one game tic it's a lot.

First of all, you both missed the point of my posts which is this: One should always be aware of the overhead of code. The else solution was the preferred one, but instead he picked the one where he had nothing more to learn. Good or bad?

Secondly, it's real easy to get ACS to impact a level - just do an infinite loop with 1 tic waits checking for some event and now do a bunch of them in different scripts at the same time. FYI there are ACS combined scripts over 64kb - so "normal" is clearly not what I'm directing my comments towards.

Anything that speeds up code for free should always be considered. To not do so leads to insiduous slower and slower code in any form. Interestingly RH is actually notorious for carrying this to the extreme in some places where it really did not matter, but he saw a saving of a few cycles. I can relate to that :)

I think FS does a 1-time interpret and then it's P-code like ACS? Not sure, but somebody from Legacy can verify this. If not, then it should be done this way :P

The idea here is not to argue about opinions, but to realize that code in various forms (with the same end result) has a differing amount of impact. One balances speed against readability or "fool proofness" of doing code.

Coding is often not black and white as anyone that pays attention to the solutions can see. That's why coding has a learning curve and arguably is an "art". And how do you learn except by realizing that all code is not created equal :)

Xaser said:

I amd not a coder either. Well, I do know BASIC, and do kind of know the 3vils of goto, but I don't see why sticking terminate in there would do anything to harm the script.

Like I said, it's considered bad practice. That's not to say that this is not done (as are "goto" habits). Sometimes extra exits it makes code easier to read by avoiding huge indenting and lots of extra "if" stuff. Simple stuff like this should not start a bad habit:)

It's preferred to have one entry point and one exit point per function. You won't realize why this is so, until you look at a very long function that someone else wrote and try to decipher all the various exits with various return values and this "harmless" habit can drive you nuts. But like I said above, there are good reasons to sometimes do this since it actually make the code easier to follow.

IOW, this is not about if the code executes correctly or not, but the human element.

OMGOMGmogGMO doublepost!!!!!111!!11122334456778890---====backspaceinserthomepageupnumlock//***----

more crap

	setlinespecial(8,102,32);

acc is bitching about the number of arguments, but I've tried everything.

ravage said:

more crap

	setlinespecial(8,102,32);

acc is bitching about the number of arguments, but I've tried everything.

I think you have to specify all 5 args which would make this:

setlinespecial(8, 102, 32, 0, 0, 0, 0);

Well, acc isn't bitching about it anymore, but it's not doing anything.

102 is for scrolling up, but it's not doing anything at all.

Specials

The ones with a '*' have to be used on lines. They don't work in scripts.

102 is one of these, you will have to use scroll_both or set the line to 102

Scroll_both doesn't work either. I'm guessing it doesn't work on 2s lines.

I'm having yet another problem, this time with thing_spawn. It's not spawning at the right zheight, which is set on the mapspot. To show you what I mean: (It's near the very end, behind the lasers what need 3 switches.

http://manifesteddestiny.com/ravagedw/temp/

I think the Scroll_Texture_Both args are different when used on a script compared when used on a line. They do work on 2-sided lines, as I've used it on them.

Nevermind, I fixed the problem. I was usuing an outdated version of acc. And I used spawnspot to spawn the bridges.

Edit: New problem. Where can I get a list for 'inventory_item', and how do I create a pickup for the pistol?

Edit2: Also, despite that the zdoom wiki says that translucent actions can be used in acs, but I've yet to get it to work.

	TranslucentLine(10,64);

Do this in the console:

logfile log.txt
dumpclasses inventory

To get a pistol pickup, use the decorate lump to create it:

pickup Handgun

{
DoomEdNum 20041
SpawnNum 171
Sprite PIST
Frames "A"
PickupMessage "You got the pistol!"
PickupSound "misc/w_pkup"
Respawns
Radius 8
Height 16
}

and when you place it in a map, get it to run this script when you pick it up:

script 0 (void)

{
GiveInventory ("Pistol", 1)
}

pickup Xpistol
	{
		DoomEdNum 20001
		Sprite PISS
		Frames "A"
		PickupMessage "You got an extra pistol."
		PickupSound "*wpnup"
	}

This crashes Zdoom, but I don't know why.

Edit: Nevermind, that wasn't the problem at all. The problem involved a script related to it.