Cronus: The Ultimate Drone

**DarkMonkey** · 06-05-2009

*cough* the name is from greek mythology *cough*
Scary idea, this might be a good excuse for me to learn applyforce heh

**Magos Mechanicus** · 06-05-2009

*cough* The name Chronos is older than the Incredibles by more than 2 thousand years *cough*

Anyway, it certainly seems like the sweetest drone yet. One thing I keep coming back to here is my ragdoll holomarionette - something like its underlying vector and matrix math might prove very helpful in making a rotatable humanoid figure whose scale is variable (since it might find big props, or small ones). It might even be possible to keyframe animate, although the amount of data needed would be massive. I wonder, though, if one single expression is the best thing. Splitting it up a little and having the thing "steal" additional libraries in the wild such as an animation library does give it a certain extra "They tried to stop it" flair.

**Lyinginbedmon** · 06-05-2009

Originally Posted by Magos Mechanicus

I wonder, though, if one single expression is the best thing. Splitting it up a little and having the thing "steal" additional libraries in the wild such as an animation library does give it a certain extra "They tried to stop it" flair.

Scale is inhibited by the box measurements, the give/take value allows it to have certain tolerances for props that are bigger or smaller than what it would ideally like.

I'd like to hear some more on stealing libraries though, that's very intriguing.

EDIT: And done some work with the first post's model and gotten the box sizes from all the props.
Arm, vec(24,12,12)
Leg, vec(24,12,12)
Pelvis, vec(19,19,6)
Skull, vec(17,14,15)
Torso, vec(36,36,1)

**Magos Mechanicus** · 06-05-2009

Yeah, but I'm thinking we can go one better than that. See the second and 3rd pictures here? The change between them is one number, the Scale variable; it compresses or stretches the positioning of each hologram prop so that the hologram shrinks or grows but everything is in the same relative position. It could do the same for physics-enabled props, I believe. The hard part would probably be getting the scale right - I'm thinking scale to the largest/average length of the props' box sizes, or some multiple thereof.

Libraries or modules or whatever could be done at both ends of the complexity scale. For animation, the library could simply be a static E2 with one array output full of 4*4 matrices with position and orientation data for each prop in the body at different frames of animation. If the array is wired up, then the main E2 loops through it as it's moving and adds the resulting vector onto the default positions of each prop and rotates the prop into the orientation specified. The result would be that without such a library, the props simply glide forward in eerie unison, but when it steals an animation library it starts walking, or linedancing or whatever the animation is.

More involved libraries might be for instance one that handles your idea with the prop spawner missile - this would run separately, having a few inputs like a target entity, when to fire and so on. Once this has been found the master expression can simply order it to attack one target and then focus its own attacks (swinging at things with the main body) on something else.

**Lyinginbedmon** · 06-05-2009

Well, that would simply be awesome, perhaps give the code a specific number of animation array inputs, so it has a few to choose from, though I'm hesitant to split weapon code from the main chip because it leaves it more vulnerable if the drone isn't around to handle any attackers but essentially invulnerable if they're only attacking the main drone. I've no clue how matrices work, despite following them in their development, so possibly that's a feature for you to work on?

Meanwhile, expanding the body part finding code, I've hit a couple issues.

Initially I had the code looking for props that were missing and outputting the IDs once they were found (The nature of it's working means that it's only going to ever assign a given prop once, so each ID should be different). I also first added in a flipswitch function to keep the code from trying to use entity discovery functions too often. I then modified it to only look for unfrozen and unconstrained props.[highlight=E2]@name Cronus body part finder
@outputs SiD TiD PiD A1iD A2iD L1iD L2iD
@persist O:entity C:entity Body:table BodName:array GT
@persist Potents:array Check Pos Pierre
@persist Flip Switch
@persist Skull:entity Torso:entity Pelvis:entity
@persist Arm1:entity Arm2:entity Leg1:entity Leg2:entity

if(first()){
O = owner()
C = entity()

GT = 10

#Body table gives the body parts their box sizes
Body:setVector("Skull",vec(17,14,15))
Body:setVector("Torso",vec(36,36,1))
Body:setVector("Pelvis",vec(19,19,6))
Body:setVector("Arm",vec(24,24,12))
Body:setVector("Leg",vec(10,10,43))

#BodName array gives the body parts numerical equivalents for their sizes
BodName:setString(1,"Skull")
BodName:setString(2,"Torso")
BodName:setString(3,"Pelvis")
BodName:setString(4,"Arm")
BodName:setString(5,"Leg")}

#Entity discovery flipswitch
if(Flip){
Switch = 0
timer("playerED",findPlayerUpdateRate())
timer("chipED",findUpdateRate())
if(clk("playerED")){Switch++}
if(clk("chipED")){Switch++}
if(Switch == 2){Flip = 0}}

runOnChat(1)
#Initiating a new area check for body props
if(O:lastSaid() == "!body check" & chatClk(O) & !Flip){
findInSphere(C

os(),1000)
findClipToClass("prop_physics")
findSortByDistance(C

os())

Potents = findToArray()
Flip = 1}

#Changing the give/take value
if(O:lastSaid():lower():left(3) == "!gt" & chatClk(O)){
Mes = O:lastSaid():lower()
GT = Mes:right(Mes:length()-4):toNumber()}

#Checking the props
if(!Skull|!Torso|!Pelvis|!Arm1|!Arm2|!Leg1|!Leg2){
runOnTick(1)
if(!Skull){Pierre = 1}
elseif(!Torso){Pierre = 2}
elseif(!Pelvis){Pierre = 3}
elseif(!Arm1|!Arm2){Pierre = 4}
elseif(!Leg1|!Leg2){Pierre = 5}

E = Potents:entity(Check)
if(!E:isFrozen() & E:getConstraints():count() == 0){
#Box sizes of the potential body part
Box = E:boxSize()
L = Box:x()
W = Box:y()
H = Box:z()

#Box sizes of the missing body part
Bod = Body:vector(BodName:string(Pierre))

BodX = Bod:x()
BodY = Bod:y()
BodZ = Bod:z()

if(L < BodX+GT & L > BodX-GT){Pos += 1} #Length size, give or take
if(W < BodY+GT & W > BodY-GT){Pos += 1} #Width size, give or take
if(H < BodZ+GT & H > BodZ-GT){Pos += 1} #Height size, give or take

if(Pos == 3){
if(Pierre == 1){Skull = E,SiD = E:id()}
elseif(Pierre == 2){Torso = E,TiD = E:id()}
elseif(Pierre == 3){Pelvis = E,PiD = E:id()}
elseif(Pierre == 4 & !Arm1){Arm1 = E,A1iD = E:id()}
elseif(Pierre == 4 & !Arm2){Arm2 = E,A2iD = E:id()}
elseif(Pierre == 5 & !Leg1){Leg1 = E,L1iD = E:id()}
elseif(Pierre == 5 & !Leg2){Leg2 = E,L2iD = E:id()}}
else{
Pos = 0
if(Check != Potents:count()){Check +=1}
else{BCheck = 0}}}
else{Check++}}[/highlight]In the first version, I hit the problem that Arm2 was never assigned, and both legs remained unassigned as well, despite everything else working.

The error for that probably rests in the assignment section.[highlight=E2] if(Pos == 3){
if(Pierre == 1){Skull = E,SiD = E:id()}
elseif(Pierre == 2){Torso = E,TiD = E:id()}
elseif(Pierre == 3){Pelvis = E,PiD = E:id()}
elseif(Pierre == 4 & !Arm1){Arm1 = E,A1iD = E:id()}
elseif(Pierre == 4 & !Arm2){Arm2 = E,A2iD = E:id()}
elseif(Pierre == 5 & !Leg1){Leg1 = E,L1iD = E:id()}
elseif(Pierre == 5 & !Leg2){Leg2 = E,L2iD = E:id()}}
else{
Pos = 0
if(Check != Potents:count()){Check +=1}
else{BCheck = 0}}[/highlight]Pierre is really somewhat superfluous if I just use the part name string itself, but for now it's a handy little reference. I'll take it out once this issue is resolved.

In the second version, when I added the unfrozen & unconstrained piece, I kept getting a LUA error from array.lua that prevent the whole thing from seemingly functioning, though it still validated without issue and the Q menu responded to it with no validation issues.

**Lyinginbedmon** · 06-05-2009

For the modules, library chips, etc. there'd need to be a predefined way for the OS to recognise them.

For example, the library chips could have the following assortment:[highlight=E2]@name Running animation module
@outputs MType:string MSpeed MLoop MArray:array

MType = "Anim"
MSpeed = 100
MLoop = 1[/highlight]MType tells the chip what kind of library/module it's found, MSpeed tells it how quickly to run through the array (So walking and running animations can differ in their speed) and MLoop tells the chip whether the array is made to be looped (Do the matrices return to their starting position or close to it?).

Using string decryption, we could combine these outputs into a single string output. For example, the above chip might have the MArray:array output and a MDef:string output, which might say "Anim+100+1", and the chip would decipher the different pieces by seeing where the + occurs and selecting information before, after, and between them, converting to numbers where appropriate.

We could even break it down further and obviate the drone's need to wire to the chip first to find these details out. The drone needs to find the chip in the first place to recognise and wire to it, so it already starts off with the chip's entity. The drone may send a data request signal to the chip, which it will respond to in the group containing the above string. The drone can then get the string using signalGroup(). In which case, the chip opener would be slightly more complex.[highlight=E2]@name Running animation module
@outputs MArray:array

if(first()){signalSetGroup("Anim+100+1")}

runOnSignal("identify",1,1)
if(signalClk()){
OS = signalSender()

signalSendDirect("acknowledged",OS)}[/highlight]

**Magos Mechanicus** · 06-05-2009

That is a weird error - it comes up in R:count() but there's only one instance of it in that expression and if you remove it the script error still comes up.

Anyway, I did a first pass on a main positioning loop. Rough around the edges, mainly because I did the orienting of the props with quick and dirty PYR rather than something that actually works like direction vectors, so many of the the orientations that are in your pictures are gimbal locked. Will have to redo that bit, but just thought you'd like to see it.

[highlight=e2]
@inputs Bodyparts:array
@inputs Masterent:entity
@persist Defaultpos:array Defaultangle:array

if(first()){
#Define default positions
Defaultpos

ushVector(vec())
Defaultpos

ushVector(vec(0,0,-25))
Defaultpos

ushVector(vec(0,25,-30))
Defaultpos

ushVector(vec(0,-25,-30))
Defaultpos

ushVector(vec(0,-10,-60))
Defaultpos

ushVector(vec(0,10,-60))

Defaultangle

ushAngle(ang(0,0,0))
Defaultangle

ushAngle(ang(60,270,0))
Defaultangle

ushAngle(ang(0,90,0))
Defaultangle

ushAngle(ang(0,0,0))
}

Masterent=entity() #For testing; can be replaced later
Localframe = matrix(Masterent)
#Positioning is done with PD controllers.
#Genericize so it's easy to copypaste
P=10 D=-0.8 Index=1
runOnTick(1)

if(tickClk()&Bodyparts){

Current=Bodyparts:entity(Index) Goal=Defaultpos:vector(Index) #Animation gets added here
Goal = Masterent