Open misyltoad opened 1 year ago
One more request: the ability to get the current capture progress of a control point. I couldn't find a netprop responsible for this, despite trying a few which appear to be the one I was looking for.
I have a request for Payload's improved func_tracktrain collisions to be independent from tf_gamerules' m_nGameType
NetProp (needs to be set to 3 specifically to have them) into its own setting or NetProp, something along the lines of m_bUsePayloadCollisions
. I see it'd fit considering that Payload Race's double cart HUD is also handled by a separate NetProp (m_bMultipleTrains
).
Any possibility of a CEconEntity::GetAttribute()
or CEconEntity::ListAttributes()
or something to compliment Add/Remove attribute? Would be very useful for checking if a player has a specific attribute, or what value it is if they do. I'm guessing you can also retrieve this info via a netprop somehow but I was messing with things like m_AttributeList.m_Attributes
but was never able to find something that worked. Even if it did work, a dedicated helper function would be a lot easier for most people to use.
I'm not fully certain if this is intended but trying to use SetModel() (with any precached models) on a player does not seem to do anything.
Tested on a dedicated server with 2 clients connected.
I'm not fully certain if this is intended but trying to use SetModel() (with any precached models) on a player does not seem to do anything.
Tested on a dedicated server with 2 clients connected.
There's SetModelWithCustomAnimations
to set the model to players.
Any possibility of a
CEconEntity::GetAttribute()
orCEconEntity::ListAttributes()
or something to compliment Add/Remove attribute? Would be very useful for checking if a player has a specific attribute, or what value it is if they do. I'm guessing you can also retrieve this info via a netprop somehow but I was messing with things likem_AttributeList.m_Attributes
but was never able to find something that worked. Even if it did work, a dedicated helper function would be a lot easier for most people to use.
Being able to set the actual underlying attribute "class" itself directly (Eg set_weapon_mode) instead of having to set it through the corresponding attribute that may not even exist (set_weapon_mode for the SMG is one such example) would also be tremendously helpful as well
Replying to https://github.com/ValveSoftware/Source-1-Games/issues/4481#issuecomment-1316364015
I can't find anything as such in the wiki ( https://developer.valvesoftware.com/wiki/List_of_TF2_Script_Functions ) and when attempting to call it on a player, it returns an error.
Replying to https://github.com/ValveSoftware/Source-1-Games/issues/4481#issuecomment-1317908670
Dunno whether LizardOfOz is stating a class function or not, but there's the SetCustomModelWithClassAnimations
input on player
entities that should hopefully do what you want.
You need to use EntFireByHandle()
for it.
It seems like I've found a bug.
__CollectEventCallbacks(this, "game_event_", "GameEventCallbacks", RegisterScriptGameEventListener)
I think the second argument (the method prefix) doesn't work because I get
AN ERROR HAS OCCURED [the index 'OnGameEvent_player_hurt' does not exist]
CALLSTACK
*FUNCTION [__RunEventCallbacks()] unnamed line [219]
*FUNCTION [__RunGameEventCallbacks()] unnamed line [226]
It seems like the prefix it wants if OnGameEvent_
regardless of the parameter I put in.
A feature request to add m_iHideHUD
flags to hide the scoreboard and the victory screen.
Custom gamemodes would like the ability to make their own implementation of that.
@Lizard-Of-Oz __RunGameEventCallbacks
always uses the OnGameEvent_
prefix.
@Joshua-Ashton Yes, but there's an argument that sets up a prefix, but it doesn't work.
@horiuchii Can you provide a test map, please?
This map should showcase the issue nicely. You must step on the red square to the right of spawn before you are able to collect the health packs.
https://cdn.discordapp.com/attachments/665797362492637195/1039780955256270872/vscript_bug.7z
This happens because the initial call to RunScript does not have a valid script scope the first time, so activator/caller, etc never get set.
I've made it so the call to InputRunScript and InputRunScriptFile re-set these values after validating the script scope in the next update
[Bug] It seems like the event callbacks registered with __CollectEventCallbacks
don't get cleared on map change. Not just within the same map, but across different maps (e.g. to vanilla map) too.
[Bug] It seems like the event callbacks registered with __CollectEventCallbacks don't get cleared on map change. Not just within the same map, but across different maps (e.g. to vanilla map) too.
Will be fixed in the next update.
Would be interesting to see new functions such as DisplaySpriteOnClient()
and DispatchParticleOnClient()
implemented, similar to EmitSoundOnClient()
, so that various effects could be shown client-side only for specific players.
Could func_ladder be fixed? This would be immensely helpful to community servers who rely on laggy plugins.
I have this issue with game_text entity that nobody has ever reported.
Imagine a map full of game_text entities, all of them share the same channel and use the same "scan out" text effect. If you make one of them displays, every other game_text will go through their own scan out process, making them pop up if you trigger them later.
Thanks for ForceEnableUpgrades
!
Current bug when set to 2 outside of MvM: unticking an upgrade before clicking "accept" doesn't appear to actually untick the upgrade - it appears unticked only in the menu, while the attribute isn't downgraded and the money still get withdrawn. Basically, it's like if you never unticked it. You can also try to untick upgrades after pressing "accept" with the same result.
One bug report and one feature request:
Apologies if my description of this bug is inadequate.
CNetPropManager
methods has strange behaviour when returning values of nested properties, either giving false positives with HasProp()
method or values that doesn't belong to the intended prop. See this output:
// ++ TF2 HasProp ++
// -----------------
// localdata
] script printl( NetProps.HasProp( Ent(1), "m_iHideHUD" ) )
true
] script printl( NetProps.HasProp( Ent(1), "localdata.m_iHideHUD" ) )
true
] script printl( NetProps.HasProp( Ent(1), "localdata.m_Local.m_iHideHUD" ) )
true
Nothing suggests anything is wrong, but when looking at the netprops for the player
entity (see here), only the last one should be correct. See what happens if I were to instead grab the props's value:
// ++ TF2 GetProp ++
// -----------------
] script printl( NetProps.GetPropInt( Ent(1), "m_iHideHUD" ) )
33580
] script printl( NetProps.GetPropInt( Ent(1), "localdata.m_iHideHUD" ) )
33580
] script printl( NetProps.GetPropInt( Ent(1), "localdata.m_Local.m_iHideHUD" ) )
2058
] condump
Alien Swarm: Reactive Drop fixed this in its open-sourced codebase, so we can see what should the methods return:
// ++ AS:RD HasProp ++
// -------------------
// localdata
] script printl( NetProps.HasProp( Ent(1), "m_iHideHUD" ) )
false
] script printl( NetProps.HasProp( Ent(1), "localdata.m_iHideHUD" ) )
false
] script printl( NetProps.HasProp( Ent(1), "localdata.m_Local.m_iHideHUD" ) )
true
// ++ AS:RD GetProp ++
// -------------------
] script printl( NetProps.GetPropInt( Ent(1), "m_iHideHUD" ) )
-1
] script printl( NetProps.GetPropInt( Ent(1), "localdata.m_iHideHUD" ) )
-1
] script printl( NetProps.GetPropInt( Ent(1), "localdata.m_Local.m_iHideHUD" ) )
0
] condump
I don't know the technical details regarding how this happens in tf2's version of CNetPropManager
and not AS:RD's, so unfortunately you'll have to compare AS:RD's vscript_server.cpp
to the one in tf2's codebase.
Could the tf_mvm_bot_sniper_target_by_dps
cvar be allowed to be edited with vscript by default? Though ideally, I'd also like the cvar unhidden and unflagged as cheats.
Feature request: the ability to set custom kill icons. Since we're likely going to see a lot of custom weapons and environmental hazards, having the ability to assign them a custom kill icon would be that final touch that elevates the good to the great.
Any chance of exposing NavMesh like in L4D2? Getting paths for custom bots would be lovely.
@orinuse Currently, unless I'm mistaken, VScript allows one to change hidden convars such as sv_airaccelerate
or sv_bounce
as well as cheat convars such as tf_bot_offense_must_push_time
without setting sv_cheats
. It can also change convars that have both flags, such as tf_fastbuild
. So I think tf_mvm_bot_sniper_target_by_dps
can be changed through VScript? I don't know if that's intended and thus whether it will stay. I only tested this on a listen server. But it would be nice to retain these abilities; considering the convars are properly reset when switching maps, it looks like it may.
I also have a feature request.
Alongside TFNavMesh
requested yesterday, it could be very useful (and powerful) to expose both the NextBot
and TFBot
interfaces for mappers to be able to create much more flexible AI-driven entities.
We appreciate your work on this. This is an amazing technical upgrade for the community.
Feature request: the ability to toggle the tracking of achievements and statistics (such as "max damage in a single life as %class%") on and off for individual players during the match on the fly, since custom gameplay will likely affect how those are earned.
@laurirasanen Yes, a lot of NavMesh/NavArea stuff will be exposed in the next update.
@ChampionCynthia Yes, there is a convar allowlist in cfg/ that also allows certain cheat convars.
@orinuse Thanks for the heads up. I ported + integrated most of the changes from ASW: RD wrt. netprops.
- SetForceLocalDraw can be used to force the local player to always be drawn, even when not in third person for use with ie. point_viewcontrol.
Will there be improvements to point_viewcontrol (to mitigate issues with player being in third person or suiciding), or addition of point_viewcontrol_multiplayer? Or maybe some other way to control everyone's camera via vscript reliably, regardless of if they're alive,dead,spectating, first/thirdperson?
@voidMike Maybe down the line, but not with the initial release.
@venturedied
Could func_ladder be fixed? This would be immensely helpful to community servers who rely on laggy plugins.
I am going to preliminarily say no, as I don't want to encourage mappers to start putting ladders into new maps. From what I can tell, the lack of ladders in TF2 seems to be a very deliberate design decision.
Ladders make sense for certain games with certain playstyles, and TF2 is not one of them in my opinion.
I hope I am not pushing my own philosophies too hard here, but ladders in TF2 would be too 'slow', they're painful to use from a controls perspective, and basically impossible to get something that wouldn't just... suck.
They also wouldn't work with any of the existing bot code without a semi-decent amount of work, as TF bots don't support Ladders in the navmesh at all.
There are so many more much more interesting things than ladders that are way more fun and work better for the type of play TF encourages that you can make even without VScript. A bounce pad, a zipline, a catapult, or anything! Be creative! :)
out of curiosity, would be possible to do stuffs with taunts? for example, making the soldier rocket taunt, acts like a real rocket with vscript, or give any of the vehicle taunts actual vehicle physics?
Beta was updated with the stuff I mentioned above.
I've been working on a script to automatize adding weapons to unintended classes, as well as adding custom weapons easily based on a function. However, I think this recent update broke these weapons... I cannot attack with these weapons anymore.
I've been going through my old builds I've released publicly that I know did work, but the ones that I did try are having the same issue. Not sure what the deal is, so I'm reporting it here to see if you know anything.
Thank you for all your hard work!
@Yakibomb Can you share the code?
https://github.com/Yakibomb/Team_Fortress_2_VScript/blob/main/GIVE_TF_WEAPON.nut Sorry, it's a bit long. Do you want me to strip it down some so it is just the parts you need to look at?
If what I have is ok, do note: 1) It attaches a think script to all tf_weapons upon player respawn, and only ones that are on a set list. Currently it only has a handful (stock Spy, Stock Heavy, Stock Engineer) so I recommend only using those classes with stock, otherwise it'll start to lag/bug out because a lot of the weapons aren't on the list yet. 2) Go stock Spy before spawning in, please! 3) Spy will automatically spawn in with the Eyelander. If you need it on any other class, the console function is: script GetListenServerHost().GiveWeapon("Eyelander", -1) It will automatically strip melee and give the Eyelander.
Ideally something small is better, yes, but I will not be looking until at least tomorrow so feel free to take your time :)
That takes a lot of pressure off me! I'll strip it down and post a new one by tomorrow morning. Thank you.
https://github.com/Yakibomb/Team_Fortress_2_VScript/blob/main/giveweapon_base.nut
I stripped it down to the essentials and some testing commands.
Type in console script CheckItems()
to see all weapon entities and item IDs equipped by your tfclass.
Pick one, then delete the entity through console using ent_fire
.
Give yourself the weapon by typing:
script GetListenServerHost().GiveWeapon(classname, itemID)
, where classname is the weapon.
@Joshua-Ashton Valve have indeed stated that they purposely did not put ladders in maps because it confuses players and it's hard to distinguish between decorational and functional ladders, I think they said this in dev commentary section of TF2.
@Joshua-Ashton i suggeested ladders being fixed at #3765. I think mappers would only use ladders in community gamemodes, for example Zombie Escape, and it is a mechanic in that gamemode because of building blocking.
https://github.com/Yakibomb/Team_Fortress_2_VScript/blob/main/giveweapon_base.nut I stripped it down to the essentials and some testing commands. Type in console
script CheckItems()
to see all weapon entities and item IDs equipped by your tfclass. Pick one, then delete the entity through console usingent_fire
. Give yourself the weapon by typing:script GetListenServerHost().GiveWeapon(classname, itemID)
, where classname is the weapon.
Ah. It seems ficool2 found the issue. It turns out it was not a bug in this build at all, but a bug fix--the netprop LocalActiveWeaponData.m_hOwner
doesn't exist, so it should've been m_hOwner
. Changing this fixes the previous issues I was having.
Thanks you two for all your hard work.
@Joshua-Ashton I see that func_monitor has also been fixed to now display your playermodel when in firstperson, would you also be able to fix this for func_reflective_glass because GMod seems to have it fixed
Feature request: Could CBaseAnimating.SetPoseParameter(string, float)
be exposed, or LookupPoseParameter(string)
for use with the already exposed (int, float)
params version?
Could changing 2D skybox at runtime be fixed? You can change the 2D skybox by doing AddOutput skyname to worldspawn entity, however, this new skybox will only be seen by people who connected after the 2D sky is changed, the people who are still in server will see the old one, CS:GO fixed this, and along with it added skybox_swapper entity, this could really be useful for halloween maps where the underground area could use a different 2D skybox than the main map, or if you want to have some kind of day/night cycle in a custom map.
This seems to crash the game some of the time. Tested on cp_badlands.
::TestNav <- function()
{
local ply = GetListenServerHost();
local navArea = NavMesh.GetNavArea(ply.GetOrigin(), 512.0);
printl("navArea " + navArea);
if (navArea)
{
navArea.DebugDrawFilled(0, 255, 0, 100, 5.0, false, 1.0);
}
}
script TestNav();
observed outputs:
navArea ([3] Area)
navArea ((null) : 0x(nil))
navArea ((null) : 0x0x3f8000)
DebugDrawFilled
resulting in AN ERROR HAS OCCURED [the index 'DebugDrawFilled' does not exist]
Nov 26 15:42:06 hal kernel: [ 9168.262928] hl2_linux[20477]: segfault at 40e0413 ip 00000000d4b50218 sp 00000000ff83a770 error 4 in vscript.so[d4afc000+9a000]
Nov 26 15:42:06 hal kernel: [ 9168.262936] Code: ff f3 0f 10 85 18 ff ff ff f3 0f 11 44 24 04 89 04 24 e8 2b 35 fc ff e9 20 f5 ff ff 8b 85 18 ff ff ff 85 c0 0f 84 36 fd ff ff <8b> 50 04 8b 00 89 54 24 08 89 44 24 04 8b 85 00 ff ff ff 89 04 24
Few feature requests:
About ladders: while the conventional TF2 is better off without ladders, maps for custom gamemodes like Zombie Fortress would love to have them.
So, I request to enable ladders (if it's not too hard to do) and expect conventional tf2 maps to not use them by choice.
The OnGameEvent_player_hurt
weaponid parameter changes when switching weapons, which is bad in 3 situations, sentry gun, projectiles, and afterburn, the issue is that the weapon id is not the weapon that hurt the player, but the current active weapon
simple vscript to test
//gethurt
function OnGameEvent_player_hurt(params)
{
//set weapon to weaponid
local weapon = params.weaponid
//print
printl(weapon)
}
__CollectEventCallbacks(this, "OnGameEvent_", "GameEventCallbacks", RegisterScriptGameEventListener)
About ladders: while the conventional TF2 is better off without ladders, maps for custom gamemodes like Zombie Fortress would love to have them.
So, I request to enable ladders (if it's not too hard to do) and expect conventional tf2 maps to not use them by choice.
Imo we should focus on things that are impossible to currently implement thru mods Ladders exist as plugin afaik https://forums.alliedmods.net/showthread.php?p=1754756 https://www.youtube.com/watch?v=X4lTC4QEGPk https://gamebanana.com/tuts/6324
Re-enabling ladders for vscript will result in massive amount of workshop maps using them cause people love to add cool new features in!
Mappers shouldn't be restricted from using ladders just because vanilla maps were designed not to use them.
Imo we should focus on things that are impossible to currently implement thru mods Ladders exist as plugin
Plugins don't work offline and are very buggy & laggy to use. Clip brushes only work when going up, not down.
@ShikiTani The flashlight from Half-Life 2: Episode Two has always existed in Team Fortress 2, but the required shader combos are disabled by default client-side (mat_supportflashlight "0"
). Although hidden while typing it, the ConVar can be adjusted through the Developer Console normally.
If you have a server with mp_flashlight
set to 1
, a client who has set mat_supportflashlight
to 1
can toggle his flashlight on and off using the impulse 100
command.
At the present time, although setting mp_flashlight
through VScript is allowed, mat_supportflashlight
isn't, meaning that a map cannot forcefully enable the shader combos. I'd say that's not surprising considering mat_*
ConVars directly affect the client's material system and may be beyond VScript's scope.
I wouldn't be surprised if it were disabled by default for performance or memory reasons. So the addition of that ConVar to the allowlist might not be that straightforward.
EDIT: This bug report might actually be moot. It only applies to vscript-generated weapons, not weapons made normally.
Hi! I think there is an issue with applying attributes to weapons. Right now I've tested a couple attributes that have broken. Note: They work if applied to the tfclass directly, just not the weapon.
Here is a script to test at least these:
CTFPlayer.ReturnGun <- function(wep_classname)
{
local YourGunFoundBySaxtonHale = null
for (local i = 0; i < 10; i++)
{
local wep = NetProps.GetPropEntityArray(this, "m_hMyWeapons", i)
if ( wep != null )
{
if ( wep.GetClassname() == wep_classname)
{
YourGunFoundBySaxtonHale = wep
break
}
}
}
return YourGunFoundBySaxtonHale
}
local weapon = hPlayer.ReturnGun("tf_weapon_minigun")
weapon.AddAttribute("maxammo primary increased", 123, -1)
weapon.AddAttribute("max health additive bonus", 123, -1)
printl(weapon)
Instructions
Additionally, creating an Eyelander through vscript, for example, breaks all stats on the weapon completely, meaning it cannot take heads nor reduce max health. (that weapon's viewmodels are also buggy on other classes outside Demo, but that's not a relevant bug)
Hello! Today we are launching a beta branch of TF2 that has support for VScript in the
vscript_test
branch.This is a big issue to collate feedback from Mappers/Server Hosts for the TF2 implementation.
Instead of filing individual issues or feature requests, please post anything related to it in here. Thanks!