Your error has nothing to do with your FX, the error says there is no function named
Code Snippet
Plaintext
load_weapon_spec_fr0m_table
i have a feeling it is because in the word "from" there is a "0" instead of an "o"
Thanks for the reply. I eventually noticed that and fixed it. Weird, I don't know how that got changed. Anyways, I got everything working now, except I can't see the fx in game. I have Iprints showing me the relative difference in origin as a vector, that is between the player and the fx model. I'll eventually figure it out or post a new help topic if I can't resolve it. Thanks again.
Does anyone know the proper method to set up fx via script? I used ugx easyfx for codwaw, and understand that fx need to be precached whether they are custom or stock.
The problem I'm having is that I've tried to precache an existing effect - electric\fx_elec_sparks_bounce_blue and launcher won't load the map. This is the final error output through the launcher console - ^1 ^1^ ^1ERR(6E) scripts/zm/zm_montys_lab.gsc (87,0) : Compiler Internal Error : Unresolved external 'zm_weapons::load_weapon_spec_fr0m_table'
I have a very simple function to test adding in fx, for controlling via scripting. It's a snippet from a codwaw project I was working on.
function e115_update(){ while(1){ f = anglesToForward(player.angles)*50; r = anglesToRight(player.angles)*30+f; r += (0,0,60); elec_orb MoveTo(player.origin + r, .1, .0, 0); wait(0.5); } }
I've tried precaching in the right places from what I can remember, but I can't get it work. I've looked for a topic on this issue for BO3 and can't find any clear tutorials. Any help would be appreciated. This is my mapname.gsc -
//***************************************************************************** // MAIN //*****************************************************************************
function main() { zm_usermap::main(); level thread e115_init(); level._zombie_custom_add_weapons =&custom_add_weapons;
//Setup the levels Zombie Zone Volumes level.zones = []; level.zone_manager_init_func =&usermap_test_zone_init; init_zones[0] = "start_zone"; level thread zm_zonemgr::manage_zones( init_zones );
level.pathdist_type = PATHDIST_ORIGINAL; }
function usermap_test_zone_init() { zm_zonemgr::add_adjacent_zone("start_zone","zone2","enter_zone2");
I noticed something in the script: Your functions pick1() and pick2() both thread your build() function, so essentially you have 2 of the same build() functions running in parallel, and build() won't break if you only have 1 part, because the first line wait's until the variable level.allParts equals 2.
Does this explain why some custom maps are playing the power up sound twice for players when you hit the power switch?
The way you have it set up is perfect, but instead of threading build() two times in the pick1() and pick2() functions, just thread build() once before pick1() & pick2() are threaded, and it will only execute once after the variable level.allParts= 2. Then of course remove the "thread build()" line from pick1() and pick2().
Maybe i'm reading it wrong or something, but just thought I would give some potentially helpful feedback. Thanks again, this is very useful.
That means you are missing _zombiemode_weapons_sumpf.gsc, so put that gsc file in your mapname/maps folder. If you don't have that gsc then you should remove it from your mapname.gsc probably where it's called around zombiemode main. If not then you are referencing it in some other script and it can't find it because its not in your mapname/maps folder lol. I mean generally in my experience any time you get that "Could not find script" you are probaby forgetting to put the script in mapname/maps folder, or in one of your scripts you are doing #include _zombiemode_weapons_sumpf and it's missing from the maps folder etc. Just check stuff like that if you haven't already figured it out.
Well, I wish I would have known that a long time ago! I use N++ for basically everything. That will definitely make things easier with the compare plugin. Hopefully this will help purplefire as well lol. Thanks for the tip. I'll have to check that out.
I'm by no means an expert on this but I would assume it's absolutely possible. I have done this before, but you wuld obviously have to manually copy all the scripts from one to the other. But keep in mind you'll have to make sure that both gscs aren't sharing any variables, function names etc. Just back up both files, and give it a shot.
Thanks man. I'm almost done making a variation of it where it doesn't shoot projectiles, but acts as an energy barrier circling the player. To be honest, it's going to be one of four easter egg style wonder weapons, like with the bows or staffs. Each one is going to have an elemental effect, like the singularity one, a wind style one that will have a small radial effect similar to the thunder gun, one will be fire tornado's circling the player and sending out smaller tornado drones, and the last one is going to be similar to the gersch device. It's a big undertaking but pretty persistent. I'm sure I'll be bugging more on the forums for help along the way haha.
I was getting an unknown function with that, so I searched some of vanilla scripts and found anglesToForward() which I'm assuming is what you meant. However, I don't understand the syntax as shown in the ugx scripting reference:
Code Snippet
Plaintext
forward = anglesToForward(forward);
It seems redundant to me looking at it. Why is a variable being defined and then sent in the same line? I tried anyways with every permutation of the syntax I could think of, but trial and error yielded no results This is the last code I tried, which compiles fine but nothing is printing:
Code Snippet
Plaintext
test_angles_and_print(); { while(1) { pangles = players getPlayerAngles(); f = anglesToForward(pangles); u = anglesToUp(pangles); r = anglesToRight(pangles); if(isdefined(pangles)) iprintln(pangles,f,u,r); wait .5; } }
Any further help is greatly appreciated. In the meantime I'll keep trying, and I'll update if I have any luck. Double Post Merge: August 13, 2016, 04:45:43 amThe code I posted, I drafted just for an example to be short, and forgot to define "players". So to make it easier I'll loan you the full code I'm working on that I'm using it in:
This is a trap I made, named Entity 115. It has a master singularity that floats above a totem, and then it shoots energy wave projectiles (looks like ball lightning with glowing plasma) at enemies for 1 minute. Once you upgrade it, the singularity is supposed to follow the player above their shoulder within sight of the first person view. This is the only thing I can't get to work, I included all the code that I wrote for this section if it helps. Double Post Merge: August 13, 2016, 05:01:44 amSorry I keep forgetting things, on the line where it says
zombies setGoalPos(orb.origin);
Disregard//comment that out if you test it, it was just something I was fooling around with last night trying to get the zombies to path towards the singularity, which I don't think I want to use anyways. But for some reason that line (I think) was spawning a second master orb above the script model that the "original" master orb spawns at, weird... but unrelated. Double Post Merge: August 13, 2016, 05:43:31 amGrrr
I just realized how retarded my last edit was. I posted that script and forgot that I removed the getangles part of it so I could isolate it until I got the iprints working. So in that code, when the minions are spawned, they spawn on the master orb and path to the zombies. When the master brain part threads the zombies as self into the minion spawning logic, the minions are spawned at the master orb origin, so naturally if the orb is floating right wing to the player then the minions will follow suit, which is the intention. This is where I need to get the players angles so I can toss them into the while loop so that before the minion spawns each cycle, the master orb will get moved to the little devil spot so the minions get dispatched above the player. Double Post Merge: August 13, 2016, 06:03:49 amI noticed a few more errors
Here is the current working version of the script:
The test_angles_and_print() function at the end I can't get working. I don't know if it's the syntax, I can't tell which part is failing, I'm getting no errors Double Post Merge: August 13, 2016, 06:15:54 am+5 more idiot points for me. *Fixed and removed undefined variable "orb_radius" on line 46
Code Snippet
Plaintext
thread trap_trig(orb,orbTag,orb_radius,orb_trig); //<--orb_radius removed. - same as "orb" using script for radius anyways
What I'm trying to do is is a moveto on an entity, which I can do easily, but the problem I'm having is figuring out how to keep the entity in front of the player at all times. For example:
Code Snippet
Plaintext
little_shoulder_devil() { x = ("50"); // 50 units in front of players face y = ("50"); // 50 units to the right of player z = ("50"); // 50 units above players shoulder }
This is not my exact code but a mockup of what I'm trying to do. I noticed the geteye() function in the ugx script references, but to my understanding that gets the angles of the player's facing direction. This is where my problem is, I can't figure out how to adjust the moveto coordinates relative to the player's facing angle. For example, if north is +x, and south is -x, and so on for y and z, how can I convert the facing direction to a relative offset of the player. If anyone could give me some suggestions I would greatly appreciate it, as well as give you credit in a mutual project I'm working on. Hopefully I explained my intentions clearly, if not let me know and I'll elaborate.
Show Posts
