UGX-Mods Login

or login with an authentication provider below
Sign In with Google
Sign In with Twitter
Sign In with Discord
Sign In with Steam
Sign In with Facebook
Sign In with Twitch

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - Archaicvirus

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.
7 years ago
Dude, that is bad ass! Great work man, I liked the brewing one you did too. +1
7 years ago
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
7 years ago
Code Snippet
Plaintext
if(player IsTouching(poi.trig)){
while(player IsTouching(poi.trig)){
poi.poi_active = true;//Turns point of interest on
IPrintLnBold("Inside");
wait(1);
}
}else
poi.poi_active = false;//Turns point of interest off
IPrintLnBold("Outside!");
wait(1);

don tuse the else-statement here, the if-statement was allready true so it wont execute the code under the else-statement

Thanks for the correction man.

He's right, this is where the problem is.
7 years ago
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

Code Snippet
Plaintext
self.shader_var[self.shader_var.size] = NewClientHudElem(self); 
//And then you don't have send 'position' as an argument.

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.

Code Snippet
Plaintext
//Do the following for each shield piece:
//If you haven't already, drop down a trigger_use
//Give it a targetname of the part you're grabbing
//Now drop in a script_model of the shield part, and deselect it
//Now first select the trig, then select the script_model
//Hit W to link them. Now select both and save as a new prefab
//This will be a random spawn point for each part. Place at least 3 of these around the map

function buildable_shield(){
level flag::init("shield_finalflag", false); //For when all parts are collected
level flag::init("shield_part_1_flag", false); //For each individual part
level flag::init("shield_part_2_flag", false);
level flag::init("shield_part_3_flag", false);  //The flag commands are explained at the top of the buildables script

shield_parts[0] = GetEntArray("part1_targetname", "targetname"); //Obv change targetnames to yours
shield_parts[1] = GetEntArray("part2_targetname", "targetname");
shield_parts[2] = GetEntArray("part3_targetname", "targetname");
       
        thread random_spawn(shield_parts[0], "shield_part_1_flag", undefined, "pick-up hintstring"); //The hintstring threaded here only needs to be the name of the part
thread random_spawn(shield_parts[1], "shield_part_2_flag", undefined, "pick-up hintstring"); //As the "Press [Use] to grab" section of the hint is already set
thread random_spawn(shield_parts[2], "shield_part_3_flag", undefined, "pick-up hintstring"); //Like "shield-top", "shield-screws" or whatever they are

//Create a trigger_use where you want to craft the shield
//Drop a script_origin and place where shield will spawn once crafted
//Select trig, then script_origin, W to link, then
//I suggest changing these variables to something that makes more sense to you
//I don't think you're stupid, I'm just making these long variables so it's understandable what their purpose is

shield_craft_bench = GetEnt("name_of_trigger_where_shield_is_crafted", "targetname"); //Again change the targetnames for yours on these
shield_craft_bench.shield_spawn_location = GetEnt(shield_craft_bench.target, "targetname");
shield_craft_bench thread build_logic(shield_craft_bench.shield_spawn_location.origin, "shield_finalflag", "shield_part_1_flag", "shield_part_2_flag", "shield_part_3_flag", "build hintstring");
//build_logic(bench_fx_loc, final_flag, part1_flag, part2_flag, part3_flag, build_hint)


//Not trying to be a code snob, but you can take it from here. You got this
//Everything you need is in the script already, just follow the threads.
//I think you should make your own functions for this and use the script lines from my script that you need

//For the shaders, Destroy() or hud_util::destroyElem() deletes them
//To spawn the shield once crafted, you can place the parts as script_models in radiant at their final location,
//then in script do getent on them, then Hide() and Show() as needed,
//or you can do part = Spawn("script_model"), then part SetModel("name_of_precached_model") once crafted, to spawn them when needed
//As far as the shield functionality, that is something I don't have experience with.
//I would ask someone else for help on that, if you don't how to get it working.
//Good luck man
}
7 years ago
Thanks for the info,  give me a few and Ill respond on my pc.
7 years ago
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.

 
7 years ago
Thanks man, if it helps, regardless of the size of the image, you can dictate the draw size when you thread
Code Snippet
Plaintext
part_shader_logic(shader, position, size_x, size_y) //size_x = width, and size_y = height

 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.
7 years ago
How can i change the lightning state? For example like use a trigger or something and the skybox changes? Is this possible?
Code Snippet
Plaintext
void SetLightingState(<new light state>)

[MANDATORY] <new light state> new state to change to. Lighting state defaults to 1 at start of game
CATEGORY:
CLIENT/SERVER: Server
SUMMARY: Changes lighting state for the map
EXAMPLE: SetLightingState( 2 )
trig waittill("trigger");
SetLightingState(2);

ambient lighting
lightning bolt
:accepted:

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.

7 years ago
Glad to help man, just let me know how it works out for you with an answer, if you would.
7 years ago
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.

Code Snippet
Plaintext
function test()
{
        //Edit - adjusted for clarity

        //First, define the array.
        //Objects excluding script_struct's in radaint should use GetEntArray("key", "value"); and not struct::get_array
poi_array = struct::get_array("exclusion_zone", "targetname");
        //Let's say you have 5 structs all named exclusion_zone

        //When you do a foreach() loop, you can name the 'item' in the 'group' anything you want
        //For example below, 'foreach(struct in poi_array)' you can call 'struct' anything, it's a temporary variable only defined
        //within the for() loop.
        //Like foreach(thing in things), or foreach(guy in things), but the 'things' has to be an array, that you
        //define outside of and before the for() loop occurs. This can be used with any array, regardless of it's contents or application.
foreach(struct in poi_array)
{
//For each struct in the array "poi_array" defined above,
//execute this code 1 time for each struct:

                struct.trig = GetEnt(struct.target, "targetname");
struct thread some_function();
}

}

function test2()
{
poi_array = struct::get_array("exclusion_zone", "targetname");
//Let's say you have 5 structs all named exclusion_zone

//This is the same as foreach, except in an array,
//the first object is index 0, then 1, 2 etc.
//And you loop through that array with 'i' which starts at 0,
//and loops until poi_array[4], which would be the 5th index.
for(i = 0; i < poi_array.size; i++)
{

IPrintLnBold("Hello I am struct #:"+i);
trigger = GetEnt(poi_array[i].target, "targetname");
poi_array[i].trig = trigger;
poi_array[i] thread some_function();

}
}

function some_function()
{
//Each poi struct becomes 'self' in this function.
//So self.trig is the same as poi_array[i].trig above or struct.trig in the first function

self.trig waittill("trigger", player);
IPrintLnBold("Hello my target is at"+self.trig.origin);
}

//Or, if you're really hungry, you could do
function get_donuts(){
        a_dozen = GetEntArray("box_of_donuts", "script_food");
        foreach(donut in a_dozen){
        donut thread deep_fry();
        while(donut.is_cooking){
                donut waittill("minimum internal temperature reached");
                donut.is_done_cooking = true;
        }
        donut thread dip_in_chocolate_glaze();
        donut thread cover_in_sprinkles();
        break;        //For a taste test. :)

}

Hope that explains it a little better.

edit* - Fixed some typos in the scripts and the earlier replies as well.
7 years ago
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 pm
Actually 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:
Code Snippet
Plaintext
	function init(){
                //Edit - changed to struct::get_array not struct::get.
points = struct::get_array("exclusion_zone", "script_noteworthy");
foreach(point in points){
point.trig = GetEnt(point.target, "targetname");
point zm_utility::create_zombie_point_of_interest(100000, 99, 25, false);
point thread zm_utility::create_zombie_point_of_interest_attractor_positions(5, 100);
point thread zm_utility::wait_for_attractor_positions_complete();
point thread exclusion_zone();
}
}

function exclusion_zone(){
self.trig SetCursorHint("HINT_NOICON");
self.trig SetHintString("Exclusion Volume");
while(1){
self.trig waittill("trigger", player);
if(player IsTouching(self.trig)){
self.poi_active = true;
wait(1);
}else{
self.poi_active = false;
wait(1);
}
}
}

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.
7 years ago
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?
7 years ago
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:
Code Snippet
Plaintext
#using scripts\codescripts\struct;
#using scripts\zm\_zm_utility;
#using scripts\shared\flag_shared; //edit: You might need this too

function poi_test(){
        level flag::wait_till("all_players_connected"); //edit
poi = struct::get("custom_poi", "targetname");
poi.trig = GetEnt(poi.target, "targetname");
poi.trig SetCursorHint("HINT_NOICON");
poi.trig SetHintString("Zombie exclusion volume");
// attract_dist, num_attractors, added_poi_value, start_turned_on, initial_attract_func, arrival_attract_func, poi_team
poi zm_utility::create_zombie_point_of_interest(100000, 99, 25, false);
// num_attract_dists, attract_dist
poi thread zm_utility::create_zombie_point_of_interest_attractor_positions(5, 100);
poi thread zm_utility::wait_for_attractor_positions_complete();
while(1){
poi.trig waittill("trigger", player);
if(player IsTouching(poi.trig)){
while(player IsTouching(poi.trig)){
poi.poi_active = true; //Turns point of interest on
wait(1);
}
}else
poi.poi_active = false; //Turns point of interest off
wait(1);
}
}
7 years ago
(Note: Again, I originally posted this on modme, but I decided to post it here in case any ugx-only users needed it  :alone:)

(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:
Code Snippet
Plaintext
void SetMovingPlatformEnabled()

CATEGORY:
CLIENT/SERVER: Server
SUMMARY: Enbles the moving platfrom.
EXAMPLE: platform SetMovingPlatformEnabled( true ) //Elevator gets threaded as self here
// elevator thread SetMovingPlatformEnabled(true);

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.
7 years ago
Loading ...