Jump to content

JohnathanMacBride

Resident
  • Content Count

    29
  • Joined

  • Last visited

Community Reputation

0 Neutral

About JohnathanMacBride

  • Rank
    Member
  1. Thanks, yes I am aware of that limitation. Attributions will be included. As of yet everything i have is hand coded by myself, but anything borrowed will be attributed. The idea is to save a location, make it retrievable and selectable by menu, then a teleport ensues from the 'active' or 'selected' destination. Global coordinates would make the most sense, however, an identifiable name for each location would be a must for retrieval also. This has been a lot of help, I am glad to have such knowledgeable people so close at hand.
  2. After doing additional research, it seems that as long as the script is not reset, I can even us Strided lists to store the data. again, I will be checking to see which is most cost efficient. Thanks for the advice and I look forward to anything anyone else has to offer.
  3. on that note, is json a viable option?
  4. This would be grid wide and external to experiences, so kvp records are probably out. however I could do lists with an import/export function for data safety. I am dealing with either landmark locations e.g.: simname/x/y/z or global coordinates for each location. So I am looking at either a string, string vector combination or strictly vector data per location. whichever turns out to be less storage intensive. where can i find more about encoding to hexadecimal?
  5. I am trying to create a HUD that saves locations, how would I go about doing that other than child prim descriptions? whats the maximum number possible?
  6. So with what I am gathering it would take a considerable amount of math to make sure the position is correct for all articulated joints/objects in the turret?
  7. I currently have the following function implemented doorOpen1() { vector posClose = llGetLocalPos() - offset1 * llGetLocalRot(); vector posOpen = llGetLocalPos() + offset1 * llGetLocalRot(); linkNum = llGetLinkNumber() + 1; if(!isOpen) { llSetLinkPrimitiveParamsFast(linkNum, [PRIM_POS_LOCAL, posOpen]); } else if(isOpen) { llSetLinkPrimitiveParamsFast(linkNum, [PRIM_POS_LOCAL, posClose]); } } that handles door state and the open/close function via llSetLinkPrimitiveParamsfast(). There is one function for each door as the open offset is different for the two doors. I don't intend on making this universal for one to N doors. it is simply for a set of two doors that slide open. A side question, is anyone familiar with non blocking functions in single threaded applications? similar to pipelining? I am trying to figure that out as well.
  8. That does definitely help me understand more,and it does present a different method for doing things. Thank you.
  9. Yes, like that. The only reason I have not purchased any scripts is because I am trying to become more skilled in scripting and felt it would make a good challenge. I have moved all my functions for the doors to my single controller script. I have not yet gotten it to work but with a few debug messages in place I should be able to locate what is going wrong.
  10. I am working on a door assembly. an automatic sliding door assembly for somthing I am building. I find that using any kind of rezzing system can be a pain when you have unlinked doors and thought it would be convenient if I could have these doors operate, linked to eachother or linked to the build as a whole. I am still learning to script and so it does get confusing. I will explore the possibility of taking the child prim scripts and combining them into separate functions in the controller and see how that works out. Thank you both for your input and I am more than open to advice as it is offered.
  11. I managed ot make a little progress by moving the link number detection to the child objects while using LINK_ALL_OTHERS link_message(integer sender_link_num, integer channel, string msg, key l_id ) { integer linkNum = llGetLinkNumber(); vector posClose = llGetLocalPos() - offset * llGetLocalRot(); vector posOpen = llGetLocalPos() + offset * llGetLocalRot(); if(channel == sender_link_num) { Do Stuff } } This essentially recieves two integers in the link message, the sender link number and a number assigned the variable name channel. in the control prim which may or may not be root at the time it is triggered, it sends llMessageLinked() with the second integer parameter set like this integer linkNum = llGetLinkNumber(); what this does is pass two variables that SHOULD be identical, the only caveat I have discovered is that the test registers true for both sets of scripted objects in the lnk set. so now I need to differentiate.
  12. I am working on a script set that will operate in a link set. Due to the fact that this will be required to operate with varying numbers of objects in the link set, and with multple instances of this script set in one linked object I am trying to overcome the issue of the llnk number identifications when the link number could potentially change. I am not the greatest at scripting so I have not yet found a way to do this. I have gotten things to work with three linked objects, the controller script sending the messages set as the root. if I link 6 together 3 and 3 then both sensors trigger all of the remaining prims rather than the 'Assigned' prims So to break it down link number 0 needs to affect 1 and 2 and link number 3 needs to affect 4 and 5 but 3 should not affect 1 and 2 and 0 should not affect 4 and 5. Is there a way to do this? I have tried the following: PRIM 0 llMessageLinked: llMessageLinked(linkNum + 1, 0, "close", NULL_KEY); llMessageLinked(linkNum + 2, 0, "close", NULL_KEY); second llMessageLinked does not go out. only prim 1 of the link set changes. it only works if I put: llMessageLinked(LINK_ALL_OTHERS, 0, "open", NULL_KEY); LINK_ALL_OTHERS is too broad of a scope for what I am trying to do. I need to target 'hopefully', if it's done right, The next two linked prims up from the controller only. PRIM 1 & 2 link_message: if (msg == "open") { if (isOpen == FALSE) { ~code here~ } } The child prims are set to respond conditionally to the controllers llMessageLinked() message. but only the next two up from the controller, if the builder has linked the objects together properly. Any thoughts or ideas on how to work around this would be greatly appreciated. Johnathan
  13. So perhaps an OBJ export then Export from Blender to Collada? I think I can do that.
  14. I was afraid of that. It is a Prim build right now, so I may scrap the idea altogether.
  15. I was able to find a plugin for Blender called MeshLint that analyzes and removes unnecessary geometry and faces and such. I ran that and re-ran the AO Bake, results were much better. My next Conquest is going to be physics. Apparently Blender Doesnt Currently Support exporting Physics Data with Collada Files. Found a solution using Unity 3D. I will report my findings once I have tried it. Thank you both again.
×
×
  • Create New...