undefined
SlyJF said in [Release] [Zombies] ZOMBIES++ MOD (Extra Perk Machines, Powerups, more):
MiguelitoS2 Cahz yeah im trying to figure out why zombie blood isnt working, any updates here?
It's because powerup isn't passed onto the original _zombiemode_powerup_grab function if it the powerup wasn't one of the user added custom ones. Instead it's just discarded.
Don't know why he missed that part when he copied over my code.
More experienced people just remember the stuff from years of experience from earlier cods etc.
When getting started, just pretty much just Google search for a list of stuff. Looking at what other people have done is also good when getting started.
Loads of tutorials for gsc found with a Google search as well. Remember that you don't have to search for BO2 gsc, gsc is pretty much the same for all cods. Best documented stuff you'll probably find from earlier cods. Or maybe BO3 since it actually officially supports modding.
Also don't forget about just studying the actual gscs BO2 runs off.
It's very good to find new stuff as well.
You'll find a dump for the decompiled gscs stickied in the BO2 modding section.
For example that other question you just posted here, "how to find out zombie kills", is solved in like a minute by just searching the word "kills" in patch_zm.
Personally I use "AstroGrep" to search for text inside the whole dump.
Emosewaj said in [Support] Mono Syntax Error:
Ox_ You're implying they know what regex or Search and Replace are, lol
I guess, but it's not like you need to know.
First link on Google gives you an online tool to which you copy paste exactly what I said and all done.
Kalitos said in Contents of the GSc file "_clientids" !Question:
Ox_ I agree with you, although since you mentioned the gsc dump search, I got on it, and if you talk about ".clientid", the game does refer to it, but it directly includes "player.clientid". On the other hand, if we search for level.clientid, we only see that it refers to a single file "_clientids.gsc". It's strange.
The level.clientid part doesn't seem very interesting or relevant, it just increases and then gives the next player the next number.
But each player getting their own clientid field is that interesting part.
Searching for uses of that field (the field owner by a player, not the level) in patch_mp comes back with 70 matches (few of them in dev blocks though) across 14 different gscs.
Sass said in Contents of the GSc file "_clientids" !Question:
I know the file existed back in CoD4, and wasn't even used back then IIRC.
To clarify,
player.clientid's do indeed exist and is (somewhat) used in the game. However this file doesn't handle them at all as you can already tell.
If you replace the _clientids gsc with e.g. this
init()
{
level thread onPlayerConnect();
}
onPlayerConnect()
{
for(;;)
{
level waittill("connected", player);
player thread onPlayerSpawned();
}
}
onPlayerSpawned()
{
self endon("disconnect");
level endon("game_ended");
for(;;)
{
self waittill("spawned_player");
self iprintln(isDefined(self.clientid));
}
}
You'll see that that field indeed doesn't exist if we patch _clientids to not create it.
(As opposed to that field working just as expected if we don't patch _clientids)
Makes me wonder how come we're not breaking the functionality in those aforementioned 15 different gscs.
Or perhaps we are, but the functionality there isn't essential. I cba'd to study/test that.
RektInator said in Contents of the GSc file "_clientids" !Question:
Kalitos the _clientids script is a leftover script. The clientid on the GSC objects aren't used anywhere else in the GSC code, therefore the script can be overwritten by something else.
Seems like to me it's actually used quite a lot?
Searching .clientid in a gsc dump gives quite a few results.
Starting to wonder myself why we're able to just patch that out of the gsc.
Cahz said in [Release] MW3 Style Infection Gamemode:
Ox_ in the initial release, i going to include a random camo on spawn for each person, but I liked the no camo look. It felt like mw3 infected as close as possible lol.
As for the indentation, i copy pasted from gsc studio without double checking the output into github. I'll fix it when i get some free time later this morning.
I totally forgot that infected had tac inserts as well!
And the idea for storing infected names is a great one. I'll definitely add that as well
Ye, gsc studio is cancer as a text editor. Indenting might look correct there, but it most definitely isn't haha.
@colorz808 said in [Release] [GSC] Zombies Custom Powerup | Unlimited Ammo:
Ox_ Are you going to make more custom power ups? I would like to see a perk bottle powerup that gives a perk to all players that leads to gaining all 7 perks on any map or perhaps a pack o punch powerup to upgrade your gun for maps like bus depo or farm that don't have a pack o punch machine. I've used your Unlimited Ammo Powerup and I enjoy it alot when I host my server. Great Work
Guess I could make more. Just seriously lost motivation when I made the nice shader at the bottom of the screen for the powerup timer and all, just to notice it doesn't work for all maps.
Ideas are appreciated though, the more complex, the more interesting it is (but that could also result in cba, haha)
And I don't think I quite understand what your first idea is. Just normal perk bottle powerup, but it also increases the perk cap? Or?
And for pack-a-punch, seems like Knight made it already, here's his post. Maybe he could share it.
Good stuff.
And for some small improvement suggestions:
I'd recommend you store the infected players and then compare against it on onPlayerConnect().
That way people can't rejoin to become not infected.
Also, loadout selection could be a lot more diverse and include tactical/lethal equipment as well as camos, just because camos are cool.
And fix the indenting in the code, it's horrible haha.
Vulture Aid said in [Release] Mob of the Dead Mod: "A cat has 9 lives":
Ox_ said in [Release] Mob of the Dead Mod: "A cat has 9 lives":
homura said in [Release] Mob of the Dead Mod: "A cat has 9 lives":
Ox_ what are CSC files?
GSC is server side, CSC is client side.
Same syntax in both.Where can you access them?
You can find a dump for them somewhere I guess.
I don't really have one, at least a good one (I know there's some ancient one on CraigChrist's Se7enSins BO2 Tesseract release thread), maybe JezuzLizard has one he could share.
But anyway, I don't know how you'd go on about loading custom CSC on Plutonium and what would happen even if you managed to do it.
Maybe asking the Plutonium devs could be worth a try?
homura said in [Release] Mob of the Dead Mod: "A cat has 9 lives":
Ox_ what are CSC files?
GSC is server side, CSC is client side.
Same syntax in both.
JezuzLizard said in [Release] Mob of the Dead Mod: "A cat has 9 lives":
Ox_ I checked the corresponding .csc to _zm_afterlife.gsc and it has that line too. Wouldn't it cause exe_client_field_mismatch error if the .gsc had a different value than the .csc?
You're probably correct, didn't even think of that.
Didn't try it or anything, so dunno.
Kalitos said in Problem handling DVARS. !Help:
homura said in Problem handling DVARS. !Help:
getCurrentWeapon();
I understand, but I also understand that the function gets me the player's current weapon, but not the primary weapon. Because I can have the secondary weapon as my current weapon.
homura said in Problem handling DVARS. !Help:
That's all you can do then as far as I know. self.primaryWeapon works in IW4, I think, and I'm not sure how else you can get it in T6. I looked at the BO3 script docs and I couldn't find anything.
You can for example see if the weapon is found in level.primary_weapon_array.
maps\mp\gametypes\_weapons.gsc has a function for checking it as well:
isprimaryweapon(weaponname)
{
return isDefined(level.primary_weapon_array[weaponname]);
}
Alternatively, <player> getloadoutitem(<loadout>, "primary") could be used.
Vulture Aid said in [Release] Mob of the Dead Mod: "A cat has 9 lives":
PLEASE READ
To whom it may concern: I am deeply sorry I couldn't get the hud to display the current lives, me and Homura have tried for many days to fix this issue, but unfortunately, we couldn't. So bare with us as you'll have to rely on the status display to know how many lives you have, the cause of this error is in line 61, it would seem to be that it only displays base 4 numbers. If anyone has a fix, leave a comment on the forum post or message me directly if you know a fix. GLHF!!!!!
The player_lives clientfield is only allocated two bits, since that's all you're supposed to need.
You can only fit numbers 0 though 3 into those two bits.
To get past this, you'll need to patch maps\mp\zombies\_zm_afterlife.gsc.
This line specifically in init():
registerclientfield("toplayer", "player_lives", 9000, 4, "int"); //patched to allocate 4 bits
After taking a quick look, I'm seeing four ways you could do this.
You could patch e.g. the vending_trigger_post_think() function, which is one the functions that will run when you purchase a perk, in _zm_perks.gsc, but that would require some doing. You'd have to fix all the decompilation errors in that gsc and then recompile it. Could be pretty easy, but could also be that it's straight up missing some code and you'd have to fill it in yourself.
This approach would surely give you the most control, and you could customize anything and everything about it. If this happens to be one of those gscs that doesn't have terrible decompilation errors, this is a really good approach.
Another way, which already seems pretty good, would be changing the perks that are associated with the perk machine triggers. This way you wouldn't have to recompile the _zm_perks gsc.
This is the beginning of the vending_trigger_think() function, which is holds the logic for each perk machine's trigger.
vending_trigger_think()
{
self endon( "death" );
wait 0.01;
perk = self.script_noteworthy;
...
The function is owned by each perk machine's trigger, so self is the trigger.
So what you could do is just change the value of trigger's script_noteworthy.
Without doing any testing, I think it'd be done with just doing this:
(jugger to speedcola)
foreach (trigger in getentarray("zombie_vending", "targetname"))
if (trigger.script_noteworthy == "specialty_armorvest")
trigger.script_noteworthy = "specialty_fastreload";
Though, you'd need to get that to run before the init() in _zm_perks, which might not be that easy.
But in that case, could of course just notify the desired trigger with a "death", and then restart the desired trigger's logic function (vending_trigger_think())
However, this approach would come with the downside(?) of your hud saying speed cola when you're standing next to the jugger machine. Basically the machine acts exactly like the speed cola machine.
And then the third approach I could quickly think of:
In the vending_trigger_post_think() function, which is the function that runs after you make a perk purchase, there is a very helpful little line of code:
vending_trigger_post_think( player, perk )
{
player endon( "disconnect" );
player endon( "end_game" );
...
if ( isDefined( level.perk_bought_func ) )
{
player [[ level.perk_bought_func ]]( perk );
}
...
}
A globally defined function that runs after you buy (and finished drinking) the perk.
Now that's lucky.
Be very easy to add your own custom logic onto that function. And in your case, I guess your desired custom logic would be removing the purchased perk and replacing it with another perk.
And on top of that, you can add whatever else custom logic as well.
I'd consider this the best approach, since you won't have to deal with recompiling the _zm_perks gsc, and you can basically still have a lot of control over what actually happens upon buying the perk by just removing it and then doing whatever.
The fourth way, is basically a duplicate of the above, with the downside of not having a direct way to tell what perk the player just bought.
Players are notified with a "burp" (this occurs in the aforementioned vending_trigger_post_think() function) upon finishing drinking a perk bottle. So could listen for that notification and then do the same as above, remove the perk that was just bought and replace it whatever else. You'd just have to create your own custom logic for determining that perk was just bought.
Most definitely not a bad approach, but I don't really see any reason to do this, since the previous approach I suggested just straight up passes the name of perk to the level.perk_bought_func function.
So yeah, there most definitely are way more ways of doing this. This is just what I could see after taking a quick glance at the _zm_perks gsc.
Though, I don't think it can get any better than using the globally defined level.perk_bought_func function. At least for the usage you seem to be after.
TheHiddenHour said in GSC Dump Searcher:
Ox_ 010 Editor looks like a wonderful program but it has a hefty price tag
. However, it does offer scripting support and is worth the cash so honestly something I see myself investing into in the future for my general workflow.
AstroGrep is actually what I was envisioning for this project to evolve into, thanks for showing it to me. One of the main things I wanted was to peek into the file and line where the instances were found. I'll give it a try
Edit: I just tried AstroGrep and it's actually slower than my project doing both case sensitive and case insensitive searches. Maybe there's some configuration I need to do
.
Oh yeah, I just tried the free trial. If I'm going to start using it, I'll just get a cracked version haha.
And is AstroGrep really inefficient? Maybe you didn't have the files cached to memory when you ran it, and then had when you ran your program?
Well anyway, AstroGrep was pretty much just the first thing I found years ago when I was searching for a program to do this, it had all I needed, regex, responsive gui while searching, peek results, search & destination history, file types, and umm probably something else that I often use as well.
Didn't do research on how efficient it is or whatever. Who knows, maybe it's not efficient at all.
Ox_ said in GSC Dump Searcher:
Nice project for sure, but, and I hate to say it, I don't really see any reason why this would be used over a normal program that does this, and is quite frankly does it a lot better. I'm not even seeing regex support and looking at the source very quickly, I don't think the gui will even be responsive while searching and searching might be quite inefficient.
Maybe try to think of some features that make sense for gsc specifically, since anything that's related to just normal text searching has already been done by others, and done way better than anyone who browses this forum could do.
I can't think of too many ideas for you, but one thing that sometimes annoys me a bit, is encountering some custom gsc function they call, and then I have to search where the function is defined so I understand what's happening.
That process could be made easy.
I'm glad you took the comment this way, kinda of felt bad about writing it, but couldn't resist writing it either.
And yeah, I for sure understand the appeal of you mostly making it for your own needs, it's fun. Sometimes that's all the reason one needs 
But anyway, some tools, personally I've been using AstroGrep to do this. But there's so much, pretty much every half decent text editor will have a "search in files" feature. Even Windows search does this, though, it of course shouldn't be anyone's choice for this.
I Googled for a few secs and found many recommendations for different tools, though one stuck out. Someone said "010 Editor will search inside files in 0 sec". Well I had to check that out, and holy shit.
I don't know how, but it literally displayed results in less than a second. And that was right after I installed the tool and just went straight to "find in files". So it's not like I made it index the gsc folder first or something.
Even searching "health" in the gsc folder, which obviously is going to come up with like a million results, took less than 2 seconds. And I even keep my gsc dump on my slow hdd instead of on any of the ssds or the m.2 (though, I'd assume the files were cached to my memory by this point).
Probably going to make this my new go to tool for this, it's even a great text editor on top of having such stupidly efficient searching.
Another suggestion:
Maybe you'd want to skip trying to reinvent the wheel on an efficient search engine and use something that's already available?
Perhaps Grep, which you might know from Linux.
I'd guess it's probably better than anything either of us could ever hope to make. And probably does searching "in 0 sec", like that text editor I tried above.
