 |
welcome, guest |
| Development Forum | ||||||
 |
| |||||
 Geek2Nurse    |
So I have this drop script that's supposed to detect whether the agent is in water or not...but it has suddenly started being unreliable, after working great for me in the past. It looks like this:
After filling my code all full of debugging lines, I turned DMAP on, injected the agent, retrieved it from the comms room, and dropped it into a largish room in the middle of the aquarium room, where it fits easily within the bounding lines. I then picked it up, without moving it, and dropped it back in the exact same spot. Here's what I got (I can include the whole script if anyone wants, I just didn't want to overwhelm you with code):
Can anyone tell me why it would initially report it was in a room of type 3, when it was smack in the middle of the aquarium, and admitted as much the next time I dropped it in the same place? --- Optimist: the glass is half full. Pessimist: the glass is half empty. Engineer: the glass is twice as big as it needs to be. |
|||||
 Prodigal Sock Ghosthande |
Can't take an in-depth look as I'm working, but I will later. In the mean time, are you sure there isn't something off about that particular room? Have you checked via some other method to make sure that particular spot isn't really type 3 like your agent claims? Perhaps it knows something you don't.   |
|||||
Geek2Nurse |
Whether it's 3 *or* 9, something's fishy (har, har!), because it should report the same room type each time. But yes, according to Moe's room changer, it's salt water (type 9). I'm wondering if I'm having an OWNR/TARG issue in my install script...maybe I'm not getting the right room ID because it thinks the current room is different from the one I think it is. Is there some delay between the NEW: SIMP command and when OWNR gets set to the new agent, maybe?  --- Optimist: the glass is half full. Pessimist: the glass is half empty. Engineer: the glass is twice as big as it needs to be. |
|||||
Prodigal Sock Ghosthande |
TARG may change from one agent to another, but OWNR is always the owner of the script. It won't ever be set to anything else, even if you use MESG WRIT in another agent to trigger this script. You can think of the classifier in the script (eg. Scrp 2 4 60600 1) as the "dog tag" which indicates what the owner is. The only reason I can think that you might have a problem like that would be if you're trying to use OWNR in the install script or something like that. |
|||||
 Moe |
The first part of your drop script looks to be a little discontinuous. You go from setv VA20 to room ownr, then you set VA21 to rtyp OV20. Where is ov20 initially set? Because as soon as it drops it's checking the rtyp of ov20, and that's what it's debug outing. I see later in the script it checks itself against the va20 you set earlier (the room it's in now) and then it sets ov20 to that room id, so the NEXT time you drop it it should report the rtyp of the last room you dropped it in, and then after that it'll update the ov20 again. The room you inject it in is 710, right? Does the injection portion set the initial ov20 to be the current room? Is that rtyp 3? Try setting the first portion to be setv va21 rtyp va20, instead of ov20. That will report the rtyp of the room it's in at the moment of dropping, since va20 was set to be room ownr. Then the rest of the script will continue, and if the room isn't the same as ov20, it'll update ov20. |
|||||
Geek2Nurse |
Dang, that's it. How'd I manage to mess that up? *sigh* Yeah, when the agent is initially injected, ov20 is set to its initial room. Then each time it's dropped, the new va20 is compared to ov20 to see if the stored room information, CA settings, etc. needs to be updated. Thank you! I would have banged my head on this all day, because THAT part of the script was already thoroughly tested and working fine. Until I apparently changed a perfectly good variable for no reason. :/ EDIT: *Groan* I just realized that room type can change without the room ID changing, thanks to you and Amaikokonut...now that it's all working perfectly I guess I have to go back and update it to detect that too, at risk of breaking it again!  --- Optimist: the glass is half full. Pessimist: the glass is half empty. Engineer: the glass is twice as big as it needs to be. |
|||||
Moe |
You don't know how many times I've re-written sections of code just because I can't solve a problem, and what I re-wrote looks IDENTICAL to the original code, yet it works for some reason. A lot of the time I think it's just stupid mistakes like a va is set as an ov, or I'm using a doif statement and I put 'or' instead of 'and'. Silly things. What I do a lot of the time is just go through my code line-by-line and pretend I'm the engine, executing it. I'll put the agent in a room, set it's ov's in my mind, and work with all the variables I can handle to see what happens theoretically. I only recently started using the CL Agent Debugger, so I never had the luxury of Dbg: Outv'ing all my stuff. :p I ran the scripts in my head, and sometimes that's still the best way to solve a problem because you actually see the code and catch the little errors. |
|||||
Geek2Nurse |
Yeah, when I was coding full-time, that's how I did it...but I didn't have a grandchild hopping around (and on) me back then. It's a lot harder to concentrate on being an engine nowadays! So here's a tangentially related question...I keep trying to move the code that updates the OV values into a subroutine/script/whatever they're called in CAOS, because I do the exact same thing again later in the drop script, and I have this ingrained aversion to duplicate code. But any time I try to call a script from the inject script, I get an "invalid ownr" error. Is there just no way to call other scripts from the injection script? --- Optimist: the glass is half full. Pessimist: the glass is half empty. Engineer: the glass is twice as big as it needs to be. |
|||||
Moe |
Injection scripts have no ownr's, only targs. You can use the "creation" script, to execute a mesg or call function (as well as assign variables and pretty much anything else you desire). scrp X X XXXX 10 endm This script is called every time an agent of this type is injected. Using it, you could call the drop script, or any other script, to run. Mesg, msg+, call, whatever!  EDIT: I should mention that technically, you can mesg writ targ in an injection script, because the targ is valid and set to the newly created agent. I'm not sure you can use the CALL function however, because that actually pauses the injection script and "returns" when finished, and to my knowledge you can't pause injections (Ex: wait command). But I put install/creation scripts in all of my agents and it's the most effective way by far. |
|||||
Geek2Nurse |
Oh, *excellent*, thanks! --- Optimist: the glass is half full. Pessimist: the glass is half empty. Engineer: the glass is twice as big as it needs to be. |
|||||
 Wiimeiser |
I know Geats reset the room type of any room they enter to atmosphere, (which arguably suggests they were intended to be world-destroying plague-spreaders but were scrapped along with their room for being too powerful, or is this just a glitch? The way games work, it's unlikely to be...) Hashikin ko Tyni Kong Taria Haju'Rumia'an Klodz'Proddi. Terdish oxen saur yessi atai Kongo Dolpik! |
|||||
 Amaikokonut |
It's not that geats reset any room they walk in to atmosphere; Ghosthande and I did some tests a while back and it appears that the rooms-turning-to-air glitch only happens when you have two geats together, and one of them looks at (or pushes, hits,etc) the other. Then, depending on your world size/computer speed, the game pauses a second, and in that instant nearly all the rooms around the geats become air. So as long as you only keep one geat in the world, or make multiple geats invisible to creatures, the room types are fine. ..It's really an incredibly strange glitch; I wish we knew more about it.  [Naturing :: Nurturing] |
|||||
Prodigal Sock Ghosthande |
Or keep multiple geats, but keep them totally separated so they can never see or interact with each other... but yeah, I'd love to know what it is exactly that makes it happen. It really is the strangest glitch I've ever seen in the Creatures series, and quite the bummer. |
|||||
Geek2Nurse |
I don't even know what a geat IS. Also, if you PAUS your agent in the pickup script, you can't ever drop it. #funthingsnovicesdo Also #2: There are ZOMBIE NORNS??? (Just noticed it in the CAOS commands...) --- Optimist: the glass is half full. Pessimist: the glass is half empty. Engineer: the glass is twice as big as it needs to be. |
|||||
Prodigal Sock Ghosthande |
Well, not literal zombies... it stops them from making decisions, so they just lie there and do nothing. If you use the right commands you can control them like a puppet... or a zombie. |
|||||
 Patient Pirate ylukyun Manager |
I like the SOUL command. |
|||||
Geek2Nurse |
I've wondered if the fact that there are a total of 666 documented commands was purposeful, too. Programmers have such bizarre senses of humor. When I applied for my first job as a psychiatric nurse, they asked me if I had any psych experience. I said, "I've worked a lot with programmers." I don't know if that had anything to do with it, but I got the job. --- Optimist: the glass is half full. Pessimist: the glass is half empty. Engineer: the glass is twice as big as it needs to be. |
|||||
| downloads cobs adoptions creaturelink metarooms breeds gallery art wallpaper screenshots graphics promos sprites |
dev hack shack script reservations dev resources active projects dev forum community links advice chat polls resources |
creatchi forum bookmarks general news help development strangeo survivor |
mycaves log in register lost pw |
1 online RisenAngel |
| creatures caves is your #1 resource for the creatures artificial life game series: creatures, creatures 2, creatures 3, docking station, and the upcoming creatures family. contact help privacy policy terms & conditions rules donate wiki |
||||