using continue

Questions about the LÖVE API, installing LÖVE and other support related questions go here.
Forum rules
Before you make a thread asking for help, read this.
Alex
Prole
Posts: 30
Joined: Mon Mar 09, 2009 1:49 pm

Re: using continue

Post by Alex »

It is important to keep in mind that what may be standard practice in one language may be very hard to do in another. Often this does not mean that the language that is making things difficult is lacking a basic feature, rather there are just other ways of doing what you're trying to do that suit the language better. Moving to a new language means learning more than the syntax, but also these paradigms that are not necessarily visible at first glance.

I would advise rethinking the entire reasoning behind why you need these features. If you like, share some sample code with the forum and we can try to point you towards something that might be a little more idiomatic for Lua. This might be a lot easier than trying to solve a problem that doesn't have an easy answer.
User avatar
Kaze
Party member
Posts: 189
Joined: Sat Jul 19, 2008 4:39 pm
Location: Dublin, Ireland

Re: using continue

Post by Kaze »

Sparx wrote:I startet Lua 3 weeks ago. You can find your way arround continue and breaking out of more than 1 slope... BUT:
These things are sooo basic to me and I don't likke integrating an external lib just for a continue.... It should be somehow integrated into LÖVE....
Yes, I agree that Lua should have a continue statement, but no. It shouldn't be included in LÖVE.. Just look at GMod's Lua.. Ugh.
User avatar
bartbes
Sex machine
Posts: 4946
Joined: Fri Aug 29, 2008 10:35 am
Location: The Netherlands
Contact:

Re: using continue

Post by bartbes »

Alex wrote:I would advise rethinking the entire reasoning behind why you need these features. If you like, share some sample code with the forum and we can try to point you towards something that might be a little more idiomatic for Lua. This might be a lot easier than trying to solve a problem that doesn't have an easy answer.
I have to agree, there are always ways around it, which might be cleaner anyway, because continue is kind of weird as a statement, let me explain that. You're telling the computer to loop, and instead of telling it when to stop, you keep telling it to continue, doesn't seem like something you'd normally do, does it?
User avatar
Sparx
Party member
Posts: 125
Joined: Thu Apr 02, 2009 9:54 am
Location: Aachen, Germany

Re: using continue

Post by Sparx »

@bartbes I don't understand what you want to tell me...
I am using for example the following loops: 1. loop goes through all players... 2.loop goes through all bullets of player X the first test is if bullet hits another player 2. hits terrain and after that and bullet is still alive let bullet fly to new destination. But: i want to delete the bullet if it hits something. I set all its variables to nil and then i NEED to continue because otherwise.... I know i can use 2 simple ifs for this... but what if i integrate movable objects that can be hit and many other entities, then i need an if for every entity-type chekced for intersection. A simple continue looks much cleaner and doesn't let me end up in the 15th tab because of code-formating end having 15 "end"s after each other doesn't make it easier to see which end belongs to which if (or in my mind to which continue).

Now anyone tell me what the nice lua way is, I'm very curious.
P.S: What can I do to make the lua guys integrate it?
User avatar
bartbes
Sex machine
Posts: 4946
Joined: Fri Aug 29, 2008 10:35 am
Location: The Netherlands
Contact:

Re: using continue

Post by bartbes »

Sparx wrote:P.S: What can I do to make the lua guys integrate it?
Nothing, they chose for this. Maybe they are going to change their mind once, but this was definitely a design choice.
Alex
Prole
Posts: 30
Joined: Mon Mar 09, 2009 1:49 pm

Re: using continue

Post by Alex »

Sparx wrote:@bartbes I don't understand what you want to tell me...
I am using for example the following loops: 1. loop goes through all players... 2.loop goes through all bullets of player X the first test is if bullet hits another player 2. hits terrain and after that and bullet is still alive let bullet fly to new destination. But: i want to delete the bullet if it hits something. I set all its variables to nil and then i NEED to continue because otherwise.... I know i can use 2 simple ifs for this... but what if i integrate movable objects that can be hit and many other entities, then i need an if for every entity-type chekced for intersection. A simple continue looks much cleaner and doesn't let me end up in the 15th tab because of code-formating end having 15 "end"s after each other doesn't make it easier to see which end belongs to which if (or in my mind to which continue).

Now anyone tell me what the nice lua way is, I'm very curious.
As a rule of thumb, if you have more than four or five levels of indentation (although this really changes from language to language, I'd say four to five is around the upper max for Lua) then you're doing something wrong. When this happens it is usually either a sign that you have code that can be abstracted out into functions or you are misusing the control structures of the language. It's kind of hard to tell from your verbal description (again, feel free to post some actual code) but I have a feeling that the code you're describing may not be very well separated into functions. If this isn't the case (or even if it is), then break or return should probably provide the necessary control to avoid excessive nesting. Without seeing any code, there's not much more I can say.
User avatar
Sparx
Party member
Posts: 125
Joined: Thu Apr 02, 2009 9:54 am
Location: Aachen, Germany

Re: using continue

Post by Sparx »

Ok here comes the serverside bullet-impact test routine...

Im sorry there are no comments... but i give some information here:
index is going through all players that are connected just as index3 to
index2 is going through all bullets shot by player[index]
shootwait is delaying the time between 2 shots

the locals tx and ty are the bulletspeeds divided into small parts(this no raycasting to save serverspeed, precision is set via SHOTPRECISION)
(!I know SHOTPRECISION is NOT the length of each step but provides a rough classification of distances beeing checked (i wanted to leave math.sqrt because of speed reasons))

the 4th for loop is the actual check for each step

bulletcreated is the time the bullet was created on the server and provides the clients with a unique id.

bullettype specifies the kind o bullet like pistole, MG.... at the moment there is just one, thats the reason health is always - 3 for legshot... (i was too lazy to integrate the bulledamages if there is just 1 weapon)

The rest should be self explaining.. I know this is not much of loops for a game of this size but im afraid i am going to add more different entities that can be hit

Code: Select all

	for index,content in pairs(PlayerIP) do
		if(move[index]["shooting"]==1 and shootwait[index]<=0) then createBullet(index) end
		if(shootwait[index]>0) then shootwait[index]=shootwait[index]-dt end
		for index2,content2 in pairs(bulletx[index]) do
			if((love.timer.getTime()-bulletcreated[index][index2])>alivetime[bullettype[index][index2]]) then
				deleteBullet(index, index2)
			else
				local tx=bulletdx[index][index2]*dt
				local ty=bulletdy[index][index2]*dt
				local temp=math.max(math.abs(tx),math.abs(ty))
				temp=math.floor(temp/SHOTPRECISION)
				tx=tx/(temp+1)
				ty=ty/(temp+1)
				for i=0, temp do
					bulletx[index][index2]=bulletx[index][index2]+tx
					bullety[index][index2]=bullety[index][index2]+ty
					temp2=0
					for index3,content3 in pairs(PlayerIP) do
						if(health[index3]>0 and index3~=index) then
							temp=PointInPlayer(bulletx[index][index2],bullety[index][index2], index3)
							if(temp~=0) then
								temp2=1
								if(temp==1) then
									health[index3]=health[index3]-3
									checkkilled(index, index3)
									lube.server:send("BULLETINFO#LEG#"..bulletcreated[index][index2].."#"..index3.."#"..health[index3].."#")
								end
								if(temp==2) then
									health[index3]=health[index3]-10
									checkkilled(index, index3)
									lube.server:send("BULLETINFO#TORSO#"..bulletcreated[index][index2].."#"..index3.."#"..health[index3].."#")
								end
								if(temp==3) then
									health[index3]=health[index3]-30
									checkkilled(index, index3)
									lube.server:send("BULLETINFO#HEAD#"..bulletcreated[index][index2].."#"..index3.."#"..health[index3].."#")
								end
							end
						end
					end
					if(temp2==1) then deleteBullet(index, index2) break end
					temp, ttx,tty=PointInPolygon(bulletx[index][index2],bullety[index][index2])
					if(temp==1) then
						lube.server:send("BULLETINFO#TERRAIN#"..bulletcreated[index][index2].."#"..ttx.."#"..tty.."#")
						deleteBullet(index, index2)	
						break
					end
				end
			end
		end
	end
Alex
Prole
Posts: 30
Joined: Mon Mar 09, 2009 1:49 pm

Re: using continue

Post by Alex »

It would seem that you need to abstract your code into functions if you want to make anything cleaner. Having all of your bullet creation, deletion, hit detection, and networking code together in a giant loop is a big sign that you should be breaking things into smaller chunks or it'll just get uglier when you need to add more things. I would also suggest more meaningful variable names (although this is less important with smaller functions). The only place where I see that the actual Lua code could be enhanced is in the if(temp==~) checks, you could be using elseif's, although there's also a lot of code duplication going on there which is another sign of trouble. In any case, I feel that the control structures that you are missing would only serve to tangle things up even further.

I have to wonder why your server needs to know all of this information about bullets. I'm no networking expert, but from what I know that sort of thing is generally handled by the client that is doing the shooting and approximated by any clients that are being shot at. The server then only needs to know a rough state of affairs which means that there is less bandwidth consumed and less computing being done by the server.

These are all just suggestions that are meant to be helpful. Feel free to disregard all of it. Kudos on having the guts to tackle a multiplayer game in the first place! I'm looking forward to see how this turns out.
Post Reply

Who is online

Users browsing this forum: Ahrefs [Bot], Google [Bot] and 44 guests