Mar 8 2003, 10:47 am
In response to Garthor
|
|
Rii
 |
Ive changed that
|
Also, in Bumped(O), which I assume is set up thusly:
atom/proc/Bumped(atom/movable/O) src would be the thing being bumped, whereas O would be the thing bumping it. | |
Ahem
Another problem I notice is the use of both usr and src in the Death() proc... However, the use of usr in that proc has nothing to do with the HUD addition in the other proc... So, the code in question is fine... He was wondering why the HUD didn't appear... Not why his Death() proc wasn't adding stats correctly, or anything else... And his use of usr is not the problem with the HUD creation and addition (at least not in the code provided)... | |
How can't you understand them? atoms are mobs, objs, and turfs. atom/movables are mobs and objs. Just like mob/whatever is a type of mob.
| |
Bumped() procs should be set up like this:
atom What's happening here is this: A moving object (a mob, usually) bumps into another object... That causes it to call its Bump() proc (built-in, so it happens automatically)... The argument in the Bump() proc is whatever thing the mob bumped into... (in this case, we define it to just be any type of atom (atom/A)) We then create a new proc named Bumped() that has atom/movable/A as its argument (atom/movable includes any mob and any object) and have the Bump() proc call the Bumped() proc of whatever thing just got bumped into... We pass the bumper into the bumped thing's Bumped() proc, so it can be used there... Here's a more simple way of thinking about what's going on: [Object 1] bumps into [Object 2] This calls [Object 1].Bump(Object 2) That calls [Object 2].Bumped(Object 1) And in [Object 2].Bumped(Object 1) we can write a proc that can affect both Object 1 and Object 2... In [Object 2].Bumped(atom/movable/A), Object 2 will be src, and Object 1 will be A... The thing to remember is that in Bumped(), src is always the mob that got bumped (probably an NPC in your game), not the mob that did the bumping (probably you or another player)... So, to set up a battle for both players, we override mob.Bumped() like this: mob First of all, I changed the argument definition a bit... Instead of being atom/movable/A, I changed it to just mob/M... mob/M is still a part of atom/movable, but it cuts out the obj possibility...which is fine, because I don't think obj's will be going into battle...lol Plus, some of the variables used in the proc only belong to the mob type, and not to the atom type, so it would give us errors if we used atom/movable/A... If this is confusing, just don't worry too much about it and take it for granted that it works...lol You can figure it out later once you've learned a bit more... Anyways, this new Bumped() proc will check both mobs involved to see if they're players with clients, and then add the HUD objects to their screens (that way, it can also be battle between two players, not just a player vs an NPC)... And that's how to set up the battle... Another problem you have is your Death() and DeathCheck() procs... The way they should be handled is this: In battle, after every time damage is dealt, you should call the DeathCheck() proc... The DeathCheck() proc should take an argument that corresponds to the mob that did the damage (src will be the mob that was damaged)... Plus, everything can be moved right into the DeathCheck() proc, and the Death() proc can be gotten rid of (just for simplicity's sake... it would still work with using both procs, but it's not necessary, so it can be taken out) mob Now, whenever a a mob attacks another player, you call that player's DeathCheck() proc with the attacker as the argument... The DeathCheck() proc will check the attacked player's HP, and do the death stuff... It will remove all Battle_HUD objects from both of their screens (if they both have clients... or just from the mob with the client) In this proc, src is the mob that died, and M is the mob that won the fight... So, all stats and leveling up must be done to M and not src... And all dying things must be done to src... | |
Thats worked now, but when I compile I have 3 new errors and I havent got a clue how to change them, here they are:
Battle.dm:118:error:O/:/Bumped:undefined proc Battle.dm:44:error:Bumped :undefined proc Battle.dm:98:error:Bumped :undefined proc How could I solve those? | |
Basically, the HUD doesnt show up when you enter battle, and once a battle is finished the player freezes, are there any parts of the coding that could be causing this? Or is it somewhere else?
Sorry if you dont want me to post my coding but I really would like this sorted: var/HUDlist[0] world New() ..() HUDlist += new/obj/Battle_HUD/HUD_ul HUDlist += new/obj/Battle_HUD/HUD_uc HUDlist += new/obj/Battle_HUD/HUD_ur HUDlist += new/obj/Battle_HUD/HUD_cl HUDlist += new/obj/Battle_HUD/HUD_c HUDlist += new/obj/Battle_HUD/HUD_cr HUDlist += new/obj/Battle_HUD/HUD_bl HUDlist += new/obj/Battle_HUD/HUD_bc HUDlist += new/obj/Battle_HUD/HUD_br obj Battle_HUD var/mob/owner mob var/PlayerHUDlist[0] mob/var/islocked = 0 mob.Move() if(src.islocked) return 0 else return ..() mob Imp icon = 'enemies.dmi' icon_state = "imp" HP = 15 Pwr. = 6 Stam. = 1 Hit = 1 EXP = 20 GP = 5 Bumped(mob/M) usr.islocked=1 usr.loc=locate(src.x-2,src.y,src.z) Battle() proc Battle() sleep(10) switch(input("What would you like to do.")in list("Attack","Run")) if("Attack") Attack() if("Run") Run() Attack() var/damage=usr.Pwr.-src.Stam. src.HP-=damage src<<"You attacked the [src] [damage] damage." Death() sleep(10) monsterattack() monsterattack() var/damage=src.Pwr.-usr.Stam. if(src.Pwr.-usr.Stam.<=0) src<<"The [src] completely missed." sleep(10) else usr.HP-=damage usr<<"The [src] hit you [damage] damage." DeathCheck() sleep(10) Battle() Run() alert("Not in") Battle() Death() if(src.client) for(var/obj/Battle_HUD/B in src.client.screen) del(B) if(src.HP<=0) src.EXP+=src.EXP src.GP+=src.GP Levelup() src.islocked=0 del src mob proc DeathCheck(mob/M) if(src.HP <= 0) if(src.client) for(var/obj/Battle_HUD/h in src.PlayerHUDlist) src.PlayerHUDlist -= h del(h) if(M.client) for(var/obj/Battle_HUD/h in M.PlayerHUDlist) M.PlayerHUDlist -= h del(h) M.EXP+=src.EXP M.GP+=src.GP M.Levelup() M.islocked=0 src <<"The [M] killed you." src.GP/=2 src.HP=1 src.loc=locate(1,1,1) mob Bumped(mob/M) if(M.client) for(var/obj/Battle_HUD/h in HUDlist) var/obj/Battle_HUD/H = new h.type M.PlayerHUDlist += H H.owner = M M.client.screen += H if(src.client) for(var/obj/Battle_HUD/h in HUDlist) var/obj/Battle_HUD/H = new h.type src.PlayerHUDlist += H H.owner = src src.client.screen += H // Anything else that sets up battle goes here atom proc Bump(atom/A) A.Bumped(src) Bumped(atom/movable/A) | |
Rii wrote:
Basically, the HUD doesnt show up when you enter battle, and once a battle is finished the player freezes, are there any parts of the coding that could be causing this? Or is it somewhere else? Whew, there are a LOT of problems here... The least of which is the use of usr all over the place...lol
Right here's the first problem... You have to have each of those objects defined under Battle_HUD...like so: obj However, since it compiles fine (you've obviously played it, so it must compile alright) I assume that you do have them all defined properly, and just left that out of the code you posted to save space... But in case they're not all defined, then you need to do that... As for the rest of the code, I'm going to fix it all up... The code should look like the following (I'll explain what I changed and why afterwards): atom One major problem I noticed is that you seem to be just copying and pasting the code people give you... You're not supposed to do that... You're supposed to fit the code I (or anyone else) give you into your own code...not just add it on at the end... For instance, I gave you a Bumped() proc that set up the HUD... You just pasted it down as a second Bumped() proc... You have to take the code I put and stick it into one Bumped() proc with the stuff you already have in your Bumped() proc (or just completely change your Bumped() proc to what I put, if that's what it takes)... Not just slap it on the next available line in your code... It doesn't work that way... (same thing for any other procs that we give you... put the code into your existing procs instead of just sticking it at the end of your code file) However, pretty much what you posted should be replaced completely by what I just changed it to (you'll have to fix the indentation, of course... so it's best to just edit your code by hand instead of copying and pasting) Here's what I changed: First off, I moved things around to organize them better... I prefer to keep my code in a specific order of type (world, atom, client, mob, obj, turf, area)... I just find that easier to keep track of instead of things like having /atom defined at the bottom of the code... Or worse, splitting things up in multiple places of the code file... Like having /mob defined more than once... Just put all /mob related stuff under one mob definition... (However, there is an exception to this rule... If you use more than one code file, then it's usually necessary to use each type more than once (once per code file)... That's alright, but you've got to be extra careful to make sure they're done right (and not overriding previously coded types in other files) Example: world See how we're using mob/ twice? Don't do that... Just put it all together... Like this: world See? Keep it all together... So that's the first thing I did to the code you posted... I organized everything into what it should be under... All mob related stuff went under just one mob/ definition... The second thing I noticed was that you have a couple of variables with periods in their names (Pwr. and Stam.)... Don't do that... Just use "Pwr" and "Stam"... The period could end up causing problems in certain conditions, since it is a DM operator... Periods should never be used in naming anything... Only as a DM operator (like calling "M.DeathCheck()") The third thing I changed was to put all of the various Bumped() definitions into just one (like I mention above)... And I moved that one into just mob, instead of mob/Imp... This way, it'll work for everyone, and not just Imps... Along those lines, I made the code now work for all mobs... NPCs and players alike... There's no need to have separate systems for NPCs and players when the same procs can be used for both... And in this case, it was very possible to use the same systems for both types... The only thing I needed to add was a check in the Battle() proc to see if the mob was a player (if they have a client), or an NPC... If they're a player, then it asks them if they want to run or attack... If it's not a player, then it just attacks... Fourth, I changed all of your procs to use mob/M arguments, and took out all uses of usr... Changing "usr" to "src" isn't the way to fix that... You have to replace it with something better... In most cases, that is done by giving all procs and verbs arguments to pass mobs into... As a simplified example, this is basically how the new Attack() system works: mob Battle starts when a mob bumps into another mob... The mob that did the bumping is M in the Bumped() proc... The Bumped() proc then starts the battle, by calling Battle(), and passing M through as an argument to be used in the Battle() proc... In the Battle() proc, it is coded to accept a mob/M argument... It then uses this M as an argument passed when the mob calls its Attack() proc... M is sent along through that one as well... Attack() is coded to also accept a mob/M argument... Using that argument, we do the damage to M... (src is the mob doing the damage, M is the mob getting damaged) Attack() then uses the argument, M to call M.Battle()... That will make it M's turn, and let them attack back... We pass src through as the argument this time, because they need to switch... M gets to attack, and then src, and so on... At the end of every attack, they are switched because of using the arguments to do so... The fifth thing I changed was the Death()/DeathCheck() stuff... Like I said before, you only need one of them... And, after looking at the code, I decided that Death() was the one to keep... Since the only thing different in DeathCheck() was one line:
if(src.HP <= 0)
And I cleaned up a few other small bits, but nothing major... And now, the revised code I posted above should now work just fine... I hope you're beginning to understand things a bit better... And please try to understand how it works, not just blindly copy my code and use it... | |
Ok Ive just got to sort out a few indentation errors and I will test it, only problem is, they dont seem to be going, once I solve a few of them and then I get an error in the Run() proc and another one in the Death proc, if you can help me Id be greatful. Thanks alot SSGX, can I ask another question?
Do you know how to do multi tiling because all help that I have been given so far hasnt worked at all. If you can help me then I will surely pay you back somehow. | |
The best way to fix indentation errors is to start at the very first one and work your way down... Sometimes, just one bad indent at the top of the code can cause errors for the entire rest of the file... And fixing that one indentation can fix all of the rest without even having to do anything...
But basically, if you're following all of that code I gave you, just remember that every line that's further in than the one above it should have just one more tab than the one above it... The problem you might have is that all of that code I posted was using spaces as indentation (tabs don't work as well on the boards), and generally, people use tabs in their code... You can use spaces, but you can't use both at the same time, so if DM is looking for tabs, and finds spaces, then it'll give you errors... You'll have to go through, and erase all of the spaces, and replace them with the right number of tabs... As for multitiling, this one can be handled a few ways, but the easiest (and so far, the best looking) is the following: obj What makes this work is pixel offsets (the pixel_y variable I use in the object definition)... pixel_y and pixel_x... pixel_y makes the obj's graphic be displayed that number of pixels higher or lower than its location (32 is a full tile to the north, and -32 is a full tile to the south... also, you can use any number... like 64 for two tiles north, or 5 for just a little bit to the north, or -320 for 10 tiles to the south... any whole number will work...) pixel_x works the same way as pixel_y, but horizontally instead of vertically... pixel_x = 32 will be one tile to the east/right, and pixel_x = -32 will be one tile to the west/left (again, any number you need will work) By defining an object with a pixel_y offset of 32, that means that its icon will be displayed one tile above where the object actually is... When we add that object as an overlay to a mob, the object's location is the mob, but the pixel offset makes its icon be displayed one tile above the mob...which makes the mob look two tiles tall... And any combination can work... You can make mobs that are three tiles tall (by having another overlay object with a pixel_y offset of 64, in addition to the middle one with 32)... And even stuff like 3x4 tiles... (using pixel_x to put tiles along side of the mob, and pixel_y for tiles above the mob) | |
Ok but I dont need it to be added immediately, only when you enter a town, castle, etc.
Would you display it in an Enter proc or Entered? I also need it so that once the player enters the world map then they will return to their world map icon, that would be: src.overlays -= new /obj/head src.icon_state = "worldmap" Is that correct? | |
What you can do to make it even simpler than that is the following:
First, you have to have two icon files... One for the bottom half, and one for the top half... In the icon for the bottom half, make the "worldmap" icon_state, and the bigger bottom half (legs, body) icon_state (name it something like "townview")... In the second file, make one icon_state with the head, and name it the same name as you named the bottom half in the first icon ("townview", or whatever you choose)... Then, make another icon_state, but leave it blank... Name the blank one, "worldmap"... Then, in Login, add the overlay as I said to... And set the mob's icon_state to "worldmap"... Since the "worldmap" icon_state for the top half is a blank icon, it will be invisible when the mob's state is "worldmap", so you don't even have to remove it... Just change the icon_state when they go to the world map, and it'll disappear... Then, when they enter a town/castle/whatever, just change their icon_state to "townview" (or whatever you name them)...and the bottom half will become the legs, and the top half will appear as the head... I'd have it change in Entered... Along with whatever code you have that teleports them to the town/castle/etc map (or back to the world map)... | |
Ive set up the top half for multiple icons, well I think I may have done it correctly, however, I still get more indentation errors on lines 3,4,5,6 and 7. How can I solve it because they keep coming back:
obj top_half if(/mob/player/fighter) icon = 'fighter.dmi' icon_state "head" pixel_y = 32 layer = MOB_LAYER if(/mob/player/knight) icon = 'knight.dmi' icon_state "head" pixel_y = 32 layer = MOB_LAYER if(/mob/player/mage) icon = 'mage.dmi' icon_state = "head" pixel_y = 32 layer = MOB_LAYER if(/mob/player/warrior) icon = 'warrior.dmi' icon_state = "head" pixel_y = 32 layer = MOB_LAYER if(/mob/player/rii) icon = 'rii.dmi' icon_state = "head" pixel_y = 32 layer = MOB_LAYER if(/mob/player/zero) icon = 'zero.dmi' icon_state = "head" pixel_y = 32 layer = MOB_LAYER | |