Messages

16

Suggestions / Name Change

« on: April 25, 2008, 01:02:52 AM »

Ok, I have a website that I need for a charity event, and when I do a search for rsucoop.org, this site with my profile is listed #2. Can someone please change my username, just like a 1 to it? Thank you.

17

Darwinbots3 / Nutrients, Vitamins and Minerals

« on: April 25, 2008, 12:47:00 AM »

Wow. Ok.

The VItamin nutrient mineral cycle is nice. And the strongest smell would give the strength and direction, and speed it was moving relative to the object that emmited it.

Calcium is a Vitamin, Vitamin D, which can be used to create a so called exo-skeleton similair to a shell. This means a bot could emit vitamins and minerals at the same time to create different types of materials. The balance between mineral content and vitamin count would mean the difference between a flexible soft shell, or a hard brital one, or even an in-between variation. This would allow for veggies to produce effective exo-skeletons as a multi-bot, empty shells capable of absorbing some nrg, and the minerals are destroyed in shots, meaning the vitamins fall off and the shell erodes. Now we can produce acids and shells, acids would help keep a balance so defensive heavy bots dont dominate because of poor balancing. Acids are made from vitamins and energy. So we have several new shot types to consider:

Acid
Shell
Mineral
Vitamin

Shells should carry alot of mass with them, making them bulkier and slower, depending on the distribution of vitamin to mineral count, minerals are heavier than vitamins (teeth vs quarter). I think this answer some key ideas.

18

Suggestions / Implementing Sound

« on: April 21, 2008, 05:05:20 PM »

well what do I have to do?

Either wait a few months and I'll get around to it or download the source and start partying...

Ok, but I only know Basic, and html, so unless you can guarantee that I can amend the code in Basic or HTML, I dont think I could be muthc help. Also sound should be able to be disabled so if it does cause performance issues, it can easily be removed, or added for that extra bit of environmental realism.

19

Suggestions / Implementing Sound

« on: April 20, 2008, 11:10:00 PM »

Could this be used in 2.4x+?

If you are asking whether this coudl be implimented on the 2.4x code base, the answer is yes.  All it takes is time and effort...

well what do I have to do?

20

Suggestions / Implementing Sound

« on: April 20, 2008, 07:10:59 PM »

Could this be used in 2.4x+?

21

Bugs and fixes / .tin/.tout pairs not erased with tie goes away

« on: April 20, 2008, 07:10:00 PM »

The .tin/.tout pairs were not getting reset correctly with the other trefvars when a tie went away.

Also fixed an issue where all the trefvars would not get reset in the case where *.numties was non-zero but the tie port being attempted to read from was incorrect.  Now bots can reliably check to see if a tie still exists by trying to read from the tie number.  trefvars such as .trefxpos will be 0 for that tie port even when other ties still exist.

BRILLIANT! Maybe now the Evo Slim's Tie Communication genes would function properly lol

22

Suggestions / Implementing Sound

« on: April 18, 2008, 12:51:43 PM »

The only thing we have today that has a propagation delay are shots.  We could do something here leveraging shots...

Imagine a new "sound" shot type.  It propagates out from the shooter in a half circle at regular shot speed, it's range is limited and controllable via .shootval.  One diffrence between it and other shot types is that the shooter's speed does not impact the shot's speed.  The speed of sound is constant.   Another is it can't be seen (other shots types will be visible soon) or maybe it can.  Any bot the wave crosses before it dissipates completely is impacted.

What it does when it impacts is a matter of discussion.  Perhaps there are a handful of sound in/out pairs.  The shooter sets them before firing the sound, the shot impact sets them in the impacted bot.

What happens when a bot is impacted by multple sound shots in a single cycle is TBD.  Perhaps each shot has a shooter-settable power that dissipates as a function of range.  The "loudest" sound impacted a bot wins...

The .hit sysvars already provide a means for impacted bots to directionalize shots.

If shapes are specified to reflect shots, then they reflect sound shots, allowing for echo-location.

I'd have to impliment some new code to do circle-circle intersection for this shot type for impact detection and there will be a perfromance impact if this becomes heaviliy used, but I would say this option is doable in the mid term.

What if we did this for multiple shots? We create a sound buffer, which collects all information about a shot right after it impacts the bot, the bots ear goes 1+(1 for each other sound). THen the bot could randomly, or intelligently, sellect a sound its heering and try to interprut it. The only problem would be speed of simulation from that, it would give the bot the ability to hear only commands from a friend, or onyl calls from a mate, or something along that; a sort of ability to decifer its environment. I think we did this with the tin/tout system, only we didnt need 36000 vars

23

Suggestions / Implementing Sound

« on: April 18, 2008, 10:39:30 AM »

Ok, how about the sound waves haev to hit their bodies, and that lets them decifer the information in that wave; which could be a turn command, or a refvar, or a 'hey im in heat' system. And I say dont allow writing to memeory through sound, leave it to the hearing bot.

24

Suggestions / Implementing Sound

« on: April 17, 2008, 10:25:21 AM »

The inverese square law applies to the idea that their is no interference. SO we dont have to use it, plus its running through water. Maybe browian motion should produce some fuzzy sounds. But ok.

The idea of combination was to emulate how harmonics work irl. But if we dont want to, then ok.

25

Suggestions / Implementing Sound

« on: April 16, 2008, 07:21:27 PM »

I assume this is impossible Eric?

26

Suggestions / Implementing Sound

« on: April 16, 2008, 12:24:36 AM »

I'd have some design questions to start:

What happens when multiple bots are speaking at the same time?  Do the sound vars of a third or Nth bot represent a summation of the values spoken by the others?   Do values attenuate over distance?  Over what distance does sound travel (please say the same as vision).   I assume we use some standard distance/cycle ratio as the sound propagation rate.  If a bot is moving counter to the sound wave, does it miss words do to wave compression?

Implimenting this might prove computationally expensive, along the same lines as vision.  I'd have to keep a per bot buffer of the words spoken over the last N cycles and compute which words from which other bots strike each bot each cycle.  You can foget about things like reflection and attenuation due to shape corners, etc.  Too hard for now.

I guess I would want to dive a little deeper into the core functionality we want acheive with this before jumping into an implimentation.  For example, I've been toying with the idea of bots being able to gather and store another bot's ID, say as a new refvar  "refid", which gets populated along with the other refvars and trefvars.  A bot could then grab this and use it for various things including getting the refvars of a bot without looking at it (as long as it is within visible range) or using memloc/memval.    

If the goal is to create a "hey you, look at me over here" capability, we might simply add a sysvar that provides a bot with the ID of the nearest bot that happens to be looking at it.  

If the goal is provide a richer communication mechanism, I'd want to discuss how to enhance the in/out pairs first.  Requiring a bot focus on another to "hear" it is a huge compuation saver, but a bot could aim it's ears at another specific bot so to speak using the ID above and be able to receive the .in values from a bot without looking at it...

Ok, in situations where sounds overlap, a harmonic is created. So a harmonic array can be created to support say three overlapping sounds at a time. The information would be stored as independent to the other vars. The speed of sound:

In a fluid the only non-zero stiffness is to volumetric deformation (a fluid does not sustain shear forces).

Hence the speed of sound in a fluid is given by

 
where
K is the bulk modulus of the fluid

I would suggest using the same equation to slow the speed of the sound, thus reducing the ammount of information recieved, until it desolves. I would say make it last three times the maximum distance of sight, unless you want to emulate whale songs; but this could mean a bulk of refvars in the ear at once, and we could use disadence to remove certain bits of infromation.

Frequency Emulation:

So the value stored in a wave is a frequency, 1 = 1 hz, the lowest possible audible tone of a Darwinian. The lis of possible frequencies would be limited to DNA, and system specs.
I would suggest limiteing the frequency list to its maxmum, but audible tones should be somewhat lower since the higher frequencies are considered harmful in nature. The rules of physics can be aplie  to such a system, allow for sound to happen naturally, in numbers

Solution to Overlapping Sound Waves:

Say we have a harmonic array, 1, 3, 4. 4 is even, but in this case its also the only one not a prime, so it can be considered a weaker frequency, it will become disanant under the following conditions. Say we have the exact same harmonic array overlap this one, well the values wont change, but will effectively combine the two wave ranges to double their range, due to amplification. If the values are reversed, say 4, 3, 1 the 4's would cancle, as they are not in the sound scheme for swaps, and 3 and 1 would switch to the 1 and 3. Its simple for frequencies, differences of 10times is considered an octave, and a 1-3 is something close to a 2nd minor in music, common to songs of natives, a step from 3-4 is actually some mathematical thing that removes part of the tone in either, causing slight alterations +/- by 10%. Inversions of waves tend to cancle, depending on the magnitude and direction, but I say just use it for Overlapping waves with same direction and speed only. Using the same formula for Collisions, the sound wave colliding into another can be altered to change its speed, range and harmonic array/frequency.

I think this shouldn't be as difficult as everyone thinks. Its like a long range caller, that's faster than shots, and doesn't have to be visible, so that should curtail most usage, and as for the numbers. I think by simply combingning overlapping (or closely touching within 50% of eachother's space) will reduce the amount of bolk information being transmitted, and still provide some information to the listener. I also think if the combined wave contained the ID of all bots inside the Harmonic combination be included, then its a matter of genetic integrity and propper speech/learning routines to know and interprut what's heard, otherwise its like static.

Edit: as for moving ears, I say fix them to a point on the body so it requires a rotation of the bot, then they can aim there eyes if they want, but the bot cannot take refvars from the eyes and ears at once. Similar to the bumb feature, only the information contained in a wave can be recieved, understood, and acted upon, while being able to look at another bot, and send/recieve information. The sound would enter the ear and disapear, so in that instance the bot must store the values, or lose the information. I think that there has to be a way to override the ears, to emulate deafs, and to prevent combat situations where a bot screams at another and it cuases the bot to go blind in combat... When a wave hits a bot, consider the Harmonic array to exist as thirds of the wave. Lower third 1st number, Middle 2nd number and Tp is 3rd number. As each third/number hits a bot, it goes away, and the rest go on until out of energy/mnomentum or hit a bot. THis could mean that some information may be lost, but could be effected for group theory, since it could hit multiple bots, and the recipients could use any of the numbers in that refvar included in the wave, to alert others, or act another way when more of the information in the wave is found later by another bot that recieved a bit of the wave.

1 ear or 2 I ask...

27

Suggestions / Implementing Sound

« on: April 15, 2008, 10:53:45 PM »

Eric, any ideas about this?

28

Bugs and fixes / .in9 and .in10 don't work

« on: April 11, 2008, 07:28:48 PM »

I vote 3. I dont see why I would want backwards anything. I'm mroe for forwardism thank you.

29

Suggestions / Implementing Sound

« on: April 11, 2008, 06:20:16 PM »

You realize, of course, that sound does not spread as a one-directional squigly line

Yes, it be shaped like ) and head -> respectively. Its more of a percentage of effetiveness to transmit/recieve. A mouth projects outward, so the sound is focused in a central forward area, those behind can hear some things.

30

Suggestions / Implementing Sound

« on: April 11, 2008, 01:06:38 AM »

Craete a point and call it the mouth, say its right where the eye/gun is. Everytime a value is stored in it other than 0, a curved line is shot forward at speed of something. When it hits another bot it does 2 different things. If sound hits back, only half of the information can be heard, if it hits the front it hears all the information. The curved packet would require a fwe out vars, so they can be read when hit. I say 20. But limit 10 of them to 1s and -1s (or 0) only. This would give the ability to create language for greater distances, but should be somehow linked to multi-bots. Perhaps upon collision both out vars in each bot are stored into the packet of the curve, and shot out of either bot with the 1 in the mouth var. I think this would open the doors for a truely intelligent species.