Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

Newcomers DBPro Corner / Pasting images in rows.

Author
Message
Darkzombies
13
Years of Service
User Offline
Joined: 25th Dec 2010
Location: In multiple tabs, most likely youtube.
Posted: 16th Dec 2011 17:42
Ok so what I want this to do is paste, and then after currbullets (It\'s what I\'m using to track the amount of bullets in the gun, bad name) is over 6, it starts pasting in a new row, but I\'m confused on how to do this.



-------------------------------------------------------------
BatVink
Moderator
21
Years of Service
User Offline
Joined: 4th Apr 2003
Location: Gods own County, UK
Posted: 16th Dec 2011 18:29 Edited at: 16th Dec 2011 18:34


Darkzombies
13
Years of Service
User Offline
Joined: 25th Dec 2010
Location: In multiple tabs, most likely youtube.
Posted: 18th Dec 2011 17:57
It doesn't really work, I need more of an explanation please.

-------------------------------------------------------------
chafari
Valued Member
18
Years of Service
User Offline
Joined: 2nd May 2006
Location: Canary Islands
Posted: 18th Dec 2011 21:49
Try this:




Cheers.


I'm not a grumpy grandpa
Darkzombies
13
Years of Service
User Offline
Joined: 25th Dec 2010
Location: In multiple tabs, most likely youtube.
Posted: 18th Dec 2011 22:24 Edited at: 18th Dec 2011 22:40
Works, but kinda weirdly. (ATTACHED CROPPED PICTURE)
idk though, I'll just mess with it.

EDIT: Never mind, fixed it.

EDIT TWO: Ya know, while we're here, I need help with another problem, the reloading delay isn't working, also, the collision of zombies to zombies is messed up a bit, and this all started after I made the shooting system, I don't see how that messes up a collision and AI system. But anyways, here's the code. (WARNING, ALOT OF CODE!)



-------------------------------------------------------------

Attachments

Login to view attachments
chafari
Valued Member
18
Years of Service
User Offline
Joined: 2nd May 2006
Location: Canary Islands
Posted: 19th Dec 2011 02:09
Quote: "the reloading delay isn't working, also, the collision of zombies to zombies is messed up a bit, and this all started after I made the shooting system"


It is hard to guess what's wrong just reading

What do you mean with the zombies collision messed up after you made shooting system ?? did collision work ok before that?

Cheers.
Darkzombies
13
Years of Service
User Offline
Joined: 25th Dec 2010
Location: In multiple tabs, most likely youtube.
Posted: 19th Dec 2011 07:11
Yeah, it did, its kinda weird, I must of accidently deleted something or something like that, but I've went over it multiple times and can't find the problem. And for the reloading, the delay never stops lol.

Hope that makes it clearer.

-------------------------------------------------------------
nonZero
13
Years of Service
User Offline
Joined: 10th Jul 2011
Location: Dark Empire HQ, Otherworld, Silent Hill
Posted: 19th Dec 2011 19:02 Edited at: 19th Dec 2011 19:07
Could you be more specific about collision problems? Do you mean actual detection or behaviour after collision? Well, I'll take it literally...

I'm gonna skip reading the code and throw some questions out there. They may or may not be useful so think of me as the pixie that gives you ambiguous clues in [insert RPG title].

1. Check your variables and ensure that local is local, global is global and that no duplicated global names exist. Watch out for typos too.

2. Check your flow. Is there perhaps a flag you were using to execute something that you changed? Did you insert something above something else and that something is now taking priority from the something else, modifying a shared resource? Are your IF..ELSE..ENDIFs right? You aren't re-assigning a value to a variable in a loop where you shouldn't?

3. RE your reload delay, i'll assume you are doing something like this:

If so, did you refresh whatever you use for ReloadTimer after running out of ammo?

4. Do you have a backup of your previous code?

Well, if you do backup previous versions of your code regularly, open the current and the last working version in seperate windows and run though your code step-by-step, removing all "new" lines from your current one. This method of debugging is very effective but consumes a lot of time.

EDIT: When you say your delay "never stops" did you mean you can never reload? If so, you need to ensure that the "ReloadTimer" I referred to earlier, is only set to TIMER() once and not again until the gun's run out of ammo again. Say, using the last bullet as a trigger (pardon the pun).

If I think of anything else, I'll edit this post, so
[Watch this space]

Darkzombies
13
Years of Service
User Offline
Joined: 25th Dec 2010
Location: In multiple tabs, most likely youtube.
Posted: 20th Dec 2011 07:08 Edited at: 20th Dec 2011 07:11
Does this clear it up for you? (ATTACHED IMAGE)

and here's the code, I don't see anything wrong with it.





and for the reload, I'm doing this:



(It's at the bottom)

Quote: "When you say your delay "never stops""


By "Never stops" I mean I always am reloading, I wanted it to just be a timer, like the timer is 1.5 seconds long, and thats how long I reload, course I've also assigned a delay to a variable, so for my upgrade menu later on, I can change that delay.

-------------------------------------------------------------

Attachments

Login to view attachments
nonZero
13
Years of Service
User Offline
Joined: 10th Jul 2011
Location: Dark Empire HQ, Otherworld, Silent Hill
Posted: 20th Dec 2011 07:46 Edited at: 20th Dec 2011 08:13
I think there's a problem here (for starters):



You're working backwards which is throwing me off, lol, but from what I can tell, you say in one line if the TIMER() is higher than the ReloadD variable, then the player is not reloading. But the minutte the R button gets pushed, the ReloadD value changes. Technically, by holding R down, you will never reload until releasing it (unless that's what you want).

Now, you also set player.reloading to true. The problem is that player.reloading only = false again so long as the delay goes through correctly (which it won't if I keep holding the R button down.

Not too sure what your variables and structure are pointing to, but I took a guess. This may help:



I'm sure there's more to it though. This was just a problem I noticed immediately.

EDIT: Kay, the zombie collision can be solved like this since you don't need 100% accuracy as they must simply avoid each other. Mold this into your code, adapting where necessary and it should help.



Darkzombies
13
Years of Service
User Offline
Joined: 25th Dec 2010
Location: In multiple tabs, most likely youtube.
Posted: 21st Dec 2011 04:55
Well, for the reloading, what I was intending was to have the player be completely imobilized for a couple seconds, then have the bullets replenished. Can't figure that out. I use "Player.reloading" to keep track of whether he's reloading or not, pressing R turns that on, after the delay it turns off, and the bullets replenish.

And onto the zombies. If you looked through it, I am doing just that, except I'm calculating it for more precise collision. I = a. J = b.

So that doesn't help at all. Don't worry. It has me stumped too. The problem I have with the bullets is I've never had to do anything like it before so its new to me. Thanks for helping.

-------------------------------------------------------------
nonZero
13
Years of Service
User Offline
Joined: 10th Jul 2011
Location: Dark Empire HQ, Otherworld, Silent Hill
Posted: 21st Dec 2011 12:00 Edited at: 21st Dec 2011 15:58
Quote: "...for the reloading, what I was intending was to have the player be completely imobilized for a couple seconds..."


As for wanting to keep your player "immobilized" during reload, simply place your key-controls (or the ones you want to disable) inside an IF, eg:



Quote: " I am doing just that, except I'm calculating it for more precise collision. "


Why precise collision for enemies avoiding one another? Isn't it better if they don't bump into one another at all? Also, you're using the distance formula (without sqrt and ^2, using ABS instead) to calculate distances from what I'm assuming to be the center of your sprites. This is technically no more accurate, unless your enemies are perfect circles (I assumed your picture with circles was just for debugging). For example, you can't cast a radius around 2 squares and get accurate collision. To prevent overlap, you must make the collision radius bigger than 1/2 the diagonals of your each square. Therefore, it is easier to use SPRITE COLLISION and create sprites with an alpha border. Use radial collision for bullet/player hits by all means but getting the enemies not to collide doesn't require these complexities. Will run a test on your code later and see if I can debug it all the same though.

EDIT: Okay, I've had a look at it and there are a few problems:
1. You run two comparisons ie Collision(1,3) and Collision(3,1) at once. So you move both badguys at once, cancelling out your "enemy vs enemy" evasion. I would suggest using PATHFINDING in a situation like this, or at least some geometry. Add "direction" to you enemy UDT and then have 8 directions: N/S/E/W/NE/NW/SE/SW. Then move your enemies based on their direction, eg: If enemy(1).direction = SW then add 1 to y and 1 to x.
Now when you've detected a collision, check the direction of the collided enemy. Now adjust their directions so that they are heading in opposite directions. Set their direction to follow the player BEFORE the collision check so that collision take priority. Because they'll both move at least 1x(Yourspeed) away from each other, they can never properly overlap. That is the best way I can think of without a complete rewrite.
2. You really should:
Look at your code
   Check for nests
   If a nest is found, then
      indent it properly
   Otherwise
      people (like me) aren't motivated to read your code
   Continue looking for nests
Stop looking when you reach the end of your code

...Sorry, couldn't resist

Anyhow, hope that helps a little. I know it requires some effort but it will make the AI more flexible in the long run.

72 97 112 112 121 32 72 111 108 105 100 97 121 115 32 112 112 108 33

Darkzombies
13
Years of Service
User Offline
Joined: 25th Dec 2010
Location: In multiple tabs, most likely youtube.
Posted: 22nd Dec 2011 06:15
I really don't see the need for all that. It worked just fine before, I think I did something too it and it got messed up. BTW it only happens on the right and left sides, collision is fine on the up and down sides.

-------------------------------------------------------------
nonZero
13
Years of Service
User Offline
Joined: 10th Jul 2011
Location: Dark Empire HQ, Otherworld, Silent Hill
Posted: 22nd Dec 2011 11:29
Kay, I think you should allow the distance formula to return a positive OR negative value (*see my example). This value will tell you what side the other zombie is on. This'll make life easier. Also, perhaps consider WHEN you update your sprite locations. atm you're running both checks before updating positions, as I mentioned in my previous post. Also, your initial IF condition, so far as I can tell says "IF both the x and y distance are too close, take evasive manoeuvres, OTHERWISE check collision with player". You need EITHER y-distance OR x-distance to trigger evasive actions. Have a look at this:



It's not brilliant code, but enemies won't collide with each other. This is a very crude but easy way of preventing enemy collision. If your code used to work, either you tried to simplify it and wound up with that conditional problem, or perhaps you just got lucky.

72 97 112 112 121 32 72 111 108 105 100 97 121 115 32 112 112 108 33

Darkzombies
13
Years of Service
User Offline
Joined: 25th Dec 2010
Location: In multiple tabs, most likely youtube.
Posted: 24th Dec 2011 07:15
I don't know, it only is glitching up on one side, which leads me to believe its just something wrong with the X part of it. I don't think its that I've done it wrong, because it partly worked. I was messing around with it, I just messed it up, I really just want a fix, not an entire recode

-------------------------------------------------------------
nonZero
13
Years of Service
User Offline
Joined: 10th Jul 2011
Location: Dark Empire HQ, Otherworld, Silent Hill
Posted: 24th Dec 2011 08:28
I can't find exactly what's wrong here but I'm pretty sure it's an update/flow related issue.

The only other thing I can suggest is try swapping the order of the movement. atm you're prioritising chasing the player over collision. That means:

However, if you switch the code around, eg:

You'll be prioritising evasion of other enemies over following player which means only 1 enemy may attack the player at close range, the rest will avoid there cohorts but possibly flank around the player.


Also, try deleting/commenting-out this piece:

That should tell you for sure if it is because of prioritising.

One other thing that may be influencing things (again why the method in my previous post is better), did you OFFSET any sprites? If you did, then you need to factor the offset into your calculations. They may appear to collide if they are offset, yet their numerical location representations, namely zombie(n).x/y may say otherwise.

Other that that, I can't say for sure. My coding-style is very different and, tbh, I haven't used the old-school method of tracking enemy-locations with enemy.x, enemy.y since I made my last game in QBasic (age 14 or 15).

72 97 112 112 121 32 72 111 108 105 100 97 121 115 32 112 112 108 33

Darkzombies
13
Years of Service
User Offline
Joined: 25th Dec 2010
Location: In multiple tabs, most likely youtube.
Posted: 24th Dec 2011 18:12 Edited at: 24th Dec 2011 18:33
Woah lol, I tried that code you gave me and they all just merged into one lol, at least in my other code they only went into eachother half way O.O

EDIT: I fixed it, the only problem was I did:



But if the enemies get pushed closer then enemy(b).x - 7 they can collide, so I had to do this:



Apparently thats how I messed it up
Oh well, lesson learned. Now can you teach me how to set a timer and have something NOT occur while that timer is active? (Like not being able to shoot while reloading)

-------------------------------------------------------------
nonZero
13
Years of Service
User Offline
Joined: 10th Jul 2011
Location: Dark Empire HQ, Otherworld, Silent Hill
Posted: 24th Dec 2011 22:04
Quote: "Now can you teach me how to set a timer and have something NOT occur while that timer is active? (Like not being able to shoot while reloading)"


You don't need a timer for your character if your reload is already on a timer (you mentioned that in an earlier post that it was... I think).



It won't even check for any input within that IF-statement unless you aren't reloading. I other words, any buttons you want to disable go inside that IF. It's the easiest way to do it.

Quote: "I tried that code you gave me and they all just merged into one lol"

Well they are one, they are legion, no?

Seriously, I'm not surprised something weird happened, it was just for testing purposes to track what was happening. Anyway, glad you've solved the collision problem without having to re-code.

72 97 112 112 121 32 72 111 108 105 100 97 121 115 32 112 112 108 33

Darkzombies
13
Years of Service
User Offline
Joined: 25th Dec 2010
Location: In multiple tabs, most likely youtube.
Posted: 24th Dec 2011 23:57
No no no, thats not the problem, I already did that, I just needed to know how the timer works, I can set a timer when the player presses R (The reload button), but I don't know how I can have the reloading change to true, then change it back without messing it up. I mean, it seems easy, but of course when I attempt it, the timer never runs out, thus I'm forever paralyzed.



So actually, just a fix, not a tutorial I guess

-------------------------------------------------------------
nonZero
13
Years of Service
User Offline
Joined: 10th Jul 2011
Location: Dark Empire HQ, Otherworld, Silent Hill
Posted: 28th Dec 2011 16:05 Edited at: 28th Dec 2011 16:12
Quote: "but I don't know how I can have the reloading change to true, then change it back without messing it up. I mean, it seems easy, but of course when I attempt it, the timer never runs out, thus I'm forever paralyzed."


What you have here:


is a situation where the reload timer only gets checked if R is pressed.

Try adding this to your main loop.



*Just make sure I spelled your variables correctly, I tend to mispell other people's variables

Basically, you need to constantly be checking the reload timer while reload is active, not when reload is pressed.

EDIT: Just food for thought, but you may find it easier in the future to synchronise a variable with the timer on an event, eg:

and then make a direct comparison for your conditions, eg:

PS: That was not a tutorial

72 97 112 112 121 32 72 111 108 105 100 97 121 115 32 112 112 108 33

Darkzombies
13
Years of Service
User Offline
Joined: 25th Dec 2010
Location: In multiple tabs, most likely youtube.
Posted: 29th Dec 2011 06:40 Edited at: 29th Dec 2011 06:42
Thank you, though what I did instead of checking if it was false, is I added an else at the end, pretty much, if player.reloading = false then the player can move, else it checks the timer. Though one thing I still need to fix is that the bullets get restored, THAN it waits a second before allowing me to move again, weird.

BTW this is what I ended up with.



-------------------------------------------------------------
Millenium7
19
Years of Service
User Offline
Joined: 13th Dec 2004
Location:
Posted: 29th Dec 2011 16:45 Edited at: 29th Dec 2011 17:43
i'm going to propose a few theories to you. Ones that i've converted over to

First, i've completely scrapped any goto/gosub commands from my coding, they're ok for beginners but get messy.
Second, move everything out of the main loop, keep it as small as possible and all 'things going on' are executed with functions (or gosub/goto's)
Third (this is most relevant to you). Use your functions in a very dynamic way. For instance at the moment you are detecting if the R key is being pressed and then doing things. I found the more effective way is to instead write along the lines of

Main loop -> Controls (function)-> Reload (function)
Always be running the control function, which in turn will always run the reload function

Now the reason for doing so is that you'll want a reload function with parameters, and it's those parameters (in accordance with the functions rules) that will determine exactly what is happening. Whether it's beginning the reload, waiting for the reload timer, updating a reload progress bar on screen, updating the gun bullets, and even NOT reloading. But call it every single loop

I've started coding like this because it simplifies everything that is relevant to those actions into a single function, making debugging WAY easier. Code is a lot neater, and it's more flexible with less actual coding required

You might start off by writing the reload and control functions like so



This code will compile and run by itself and let you press 'r' to reload or manually set bullet count with 1/2/0 keys. Hopefully you can work out the above. The point of writing this way is to get you in the habbit of writing code that is self sufficient. The benefits to writing reload code the above way is
1)EVERYTHING to do with reloading is handled by the reload function, you need to make any modifications you simply edit the function and no other code
2) You get used to writing code that does not halt or affect your program, it runs alongside anything else that is going on. If you want to impart restrictions, you do it within the function itself. You can simply pause/stop the function by 'not' calling it
3) The function does NOT rely on the triggering of a single action, i.e. pressing the R key. It is going to run anyway (as demonstrated in the main loop), but the function itself decides what happens according to it's parameters. In this instance if it's parameter=0 then it knows it's just updating itself and checking if anything needs to be done, and not to reset the reload timer
4) it's extremely expandable. You can adapt the single function to accomodate the reloading of thousands of units simultaneously. If you write it properly you only need to call reload once, it will handle the individual reload timers, resetting ammo etc. And you only need to call it additional times when a reload event is triggered (enemy runs out of ammo? call Reload(enemyNumber,timer()) for instance)
Millenium7
19
Years of Service
User Offline
Joined: 13th Dec 2004
Location:
Posted: 29th Dec 2011 17:34 Edited at: 29th Dec 2011 17:53
Bonus Code:



This is an example of the control scheme in my game for the marine's (I have 2 vastly different control systems)
This handles keyboard movement and mouse aiming as well as support for xbox360 controller movement/aiming (keyboard/mouse takes preferance over 360 controller). Is done simply by calling



within my control function every single loop. That's it, so if I ever want to adjust my movement system I simply dive into that one function and modify it, no recode of anyhting else necessary as it's the function that returns an end result (Function handles keypresses and works it all out, not the main loop)

Here's my main loop



My program is currently 750 lines long and only contains a single main loop (the one above). It handles everything ingame and out of game including main menu, multiplayer menu's, hosting/joining, game lobby, chat windows, level loading, controls, loading levels+scripts and so on
It'll expand a bit down the track. But at this stage everything to do with a menu system is under the Menu() function. MenuSelection(0) is what is currently highlighted in that menu. The function itself will determine if i'm in the game lobby for instance, or if i'm ingame and somebody has sent a chat message through. The function will show a chat window (a seperate function), but it will position and size itself according to the situation. In game it's much smaller and only contains about 4 lines of text at one time, in a game lobby it's much larger and contains a lot more text at once. It also doesn't disappear, though ingame it'll only show the chat window for 7 seconds after a chat message has been received, then will disappear. It's the same chat window, with the same variables, just dynamically handled without needing my intervention. All of this is handled with a simple Menu(MenuSelection(0)) function. Within that function are seperate catagories and additional outside functions that handle things such as a player joining. When a player joins it'll advertise it in the chat window (in a different text to chat messages), it'll update the new player details on all clients and so on.

Not sure if you'll find any relevance here but I hope it helps
nonZero
13
Years of Service
User Offline
Joined: 10th Jul 2011
Location: Dark Empire HQ, Otherworld, Silent Hill
Posted: 30th Dec 2011 14:29
@Millenium7: Very good example. I myself usually place everything in functions (Except for declarations, I'm old-fashioned about those going above everything, lol). The problem is, I don't think Darkzombies wants to rewrite his entire (or most of his) code, which is what makes this matter complicated. I kinda empathise though, it took me a few years before I was able to "Ctrl + A, Del" 500 lines of code (Once I was able too I realised how much less effort it could be than tryna restructure the whole thing).

@Darkzombies: Here is code WITH a TEMPLATE code FOR your PLAYERINPUT() function. It requires LITTLE MODIFYING to be compatible with your code.
Run the code below and you'll see there's NO freezing after reload other than the waiting period specified:



72 97 112 112 121 32 72 111 108 105 100 97 121 115 32 112 112 108 33

Darkzombies
13
Years of Service
User Offline
Joined: 25th Dec 2010
Location: In multiple tabs, most likely youtube.
Posted: 31st Dec 2011 05:28
Ok, that makes more sense, thanks!

-------------------------------------------------------------

Login to post a reply

Server time is: 2024-11-23 23:53:26
Your offset time is: 2024-11-23 23:53:26