I've made a model of a crate, and made the animations for it to open and close it's lid in maya 2014. The problem is I don't really know the bone hierarchy that I need to follow. I tried making a bone called "tag_origin", then made it the parent of another bone called "tag_lid". I selected the lid of the crate, then hit bind>rigid to the "tag_lid" bone. I set the bottom of the crate to bind>rigid on the "tag_origin" bone. I can play both the animations in maya, and it looks fine, when the lid opens and closes, but in ape the box is sideways, and the animation doesn't play. Any help is appreciated.
*In APE I have the xanims set up as Type>delta. I enabled the option to view bones in the ape preview window, and I can see the tag_lid bone swinging open, but the lid isn't attached to the bone, I don't understand why because when playing the anim in maya it is attached and looks fine.
Sweet man, and glad to assist. I don't mean to seem condescending in any way, my thing is I just try to explain things in high detail since I don't know how much you might already know about the subject. Plus other readers can understand more. I learn a lot just looking through the help forums myself, even when I'm not having any particular issue. Which is all the time lol
It looks like you already figured it out, but in case you don't fully understand the way I did it, when you thread part_shader_logic(shader, position, size_x, size_y) the position determines the index of each shader in the player.shader_var[] array for every player. There are different and probably easier ways to do that, for example in part_shader_logic() you could do
If you gave them all the same position, regardless of where you align each shader, it overwrites the last hud created since it's using the same array index as the previous one.
Honestly this whole script in my opinion is messy and desperately needs to be re-written in a more user-friendly way. I plan on making it more dynamic also, so all of the functions can just be threaded with arguments, so the user doesn't have to change the functions, only the arguments. It's mostly that way now, but not in all the functions.
I got your pm, but if you don't mind, post the exact script you're using in code tags here, and I'll take a look at it. That way other people can learn from this, and I can see which one of my examples you're using. And also, what is your radiant setup? Give me a brief explanation on the trigger and struct setup you have. A screen shot of their kvp's will also help.
Thanks man, if it helps, regardless of the size of the image, you can dictate the draw size when you thread That's what I did to scale the shaders down for split screen players, and even the full screen shaders are drawn scaled down a bit I believe. I did it that way because I wanted to have a slightly higher definition image to work with in photoshop, but not so high that downscaling has a negative quality impact. Especially when you're manually cutting out pieces of an image, I find once you downscale it, any edge artifacts are virtually eliminated (such as slivers of the background left behind when cutting out the lever)
In any case, you almost always have to re-scale your image in the end, unless you make it the perfect size from the start, I'd imagine.
How can i change the lightning state? For example like use a trigger or something and the skybox changes? Is this possible?
ambient lighting lightning bolt
I haven't done this before, but the tutorials I've seen describe first setting up an additional lighting state within your map using radiant. Your default skybox should be ssi1, out of a total 4 states. You would set up a different skybox on ssi2, so when you switch lighting states... you guessed it. There is a tutorial on this already, here I believe. I don't know the entire process, but hope that helps.
Foreach means you are iterating through an array (in this case), so you are saying for each item in this group, do this to them. Here's a more practical explanation.
Hope that explains it a little better.
edit* - Fixed some typos in the scripts and the earlier replies as well.
Haha yea sorry man, it's kind of hard to explain, but it's really easy in the end. Double Post Merge: June 13, 2017, 10:04:39 pmActually to be honest, linking the two objects does do more then what I described before. Generally when you link objects, the targeted object will auto-generate a targetname kvp. It will be like "auto1" or if you've linked a lot of objects, "auto17". This is useful for a lot of different reasons. Lets say you wanted to make multiple exclusion zones, you could link the two objects like I said, then save them as a prefab. So when you stamp copies of that prefab around the map, the targetname of the struct will stay the same, but each trigger will have an "auto3" or some number generated unique to it's parent's struct. That way you could do something like this:
I haven't tested this exact script, but it comes from one of my scripts and I'm doing something similar, although I wrote this a little different for your application. But again linking objects does have a benefit depending on what you're trying to do. This method makes it so you don't have to write a separate function each time you want to make another exclusion zone. And also I haven't tried this with a trigger multiple, but I have this working on a trigger_use. So you might not want a hintstring on a trigger multiple.
Another idea you could do, is make multiple exclusion zones (triggers), but link only one struct to all of them, so no matter which exclusion zone the player is in, the zombies will always go to the same place.
Linking the struct to the trigger does nothing, other then making the trigger easier to grab in script. It's just something I generally do to keep things simple. But essentially when you link two objects, the object that targets the other gains the kvp: target: (targetname of targeted object). So now struct.target equals the targetname of the object that the struct is targeting. COnfusing?
Create a script_struct in radiant, give it a targetname of custom_poi. Then create a trigger_multiple where you want the safe zone to be. Now, select the struct first, then select the trigger, hit W to link them. Place the struct where you want the zombies to go when you're in the exclusion zone. Then do this in gsc:
(Note: Again, I originally posted this on modme, but I decided to post it here in case any ugx-only users needed it )
(Content removed from quote.) Hello again! (I know it's been a while...) I recreated my elevator script, which adds one main feature: You can now call the elevator. This should fix prior problems with having to make it start at the top, plus some people here and lots on Modme were asking for the call feature. In case you never saw the first post, here are the features: -Sliding Doors -Elevator -Call Feature -Editable numbers (You can adjust the elevator to your liking) All of the things you will need are in the download (I've made it so you no longer need a separate download if your doors open sideways)
IMPORTANT: Please DO NOT re-upload this script. If you are going to use this in your map or video, please credit me. (Ex: "ZombieKid164 - Youtube: http://www.youtube.com/channel/UCAm_2-Z_RGUmkLJcN1OfJrQ ") Also, if you want to turn off the debug text, set zk_debug to false in the script (Forgot to add that to instructions). I hope you enjoy this script! Thanks, and happy modding! -ZombieKid164
Nice, scripting. Just one suggestion though, I've done elevator scripts before, and the problem is that players glitch through the floor iif they jump around or move too much. You can solve that problem by using this function on the elevator floor:
This will match the player's velocity with the elevator's, and prevent any derpy behavior. *edit - Also I believe in radiant there is an option on script_model and script_brushmodels to enable them as a moving platform. It's in the kvp's, I have only tested the function via script though so you'd have to test that.