creatures caves
welcome, guest 

downloads   gallery   dev   community   creatchi   forum   mycaves
hack shack | script reservations | dev resources | dev forum
 

  
Submit Question

  The advice column is not currently accepting new questions.
We apologize for any inconvenience.


Flipped Sprites vs. Mira  on 10/23/2014 | 1 comment | 1 like

Hello,
     I've been coding a bunch of critters and other things for my metaroom, and working with them is making me wonder something.

A few critters had sprites only facing one way. What I wound up doing was making copies of the individual images facing the other way before throwing both into the sprite file. However, I'm aware there exists a CAOs command, mira, that flips the sprite around in-game.

What I'm wondering is the advantages and disadvantages of each method. Mira is obviously a bit easier to implement, but does it take up more processing power over having images facing both directions in the sprite file? Is there any hidden benefits to using one method over the other? Stuff like that.
- Grendel_Man


Dear Grendel_Man,
     MIRA does come with a few disadvantages. For one thing, since it forces the engine to "create" the flipped sprites on the fly, I doubt it's much more efficient for the game itself than just creating the mirrored sprites by hand.

However, there is one obvious drawback to using MIRA: an agent will not appear on any in-game cameras while its sprites are mirrored. For example, if you use MIRA to change the direction a critter faces, that critter will be visible on cameras whenever it is not mirrored, but randomly disappear any time it turns around.

I did not initially notice this issue myself, and used MIRA a lot more frequently before the problem was eventually pointed out to me. I try to use the command more sparingly now, although I do still use it. Being able to "cheat" your way out of drawing mirrored sprites can be very useful in certain situations. I have used it a few times for agents that have a lot of sprites, particularly when I was concerned that they might exceed the 255 sprite limit if I were to include flipped versions*.

* You can, of course, have more than 255 sprites in a sprite file. But the number 255 is used as a special marker to indicate the end of a loop sequence when using the ANIM command; so if you say "ANIM [253 254 255 256 257]", it will reach 255 and then flip out, assuming that it is supposed to continually loop starting on frame 256 of a two-frame animation!

I'm not aware of any other drawbacks to using MIRA, and your mileage may vary as to whether or not the camera detail bothers you. There are definitely some circumstances when it will be more or less noticeable; and of course it becomes a moot point for agents that are invisible to cameras by default.
- Ghosthande
 
Peak of smell  on 7/25/2014 | 2 comments | 2 likes

Hello,
     I'm playing around a bit with the genetics and wanted my breed to have their home where the light is. So I changed Stimulus to 'Reached Smell 1'. I thought it was that easy but I found the following problems:

- What to do with the instinct gene for the home? The light emitters classify as nothing but invisible. My solution now was to change them to 'weather' and set the instict to weather, too. Would changing of the emitters cause problems (with other agents maybe)?

Is there maybe another, easier way to tell the instinct that they get their comfort when following the light 'smell'?

- How does 'Reach Smell X' work anyway? Is it triggered when a certain amount of CA is reached or the maximum of the room or the total worlds? (Like, if I install a new room that has a new light maximum would their home location change?)

- Would there be a way to 'invert' it? To set 'darkness' as their home?
- Luzze


Dear Luzze,
     The way Creatures detect and interact with smells is a bit funky. I know what you're going through, because I've tried to do similar things in the past.

I'm not sure exactly how "reached smell X" works on its own, but I can tell you that if you want your Norns to approach something, the smell in question needs to be associated with an agent type. Norn brains are set up to run primarily on interactions with physical agents. For the most part, a smell is essentially just a "billboard" that tells the Norn where to find an agent of a given type.

One way in which you can see this limitation in action is what I call "oblivious Norn syndrome" (or ONS for short). If you create an object that smells like food, but is either invisible or just some other type of agent, Norns will pace around that agent but completely ignore it. Even if the agent is some other edible object, like a piece of fruit, they will still ignore it! Their brains connect "food smell" to "food agents", so they will keep doggedly looking for a piece of food until they are either sufficiently distracted by something else, or until they die.

This kind of behavior (expecting an agent to be associated with a smell) extends to Norn Home Smell too: there is a specific, visible agent called "Norn Home" which Norns approach when homesick, and this agent is what produces Norn Home Smell. If Norns can't see the Norn Home agent, or if the smell emitter is a different agent type, they will fall right into ONS: pacing back and forth helplessly as they look for something they either can't see or don't recognize.

Now here's something that might be able to help you: Norns only know that the "Norn Home" agent is what produces Norn Home Smell because the game stores associations between smells and the agents that emit them. In Docking Station at least, you can change or create new associations using the CACL command. The structure of the command, as depicted in the CAOS Documentation, looks like this:

CACL (command) family (integer) genus (integer) species (integer) ca_index (integer)

So if (for example) I wanted to make the Hand smell like food, I could run this command:

CACL 2 1 1 8

You can have your Norns approach light more effectively if you tell the game that the "light smell" is linked to a certain agent type, and tell them to approach that agent. I'm not sure the inverse would be possible, though, since "darkness" even in the game is simply an absence of the "light smell".
- Ghosthande
 
Nested DOIF?  on 4/13/2014 | 1 comment

Hello,
     Have you ever used nested DOIFs? (DOIFs inside DOIFs) When would you recommend using them? Do you have any tips on how to work with nested DOIFs effectively?
- Malkin


Dear Malkin,
     I use nested conditions all the time: in CAOS, in PHP, Javascript, and ColdFusion (which is, interestingly, more similar to CAOS in some ways than it is to other web-related languages). The correct answer is: whenever it seems more efficient to do so. In general, which method you use isn't a matter of optimization, but basic logic that depends entirely on the circumstances: your script won't do what you want it to if you use the wrong method.

But there are definitely some times when it's better to nest them, and some times when it isn't. The most common alternative to nesting conditions is to link them, like this:

DOIF condition 1
(do something)
ELIF condition 2
(do something)
ELIF condition 3
(do something)
ELSE
(do something)
ENDI


It's all essentially one "block" of conditions. If the first condition isn't true, it will automatically try the second, then if that isn't true it will try the third, etc.

Nesting conditions, as you know, looks like this:

DOIF condition 1
(do something)
ELSE
DOIF condition 2
(do something)
ELIF condition 3
(do something)
ELSE
(do something)
ENDI
ENDI




There are a few ways in which humans use conditions that computers don't, and this "language bias" is the most counterproductive when using conditions, because our experience speaking English (or German, or Chinese) influences how we expect CAOS to work. For instance, I see a lot of new programmers write stuff like this:

DOIF the sky is blue
(do something)
ELIF the grass is green
(do something)
ELSE
(do something)
ENDI


Because we all think the same way and make the same initial assumptions when learning to code, you'll see people do this kind of thing in any programming language that uses conditions. The problem is that computers--regardless of what language you're using to communicate with them--don't like subject changes in the middle of condition blocks. Since the first DOIF is referring to the sky, the game expects that the next condition in the block will also relate to the sky. Even though the basic structure looks correct to the human eye, the code above won't work consistently because it relies on forcing the game to "think" in a way it wasn't designed to. This is the kind of situation in which we need to use nested conditions. The code above becomes much more stable and reliable when we "phrase" it properly:

DOIF the sky is blue
(the sky is blue, so do something)
ELSE
DOIF the grass is green
(the sky is not blue BUT the grass is green, so do something)
ELSE
(the sky is not blue AND the grass is not green, so do something)
ENDI
ENDI


Now the game will know for sure that we only care about the color of the grass if the sky is blue. If we want to check the color of the grass and take different actions depending on both the sky and grass color, we can duplicate the grass-related condition block like this:

DOIF the sky is blue
DOIF the grass is green
(the sky is blue AND the grass is green, so do something)
ELSE
(the sky is blue BUT the grass is not green, so do something)
ENDI
ELSE
DOIF the grass is green
(the sky is not blue BUT the grass is green, so do something)
ELSE
(the sky is not blue AND the grass is not green, so do something)
ENDI
ENDI


Or we can use variables to "tally up" the results of our conditions, like this:

DOIF the sky is blue
SETV VA00 1
ELSE
SETV VA00 2
ENDI

DOIF the grass is green
ADDV VA00 10
ELSE
ADDV VA00 20
ENDI

DOIF VA00 EQ 11
(the sky is blue and the grass is green)
ELIF VA00 EQ 12
(the sky is blue but the grass is not green)
ELIF VA00 EQ 21
(the sky is not blue but the grass is green)
ELIF VA00 EQ 22
(the sky is not blue and the grass is not green)
ENDI


Which one you use depends entirely on the situation: if you're only combining two conditions, the first method is certainly more straightforward at a glance. But if you're combining more than two conditions (perhaps you want to check if the sky is blue, if the grass is green, and if there's a mild breeze) that method will double in complexity with each condition added, which can get messy very quickly. The second method has an advantage in that situation, because the final condition retains the same structure no matter how many conditions are involved.

It also makes it easier to use the same action for different conditions, because you can do fun stuff like this:

DOIF VA00 EQ 11
(the sky is blue and the grass is green)
ELIF VA00 EQ 12 OR VA00 EQ 22
(the sky is blue but the grass is not green, OR the sky is not blue and the grass is not green)
ELIF VA00 EQ 21
(the sky is not blue but the grass is green)
ENDI



There's a lot that could be said about conditions and how to use them, but any method depends on what works best for your agent and what makes the most sense to you. I think that's why I find conditions one of the most fun and interesting aspects of coding.
- Ghosthande
 
Correct BHVR, No Script?  on 11/13/2013 | 4 comments

Hello,
     What happens if I set a bhvr that allows an agent to be interacted with, but I don't give that agent a corresponding interaction script? What does the creature experience when they interact with such an agent?
- Malkin


Dear Malkin,
     It depends on the script in question. A C3/DS agent cannot have a BHVR that includes edibility but no eat script, for example: the agent will error when the user attempts to inject it, well before any creature could try to interact with it.

It may not seem that way, but this is true for all script types; I actually discussed this with AquaShee a while back and he was able to determine that scripts that appear to be optional, such as the pickup script, only appear to function that way because the game has a hidden "global default" pickup script that it uses if there is no pickup script for a specific agent.

So really, there is never not a script to match an agent's BHVR, either because it causes an error or because there really is a script involved. A creature that interacts with a "scriptless" agent experiences whatever stimulus exists in the default script.

The only time I can think of when a creature might receive literally no stimulus for an action is if an agent's creator does write a script for a certain interaction, but does not include any stimulus. CFE breeds appear to feel disappointment and/or boredom when an action provides no feedback and will eventually give up, but non-CFE breeds don't have this feature and may continue to try to perform the same action until they exhaust themselves.
- Ghosthande
 
Patch Plants  on 11/7/2013 | 1 comment | 1 like

Hello,
     Are patch plants easier to create than regular agents, since they're a sort of addition to an already created agent (i.e. the garden box)? Or do they basically entail the same amount of coding and work to create?
- Rascii


Dear Rascii,
     In my opinion, they're both pretty much equal, though patch plants may be slightly more difficult the first time around since you have to get familiar with Garden Box coding and variables. Beyond that, patch plants and regular plants are generally the same: a coder still needs to write an install script, it is just "nested" inside a GB script. The other scripts, including the timer script and remove script, are basically identical.

So from my experience (mostly helping others--I have yet to finish a patch plant of my own) the Garden Box is definitely not a "shortcut" for people who want easier plants, but those who are new to plant creation aren't in for much if any extra difficulty, and coders who are already familiar with making regular plants will find that patch plants aren't intimidating at all once you start. :)
- Ghosthande
 
Drag and Drop in C3/DS  on 10/28/2013 | comment | 1 like

Hello,
     Most (if not all) actions in the Creatures series are point and click-based, but I was wondering if drag and drop actions are also possible. Since C3 and DS have user interface elements in-game I thought it wouldn't be too surprising if the engine supports it. Do you know if drag and drop actions are supported?
- eprillios


Dear eprillios,
     Hmm, that's an interesting question.

I've never specifically tried to make something drag-and-droppable, so I can't say for sure that there's no way to do it. I'm not aware of any specific commands for it, however. I do know that you can run a line of code to make the hand pick up an agent when it is clicked on, but I don't think that's quite the same thing. Sorry I can't be of more help! :)
- Ghosthande
 
Pigment Bleeding  on 8/18/2013 | 1 comment | 2 likes

Hello,
     Hi, I've been trying to stop my genetic norns that i'm making from changing colors as they get older. Is there any way that I can get rid of the pigment bleeding?
- HavenHerbaven


Dear HavenHerbaven,
     I'm not an expert on genetics, usually sticking to the "caotic" side of development, but I can empathize with what you're dealing with; pigments are tricky to work with.

There is a tutorial here which may be of use, although I must warn you that--despite what the tutorial says--you must not delete any of a Norn's genes. Deleting genes simply leads to slider syndrome when that Norn breeds with others that have normal genes.

Fortunately, you can literally "turn off" a gene without having to delete it. Each of a Norn's genes has a special toggle; in the Genetics Kit this appears as a check box at the top of the gene editing window, which says "Do not express (carry)". If this box is checked, the gene still exists in the Norn's genome, but lies dormant. Its effects should not be observable on the Norn.

I hope this helps as a starting point and wish you the best of luck with your project!
- Ghosthande
 
ATTs and Breeding  on 5/26/2013 | comment

Hello,
     First off, thank you for the advice concerning spriting/lighting/etc earlier! I've since made some headway on the breed I'm working on (despite a few setbacks), but I've gotten stuck on a worry of mine.

I know from experience that breeding creatures with different sprites will sometimes get you weird, disjointed/dismembered creatures if they're using certain breed sprites in combination with other breed sprites.

While I'm not worried about ATTs becoming a problem with pure-bred creatures, I'm worried that my breed would become prone to this problem when crossbred, and I want to try and prevent the problem before I've made too much progress.

What do you know about how ATTs interact with other ATTs from other breed slots? Can a problem like this be easily fixed?

Thanks again!
- Leporidae


Dear Leporidae,
     Each Norn body part has an ATT which tells it where its joints are. So a Norn head has a "neck joint", and a Norn body also has a "neck joint", and the game positions the head on the body by lining them up with one another. Easy, right? I'm sure you probably know that much already. The reason some breed combinations "go wrong" is that in the past, not all creators were consistent about making sure the joints were in the same relative place on each body part, compared to other breeds.

A Norn with (for example) a neck joint located 10 pixels too far down can still look visibly normal in the game, when both its head and body ATTs match up with each other. But when you get a crossbreed with that breed's head and another breed's body, bad things will happen. Its head ATT specifies that the neck joint is 10 pixels further down than usual, but its body ATT specifies that the neck joint right where it's supposed to be. As a result, the Norn winds up with a floating head.


If your breed has the same proportions as an official breed and are positioned the same way on their sprites, you can just copy an official breed's ATTs and avoid the whole issue. If not, that's okay too! As long as you can get the hang of how ATTs work in general, I don't think making your breed compatible with others will be too difficult. But I do strongly recommend using a graphics program like Photoshop, Gimp, or even Paint to keep track of where connection points are located on the sprites--not just for your breed, but for one of the official breeds too, so that you can get an idea of where joints are supposed to go.

And finally, you can always use the Genetics Kit to test hybrids in-game. I had a lot of concerns about how Gaius crossbreeds would look, for example, because he's built so weird. Because the Genetics Kit allows you to specify species/breed slot for each body part, and then create an egg in-game, it's a breeze to gengineer a test subject with any combination of body parts you want.

I hope this answer has been helpful; ATTs aren't always easy to explain without visuals, but hopefully they don't seem too scary. :)
- Ghosthande
 
Timer Scripts With Pushes  on 5/26/2013 | comment

Hello,
     What are some tips and tricks you can use to make a plant or critter timer script (growing/fruiting plant, mobile critter) that also allows the item to be interacted with (pushed, pulled, hit, eaten), and easily 'resume its place' in the timer script?
- Malkin


Dear Malkin,
     If you followed the same learning curve I did, your first introduction to timer scripts might have been the Basic Plant Script on the Creatures Wiki. A lot of my early agents started out with timer scripts like that: just a line of subroutines, or even just the code itself laid out sequentially. This is fine at first, because this system works great for things that aren't interactive, like plants.

A timer script runs automatically every few ticks (depending on what you set the agent's TICK to). It will automatically be interrupted if another script is called (eg. if a Creature activates its Push Script), and when the timer script next runs, it starts over from the beginning. This means that if you have a plant with a timer script like the one in the tutorial above, it's going to want to restart the whole Grow -> Live -> Seed -> Die sequence every time it gets interrupted. This can cause errors in a lot of ways... say, if the plant tries to "grow" when it's already an adult, it may try to grab an out-of-range sprite.

One easy way to prevent a timer script from being interrupted is to LOCK the agent at the beginning of the script, and UNLOCK it at the end. Then if a Creature or another agent tries to interact with it, it just says "sorry, no can do!" and goes on with its timer. The downside is that the more often the timer script is running, and the longer it takes to run, the less often the agent is open for interactions. And if the whole script runs in one iteration of the timer script, as with the Basic Plant, the agent will essentially be locked for its entire existence (which is why I don't write timer scripts that way anymore). Since Norns don't understand the concept of an agent being "locked", this is a major downside.

The most surefire way to keep track of where an agent "left off" is to use OVxx variables to keep track of what it was doing last. If you're dealing with something like a plant growing or wilting, you can simply check the agent's pose, eg. "doif pose lt (whatever the final pose is)". Of course, this pose will probably change if you end up adding sprites later. And if you ever want to re-use the same code for another agent, that agent might have a different number of sprites. So it's easier to set an OVxx variable with that number when you first create the agent, and then have the agent check "doif pose lt OVxx".

Variables are even more useful if you're dealing with something that doesn't always follow a set pattern of behavior, such as a critter. A critter might wander randomly, interact with Creatures, look for food, play with nearby toys, or any number of other behaviors, often depending on less predictable factors like whether it's hungry or what's going on in its environment.

To do this, you first set a permanent (OVxx) variable as soon as the critter "decides" to do something--eg. as soon as it realizes it's hungry and starts looking for food--and reset that variable to "empty" as soon as the critter is finished doing that thing. Then, at the beginning of the timer script, you check that variable. If the variable is set to a certain action, you go straight to that subroutine. If it isn't set, you let the critter go through the normal process of what it wants to do next.

Using variables this way for critters can be overdone, though. Say, if I have a critter that gets interrupted by a Creature when it's in the process of looking for a mate. Being played with so much leaves it starving, but it ignores the food near it because its last action wasn't "find food". But because it's now starving, it dies before it can reproduce. You may end up seeing some strange behavior if you don't have a set "hierarchy" to prioritize your critter's actions.



If you use reference variables, it's also important to re-check them at the beginning of the timer script to make sure they're still "valid". For instance, let's say that I have a critter that seeks out and eats leaves, as described in the Hungry Critter Tutorial.

In the tutorial, the Hungry Critter only uses a temporary variable to reference the leaves it finds, which means that it "forgets" what it was looking for if the timer script is interrupted. If I want to use an OVxx variable so it can pick up the hunt where it left off, I need to remember that the leaf might not exist anymore by the time the critter gets around to looking again; it might have rotted, been eaten, autokilled, or simply moved. Yes, moved: I've had situations where a Creature carried a food item into another metaroom, and the critter that wanted to eat it spent the rest of its life trying to "follow" that food item! A lot of things can happen while your critter is distracted. [ntongue]
- Ghosthande
 
Hopelessly Lost in Coding  on 5/24/2013 | 1 comment | 2 likes

Hello,
     I've been dreaming up things to make into agents and metarooms since I was a little girl, and I've got the artsy part down pat, but I lack the most important skill for making such things! I have a complete lack of coding knowledge. I'm eager to learn, but I don't even know where to start! [nscared]

First thing's first, where can I learn what all this coding gobbledygook means? What tools do I need? Have you any tips for an eager beginner? I'm drowning in a sea of ideas, with no way of making them a reality!

Thanks luv!
- TrellyDawn


Dear TrellyDawn,
     I'm happy to be able to say that we have a great series of beginner's tutorials right here on CreaturesCaves: the CAOS Chaos trilogy, written by our very own AquaShee! These were the tutorials I used when I first started agenteering, so I can vouch for their helpfulness. The first installment also lists the basic programs you'll need to make a simple agent, which makes it an excellent starting point.

I'd also recommend checking out the CAOS section on this page, in addition to this article, both of which list a lot of development-related resources that may be of use to you.

Probably the best advice I can give you other than that is to grab the CAOS documentation (the first link in the paragraph above explains how) because it lists a lot of really great information. The descriptions of CAOS commands are a little tricky to understand at first, but the lists of attributes, stimuli, script numbers, etc. become extremely handy as you start making a wider range of agents.

Good luck with your foray into coding, it's always great to see new people getting started! :)
- Ghosthande
 

prev | 1 | 2 | next

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
5 online
Papriko
Aliena
Grendel_Man
Pilla
Intyalle
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