 |
welcome, guest |
| Development Forum | ||||||
 |
| |||||
 AquaShee   |
I've begun using script number 10 to set up my agents. The BSTL Machine already uses it partly. Script 10 gets executed when an object is created, so you can put all attr, elas, fric and other attributes in there instead of setting them up in the script of the object making the new object. So instead of
You get
This way you can inject new objects much more easily. I was mostly wondering if anyone else has experience with this method, and if there are any reasons not to do it this way. So far I haven't had a single issue. The Community Scribble: make (y)our own metaroom! |
|||||
 Moe  |
If the object isn’t created instantly there can be resource issues if another agent tries to access it, or one of its variables, due to the game’s scheduler delaying the injection of the Install script, but that would be a rather rare problem unless your agent depends on this. The biggest problem I can see thus far is something like this: Your agent example moves itself to a safe location before the install script is injected, but at this point it’s ATTR is still 0, that means the engine can put it anywhere. If it doesn’t inject the install script instantly due to tick scheduling or any other agents being injected along with it, you could end up with it in a wall when the engine sets its ATTR to 199, causing it to raise an exception (crash or auto-kill). You could try putting the mvsf in the install script after the attr is set, see what happens. I experimented with this notion on an agent I created to store and vend any number of any items placed in it (which worked fairly well), but script numbers are like variables, if not everyone uses the same ones I found no real use knowing them for just a few agents, other than just taking up [albeit, very little] space in the scriptorium. Which is the third possible, but VERY unlikely, problem, that it'll bog down the scriptorium with unnecessary information (unless you use it later, in which case it's necessary and all is well.) In any case, if you can find a use for it and ensure that no problems arise, by all means, use and abuse. EDIT: Let us know if any other problems arise too, or even what benefits the method yields. |
|||||
AquaShee |
Well, mvsf moves the agent to a safe location regardless of the attr. It will always be put inside room boundaries. The perm, on the other hand, does give issues when trying to get set while the agent is crossing a room border that wouldn't allow the new perm. But since most objects are created by a parent object (seed, mother critter, egg,...) you will not encounter this as long as the perm of parent and child are the same. Putting the contents of the creation script in an inst block solves most accessing issues, as the creation script gets executed almost immediately. Agents accessing other agents should be careful themselves, it should be easy for them to spot your agent isn't set up yet. If needed you can just pass along the coordinates instead and move the agent from within its creation script, solving any issues before they arise. A good example of what makes this useful is a plant: Both the plant and the seed vendor only have to execute the NEW: SIMP command and put the seed where it should go. So yeah, the creation script does have its downsides, but so far they're easily worked around by safe programming which should be done in any case. So far I'm loving this new method. The Community Scribble: make (y)our own metaroom! |
|||||
Moe |
Oh that's right, yes, mvsf! I was using mvto by accident in my test, no wonder I got errors. Haha. And yes, I do see the positive in your method. I might have to give that another look. It's easier than laying it all in the parent's script itself each time your make a new object.  |
|||||
 Malkin Manager |
*bumping* this topic five years on... (sorry!) Do we know anything more about how to implement creation scripts, what can go in them? My TCR Norns |
|||||
 Peppery One Papriko |
A creation script is the same as any other script, just that it is automatically triggered upon creation. You can use it to set up physics properties or other values which need to be set, for example when you have a vendor producing pretty complicated agents. My corpse vendor for example uses the construction script to re-align the lower border of the bounding box, to prevent hovering pieces (e.g. non-pregnant female bellies). Another possible application would be a vendor which produces compound agents and/or a ton of other agents at once. Instead of letting the vendor construct them piece by piece, either taking ages or costing a ton of power using INST, the vendor just sets up a very basic version of the object which then takes care of itself via constructor script. The script can be used for pretty much anything which needs to be done to an agent just once and right when it appears. Yet another example would be placing it in the world when it goes to a fixed position and not to a relative one or pre-calculating some variables. Lets play plants! Photosynthesis... Photosynthesis... Photosynthesis... |
|||||
Moe |
I agree with the notion that you can use the Creation Script for just about anything you want to be done at Creation. I use it for every agent I make. Even if all I have to do is set up the ATTR and BHVR, I still use the Creation Script. It's organized and great for complex agents. There are a few things to watch out for though if you're making really complicated agents... The Creation Script occurs as soon as the agent is made. This can be a problem if you have to set up specific variables and use the Creation Script to modify those afterwards. Consider this example where one agent is creating another and the child agent needs to check a variable to determine what to do in its creation script. Maybe it's a plant passing on its genetics or telling its flower which way to face: [somewhere up here va00 is set by the parent agent creating the one below, to tell it something very important:] new: simp X X XXXX "Sprite" 1 0 500 setv ov00 va00 mvsf XXX XXX Creation Script: scrp X X XXXX 10 doif ov00 eq 1 [do something] endi endm In this case the agent you're creating needs to know what the parent said about ov00/va00 in order to proceed. But here's the catch... The Creation Script occurs so fast that your "setv ov00 va00" actually gets done AFTER the Creation Script finishes. So unfortunately, your ov00 in the Creation Script always returns 0, and never executes the doif block. Adding a "wait 1" to the start of the Creation Script can usually fix this problem, but be aware that some agents need their attributes and permeability set immediately, otherwise they crash the engine by trying to phase through walls. To fix it, use this approach: Creation Script: scrp X X XXXX 10 inst attr XXX bhvr XXX perm XXX elas XXX slow wait 1 doif ov00 eq 1 [do something] endi endm (Experience coders may note that there's no need to use "SLOW" when you use "WAIT". WAIT automatically breaks an INST block. However, I show it here for good INST etiquette. Always let the engine know when you're done INST'ing.) That pretty much covers it. The Creation Script really tidy's up the creation of agents. |
|||||
 Prodigal Sock Ghosthande |
Assuming you're running Docking Station, of course... IIRC it doesn't run in Creatures 3? Or is this a quirk of my game?  |
|||||
| 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 |
2 online Papriko Riakodoadm |
| 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 |
||||