I'm trying to draw text over a series of entities. For most of them it's easy since they have unique classnames. But one of the entities I want to draw text over is a func_button. It has a specific name in hammer, however when trying to grab the name clientside, I'm hit with "attempt to call method 'GetName' (a nil value)"
Why? Why would GetName be exclusive to server, while GetClass would be shared? Makes no sense to me. I could draw the text over a specific vector, or just use the entity's ID, but this is a gamemode, and I want to be able to use different maps. Now I either have to specify for each map in a roundabout way, or go through the server with net messages or something.
I mean, it's not a massive issue, but I'm just curious why GetName would be held from the client.
Its very, very simple.
The client HAS to know the classname of the entity in order to "load the proper clientside code for the entity on client". For this reason, the classname of the entity is networked to the clients.
The GetName(), also known as the "target name", however, is another story. The target names are only ever used for map entity logic, And that is done on the server. Since the target name is not needed on the client for any reason at all, it is not networked to clients by the engine. You can do that yourself with any built in methods to do so, such as NWVars or DTVars.
Why is [img]http://wiki.garrysmod.com/favicon.ico[/img] [url=http://wiki.garrysmod.com/page/ents/FindByName]ents.FindByName[/url] shared then? It doesn't do anything on client so why bother making it a shared function?
I didn't make it, don't ask me. There are plenty of functions that do nothing on client, I don't know why Garry made it so, but moving them to correct real can potentially break addons, in case someone actually used them.
Yeah, because 90% of all lua developers of gmod are active and will work to update the addons for an unnecesary change
[QUOTE=gonzalolog;52337770]Yeah, because 90% of all lua developers of gmod are active and will work to update the addons for an unnecesary change[/QUOTE]
Yes, and that responsibility somehow falls on the GMod devs to maintain years of unmaintained addons at the expense of active Lua devs, because that's how that works with literally any other software in the world...
That line of logic is like a hoarder justifying why they can't throw their trash away, because they still "need" it.
I can't imagine any update to a broken function having much of an effect since nobody would be using it in the first place. Also, didn't [URL="https://wiki.garrysmod.com/page/Updating_Scripts_From_GMod_12_to_GMod_13"]this update[/URL] screw up stuff anyway?
[QUOTE=MPan1;52343818]I can't imagine any update to a broken function having much of an effect since nobody would be using it in the first place. Also, didn't [URL="https://wiki.garrysmod.com/page/Updating_Scripts_From_GMod_12_to_GMod_13"]this update[/URL] screw up stuff anyway?[/QUOTE]
You're comparing minor API changes to complete game rewritesand the changes that come with that. An addon could have easily used it shared with a loop right after where the loop ends immediately clientside but works serverside.
IMO, it's not wrong to put "don't break old addons" at a high priority. From a Roblox [url=https://blog.roblox.com/2012/08/bye-bye-bytecode/]blog post[/url]:
[quote]ROBLOX tries very very hard not to break any of the tens of millions of user scripts that exist in our ecosystem whenever we put out a new release, because we respect the time and effort that coders have spent making those scripts.[/quote]
I know that gmod isn't Roblox, but I like this line of reasoning nontheless. If it were possible to play old versions of gmod and thus having old addons at least [i]somewhat[/i] preserved, it'd be a different matter. But forcing potentially thousands of different addon devs to update their scripts without a VERY good reason is a dumb thing to do.
[QUOTE=NeatNit;52345884]IMO, it's not wrong to put "don't break old addons" at a high priority. From a Roblox [url=https://blog.roblox.com/2012/08/bye-bye-bytecode/]blog post[/url]:
I know that gmod isn't Roblox, but I like this line of reasoning nontheless. If it were possible to play old versions of gmod and thus having old addons at least [i]somewhat[/i] preserved, it'd be a different matter. But forcing potentially thousands of different addon devs to update their scripts without a VERY good reason is a dumb thing to do.[/QUOTE]
We're not talking about breaking shit every update, we're talking about cleaning up an absolutely cluttered and incoherent API that hasn't seen a proper facelift in 5+ years. GMod is an extraordinarily unique software just in the time it has been alive and updated alone, especially for a game.
A lot of the functions that are client side also but don't do anything could be in shared files in an addon, and when those functions work again the addon may not know what to do with it, or if its completely pointless to be on client side and they just remove it then you would be getting errors.
Is there a plan for another big backwards-incompatible update? Because gmod damn well should make all these kinds of changes in one update. IIRC Rubat kept saying this was the plan but I guess there just isn't a deadline of any sort for it.
Imagine being able to update and fix addons in workshop as curator or something like that, i would point for help, but that would be a mess
Sorry, you need to Log In to post a reply to this thread.
