it's amazing how rephrasing something suggests whole new ways of doing it.
was thinking about parts, how they would actually work n'stuff. the old lamp
example: it gives light-energy to stuff. before I'd been thinking that it gets
a list of visible parts, throws out the ones not light-sensing, then divides
its energy between the remaining ones.
then, I rephrased it like this: "send x energy to parts which are
visible-to-me and light-sensing". that suggests a much simpler way of
organising things: lamp tells engine that it wants to send x amount of energy,
type light, to any part it can see which is interested in light. iow,
sendEnergy(x, EnergyType::Light, SenseType::Seen, "senseLight == true");
you might even be able to omit the last arg, if the engine has it hardcoded
that the light-type energy can only be sent to parts with senseLight set.

let there be light! ;)

so, that means in general senses can be implemented that way. if you want to
affect the world, you use that function. if you just want to get info about
the world and store it, that's an easy function too. mapping stuff to neurons
may be a little harder, though :)
so, um. the lightbulb part is pretty simple, isn't it? whenever it's given
energy, it uses it to call that function. it has no way of burning out -
although I'm not against having the chance for parts to be broken, kinda in the
way that grendels can disconnect wires in c3 by hitting stuff.
that brings me to the thought - how much control over energy do nonorganic
parts get? in RL you'd have wires connecting the bulb to a switch in the lamp,
so that it had to be plugged in *and* switched on. having a switch built into
the part that draws electricity in the beginning would be pretty easy, but
what if you had more than one bulb? what if you had a bulb and a fan, or
something, and wanted separate controls?
in organic stuff you could probably have parts-requiring-different-chems to
regulate them separately, but for inorganic stuff... hmm. hte dna is more like
a blueprint here, it just wires things up and that's it. wires... connecting
parts? well, we have lots of var space. with organic you have a big pool of
chem-vars that every part is swimming in. with inorganic... umm... well, they
don't have a pool of sludge to swim in. so, they need wires to direct the flow
of energy. do we need pairs, or just one? depends whether you want to allow
stuff in parallel. probably best not to forbid it... I always think of
electricity going in and light coming in, but really it's electricity going
*through* isn't it? the energy comes from the movement. but we still need to
measure that energy drawn, correctly... hmm. so, wires to hook things up.
wires have a tiny bit of resistance themeslves maybe, just to make 100%
efficiency impossible. also means big things get hot, hmm. am I being mean?
should I allow superconductor wires? we'll see. but, wires are *outside* of
parts. that's interesting. so are chems, mostly. wonder if the two can
coexist... aanyways. wires have two endpoint parts. pretty simple things. but
the movement of energy along them could get nontrivial, so watch that. then
we'd need one powersupply part, with or without a builtin switch, that
supplies us with energy. this part is continually trying to get energy from
the engine's lines (or the engine is pushing energy to it, whichever's best),
and then it pushes the electricity through the wires. hrm, maybe it'd be
easier to do wire-pairs after all. traing a path through the wires could be
icky.

hmm. with single wires, you'd have to trace a path around the circuit first,
seeing whether it was all hooked up (including checking whether switch-parts
were on), and only if you found a path would you then push electricity along
it. with multiple paths it just gets icky. if someone else knows a sane way to
implement it, they can do so; for now I'll just have a simple pair-wiring
system. powersupply pushes energy to switch, if it's connected it pushes
energy to bulb, bulb lights up by telling the engine to push out energy;
engine notes that this energy has been used and does its accounting. can also
note energy used from passing through wires and other parts; anyways, it's all
easy. although, possible bad side-effect: wires drawing energy when bulb
switched off. maybe wires just reduce amount provided, not efficiency? or
maybe they're only considered when energy's actually used - counting the
number of hops from ps to bulb should be easy. or, I could just be mean and
have things drain energy anyways. this doesn't act *quite* like real
electricity but it's close enough.

btw, if the distinction between parts and bodies gets confusing remember this:
they're not really in the same dimension. the world may end up being 2d, and
you can't have a tangle of wires (or neurons) in 2d, so the parts *have* to be
off in some other dimension. it happens to be a magical one with no concept of
space; no physical limits like that, just variables and functions. but, stuff
can generally only act through bodies, because in order to use senses you
have to have a position in hte world. and you're probably not allowed that
without a body. so, objects with no body are isolated in nothingness, and
can't interact until they grow a body. hmm. makes it easy to store something
out of the way until it's done building itself, doesn't it? :) bodies have to
be inside the map, objects without bodies aren't on the map at *all* so
there's no icky need to hide them at -1000,-1000 like in c3.

dna: files or ram? well, it would depend on how many strands are in the world,
how big they are, how often they're needed etc. and how annoying it would be
to read them from files a lot. obviously we need some ram cache, and we'll
have some dna saved on disk... but should it all be in ram all the time?
should newly created dna be saved to disk right away? kinda also depends on
whether hte world has autosave too. and, I generally dislike the clutter of DS
world folders. especially since there's no indication of what half of it is
for.
inorganic dna (iow blueprints) would only be read on creation, although some
user might want to see it. organic dna may be consulted more than that so
that the thing can grow and breed n'stuff. I don't see any real need to write
dna out to disk when it'll probably be saved with the world... if the user
wants to keep norn data around, a history kit can be used. not certain whether
it'd be best to keep that server-side or client-side but it's no big deal.
as for keeping it in ram... well, it has to be available for organics enough
that there's proabbly no point deleting it. gadgets are unlikely to need it
after creation, but it must still be kept *somewhere* in case the user wants
it. well, probably. it's not a big deal for the functioning of the world but I
don't want black-box gadgets. besides, ho much space can a few blueprints
*take*? if stuff is cloned it can probably do copy-on-write somehow...

another point: should gadget dna be the same language as organic dna, or
should it be some different blueprint-thing, perhaps more human-readable?
well, it depends on a couple of things - do I want gadgets and organics to be
completely incompatible with each other? and do I want yet another languge to
interpret? :) I think the answers are obvious. besides, electrical wires and
neurons aren't all that different...

anyways, the creation process looks pretty similr right now. set up parts,
bodies, and vars; either have a pool of chems or wire things up; then set the
thing running. an electrical part in an organic will do nothing without a
power supply, and probably won't interact with the chems... hrrrm... but, what
if it *could*? cyborg creatures... critters running off electricity instead of
food... well, I dunno if an electrical part could produce the right chems to
keep the system in balance, but still. interesting-ness. and none of it
violates conservation of energy :)

hmm. I wonder what defines how objects react to being cclicked, picked up,
dropped, etc? well, hmm. pickup and drop only happen on hte main object... I
was planning to add 'grab' too so that sensible things can happen when a norn
tries to pick up something heavy. stuff like rocks wouldn't react at all; they
have no parts. smashy rock from c3 might be impossible, I'm not sure...
maaaybe I could make a part to handle smashing, later, but for now things are
generally indestructible. energy from dropping would probably be all heat &
sound. as for stuff *with* parts... let's start with the lamp. say we have a
switch part. clicking on it, pushing, etc all toggle whether it's on or off.
how it actually *turns* on/off I'm not sure. oh, and it would want a realated
anim. dropping it reallly hard might have a chance of breaking one of the
parts. as for organics... well, pushing a leaf generally does nothing. pushing
a critter, it might have a sense that picks up on that... er, but you might
not be pushing said part. deal with that later. some stuff might want anim on
pickup; actually, hooks for that might be directly in the body. not sure.
certainly parts can't receive physical events unless they have a body. which
raises the question, can the root body get those events? hmmmm. something to
think about.

now... something about gadgets. the lamp switch. what does it do internally
when it's turned on? well, it might have an anim, or that might be handled
aready by hte body. I see two types of switch: plain and dimmer. a plain
switch just goes on and off; a dimmer switch affects how much energy passes
through. these could both be phrased in terms of how much energy to pass
through; the plain one toggles between 0 and 1, the dimmer goes up in
increments of, say, 0.2, and the var is used when determining how much energy
to pass along. maybe "energyPass" or something, whatever. hrm, but nontrivial
wiring could complicate things again. I suggest limiting everything to one in
& one out for now. it's soundng more and more like c3 wires. but, while
hooking up things in c3 could be fun, it was really awkward to move stuff
around. I'm pretty sure it'd be easy to make a gadget-designer tool with
this... just pick your parts, hook them up, set any extra vars and out pops a
dna/blueprint. hrrrm, can parts have default bodies? or will that all be in
dna? because it'd be nice to have default graphics for common parts like
switches, and the anim would probably be the same even if you wanted a
different sprite... so yeah, it'd be nice to have defauts there, and then let
the dna override them if it wishes.doesn't make much sense to me for dna to
specify the anim sequence, anyways.

gui idea: why not have click as push, and shift-click as pull? would make norn
discipline easier too: push for tickle, pull for slap. or something like that.
but, will we still have tickle/slap actions when there's no distinction
between creature and critter?

so, hmm. thing is, parts have to have basic math operations available then -
setting vars, adding and subtracting from them. and mod, perhaps - if the
dimmer is at 1 and you click it, does it go back to 0? or do you have to
shift-click it all the way down again? also not sure if the dimmer should have
a fixed number of steps.

also, it might be useful if parts could be organised into some iknd of
hierarchy. we've already thought of two types of switches, and there could
easily be more types of dimmer switch; there'll probably be several types of
light-sensor and different types of eyes, too. if there could be some kind of
organisation it might help with dna; something could maybe mutate to using a
different part without getting something totally out of left field.

what if a part wants to animate some *other* part, though? um, no. parts
aren't supposed to assume other parts will exist. in the case of the lamp
switch and bulb... the bulb would handle its own animation, changing sprite
when the available energy changed. but, how will it know how  many
energy-levels to expect? well, it won't. I'll figure that out later. might
just be hardcoded. multiply energy by 5 and use that as the sprite #, or
something. of course, you wouldn't want to bother checking it every energy
pulse, only whn something changes... looks like I'll want some events for
managing energy stuff. maybe instead of a simple var for energy available,
I'll end up with functions that both set the new amount and alert anything
that might be affected by it.

I wonder if there'll be text parts... hmm... text *entry* can be handled by
the gui, at least, yay. but text display... what sort of cobs might want text
on their body? gadgets, I guess. leave it out for now.

what about soil? it's basically chems in the world... let's not think about
how they're stored or changed there, just about the parts... a root-part could
suck up stuff from the soil, but I'm not sure how it would filter waht it got.
a part for excretion would need a filter, too. iirc we have the liver &
kidneys for that... but... filtering is kinda hard when all the chems are in
one big pot.

oh, and the not having a presence without a body would be especially useful
for children 'growing' inside the mother. would have a way to skip the
body-parts of dna at first, then go back later and create them when everything
else is set up and ready. object will probably have a few internal vars to do
with stuff similar to the ds 'faculties'; we might not want the chem process
starting until we've got it all set up. of course, we could just get it all
created at once but that's less fun :)

hrm. another tough question: should properties be per-body or per-object? I'm
not sure if it might be too complex to have critters seeing every part on
every object. but otoh, not seeing them means they won't know gadgets have
buttons. and, some objects may not have a main body... might end up specifying
one of the part bodies as main if necessary. can't interact with the main body
anyways, it's just there to hold the parts together really. although it might
be edible, and it can be held or picked up... hrrm, I wonder if parts can be
ripped off by norns? :)

oh, but what about when you want a button to activate a bunch of other stuff?
not just a switch, a button. does the electricity have to go *through* it?
what if more than one pulse is needed for what's going on? can we have an
electrically-toggled switch? all this requires nontrivial wiring. so, I will
have to tackle the wiring design sooner rather than later. but if I follow c3
ports & wires, it should be fine.