Next Update v4 - March 2016 Update is out!

[>>oubliet]

[QUOTE=Neat-Nit;50093493]That's already covered by t[c] == nil. Think about it.[/QUOTE]

Yeah you're right - got it mixed up my bad.

[deinemudda32]

A question.
Why do we have to restart the game for mounting addon folders correctly?

[Rubat]

[QUOTE=deinemudda32;50093738]A question.
Why do we have to restart the game for mounting addon folders correctly?[/QUOTE]

They are mounted only on game load for performance reasons.

[Geferon]

[QUOTE=Robotboy655;50093760]They are mounted only on game load for performance reasons.[/QUOTE]

Can't be there any sort of console command to reload all the addons folders, beacouse it's annoying to create new files and restart the server for it to load, and if the server is slow it's a pain in the ass.

[Bo98]

Since no one has opposed this, I'll send a pull request for it:

[QUOTE=Bo98;50092986][LUA]function table.IsSequential(t)
local c = 0
for k, v in pairs(t) do
c = c + 1
if t[c] == nil then return false end
end
return true
end[/LUA][/QUOTE]

There is one more thing though: do we ignore non-numeric keys? As per the Lua manual it seems to be the right thing to do:

[QUOTE=http://www.lua.org/manual/5.3/manual.html#3.4.7]
Note, however, that non-numeric keys do not interfere with whether a table is a sequence.
[/QUOTE]

However some people here opposed it so how about a vote:

Agree for ignoring non-numeric keys (i.e. continue if one is found), disagree to take them into account (i.e. return false if one is found).

[NeatNit]

[QUOTE=Bo98;50094860]Since no one has opposed this, I'll send a pull request for it:

There is one more thing though: do we ignore non-numeric keys? As per the Lua manual it seems to be the right thing to do:

However some people here opposed it so how about a vote:

Agree for ignoring non-numeric keys (i.e. continue if one is found), disagree to take them into account (i.e. return false if one is found).[/QUOTE]
Damn you. I clicked agree to "I'll send a pull request for it" before I read the rest of the post. I had to refresh the page because of you!

The current implementation returns false on non-numeric keys, equivalent to Disagree. The only problem with it is that it's unreliable. So the question is actually: do we change the meaning of the function? agree/disagree

Yes, it's wrong, but for most purposes it's probably what's needed.

Maybe we can add a boolean second argument to pick between them? That way the old behavior can be preserved while the correct can be enabled by using table.IsSequential(mytable, true)

[Ott]

Shouldn't we know if a table is sequential already? Why do we need to check? I regularly put non-sequential keys in sequential tables.

[Bo98]

[QUOTE=Ott;50097371]Shouldn't we know if a table is sequential already? Why do we need to check? I regularly put non-sequential keys in sequential tables.[/QUOTE]

I agree - I don't even use the function myself. But the function already exists and we can't remove it now so we might as well make it work.

[FPtje]

I've done it

[url]http://forum.darkrp.com/threads/darkrp-2-7-0.7547/[/url]

[NeatNit]

[QUOTE=FPtje;50100219]I've done it

[url]http://forum.darkrp.com/threads/darkrp-2-7-0.7547/[/url][/QUOTE]
:wideeye:

:worried:

Godspeed.

Edit: this doesn't affect me in [i]any[/i] way and yet I'm super nervous about this.

[aStonedPenguin]

[QUOTE=FPtje;50100219]I've done it

[url]http://forum.darkrp.com/threads/darkrp-2-7-0.7547/[/url][/QUOTE]

May 1st is going to be entertaining.

[UselessGhost]

"omg i can't believe falco broke darkrp again 2.7 SUCKS"

Just a reminder that there are people still clinging to the ancient 2.4 codebase to this day.

[FPtje]

[QUOTE=Joeyl10;50100464]"omg i can't believe falco broke darkrp again 2.7 SUCKS"

Just a reminder that there are people still clinging to the ancient 2.4 codebase to this day.[/QUOTE]

Though increasingly rare.

[DaCool]

[QUOTE=Joeyl10;50100464]there are people still clinging to the ancient 2.4 codebase to this day.[/QUOTE]

Those are like Win XP users, who gives a shit, if they wanna stay with bugs and exploits and missing functions and features, let them have it.

[Bobblehead]

[QUOTE=FPtje;50100219]I've done it

[url]http://forum.darkrp.com/threads/darkrp-2-7-0.7547/[/url][/QUOTE]

You might want to upgrade the machine that's hosting your forums. The influx of stupidity on May 1st could crash even the most robust of servers.

[MattJeanes]

What's the best way to store SteamID64? I've been using strings as I've had issues with losing precision before.

[zerf]

Honestly I'd consider just storing "AccountID"s for players. They're simple 32 bit numbers, and you can fully reconstruct a steamid64 from them. The drawback is that it isn't a full "SteamID"; you lose 3/4 components of the SteamID, but they are enough to uniquely identify a player on a server.
Consider the makeup of a SteamID64 (arguably the easiest SteamID format to understand) here:

((Universe << 56) | (Account Type << 52) | (Instance << 32) | Account ID)

Universe is an integer between 0-4 inclusive, and its possible values are: Invalid, Public, Beta, Internal, and Dev. Every player joining your server will be in universe 1, Public.
Account Type is an integer between 0-10 inclusive and contains [URL="https://developer.valvesoftware.com/wiki/SteamID#Types_of_Steam_Accounts"]all sorts of wacky values[/URL]. Everyone on your server will be type 1, individual.
Instance is largely undocumented but should always be 0.
Account ID is the last field, and the only one that will change between players on your server. This is the aptly named identifier of your steam account, an incremented value determining what user number you are of Steam.

If 3/4 of the fields are constant for players, why bother storing the extra data?

Here's how you find an account ID from a SteamID64:

AccountID = SteamID64 - 76561197960265728

and the reverse:

SteamID64 = 76561197960265728 + AccountID

My SteamID64 is 76561198052589582, my AccountID is 92323854.

In conclusion: if you are confident that only players and not groups or "P2P SuperSeeders" will be joining your server, you can safely store AccountID without losing any data.

It's small enough to fit in a 32 bit integer, unique to every steam user, and fully convertible to and from steamid64 with one operation.

AccountID, store yours today!

[aStonedPenguin]

[QUOTE=MattJeanes;50103502]What's the best way to store SteamID64? I've been using strings as I've had issues with losing precision before.[/QUOTE]

I've always used a bigint

[FPtje]

[QUOTE=zerf;50103873]
In conclusion: if you are confident that only players and not groups or "P2P SuperSeeders" will be joining your server, you can safely store AccountID without losing any data.[/QUOTE]

[url=http://wiki.garrysmod.com/page/Player/SteamID64]shit will go wrong with bots, which is very annoying. [/url] you'd have to make an edge case. Besides, your representation isn't standard and not API friendly. Addons that use that representation would have to provide conversion functions. That gets annoying really quickly, especially when addon authors decide to use a slightly different representation and you have to convert between different non-standard representations.

SteamID64 is fine for me.

[Bobblehead]

Furthermore, if your forum or website has an api for steamid32 or 64 then you don't have to create the api for accountid, even if it would be simple.

[NeatNit]

Sounds to me that, in cases where you MUST use a number and not a string especially in Lua, there is benefit to getting the account ID. Unfortunately zerf's method can't work in Lua because the string will have been converted to double and lost some of the account ID before subtracting. I think it should be taken from the old school SteamID, e.g. this untested code:
[lua]local sid = string.Split(steamid, ":")
return sid[3] * 2 + sid[2][/lua]

[#NaN]

I don't get it, why you wouldn't want to store the 64-bit SteamID. It's just 4 more bytes to save per row (compared to an int column). Let's say you have 1000 unique entries in your table. That are 4000 bytes more to store. ~3.9 kilobytes. Holy shit.

And you wouldn't have to deal with these edge cases like described by FPtje.

The only downside I can see with using the 64-bit SteamID, is that you would have to work with a string in Lua (besides that, doesn't LuaJit already support 64-bit integers?).

[man with hat]

I know this has been talked about previously, but whatever happened to the idea of having a hook for lua errors? The functionality for detecting errors (and also clientside errors) is already in the game.

[MysteryPancake]

[QUOTE=man with hat;50104822]I know this has been talked about previously, but whatever happened to the idea of having a hook for lua errors? The functionality for detecting errors (and also clientside errors) is already in the game.[/QUOTE]

[img]http://wiki.garrysmod.com/favicon.ico[/img] [url=http://wiki.garrysmod.com/page/GM/OnLuaError]GM:OnLuaError[/url]?

[editline]10th April 2016[/editline]

Oh, I guess you mean in the clientside realm rather than the menu realm

[man with hat]

[QUOTE=MPan1;50104837][img]http://wiki.garrysmod.com/favicon.ico[/img] [url=http://wiki.garrysmod.com/page/GM/OnLuaError]GM:OnLuaError[/url]?[/QUOTE]

That only works in the menu state.

[Bo98]

[QUOTE=pennerlord;50104784](besides that, doesn't LuaJit already support 64-bit integers?)[/QUOTE]

Lua 5.3 does. LuaJIT (outside FFI) still uses doubles AFAIK so it's 56-bit for integer-like values though I haven't tested it out in GMod.

[Geferon]

[QUOTE=geferon;50094140]Can't be there any sort of console command to reload all the addons folders, beacouse it's annoying to create new files and restart the server for it to load, and if the server is slow it's a pain in the ass.[/QUOTE]

Will this ever come true?

[Dynn]

Anyone else having crashes caused by the weld tool (according to Willox)?
I have like a daily crash with more or less the same crash log.
Here's a collection of crash logs + logs of welding if anyone would be so kind to take a look:
[quote]
Script for logging in constraint.lua: [url]http://pastebin.com/LgazZEUA[/url]
The logging function itself: [url]http://pastebin.com/cQdyDHw9[/url]
Crash log 1: [url]http://pastebin.com/eZqz2jWQ[/url]
Crash log 2: [url]http://pastebin.com/eiCeyWxm[/url]
Crash log 3: [url]http://pastebin.com/zMfA9sKb[/url]
Crash log 4: [url]http://pastebin.com/1biq3RZi[/url]
[/quote]

[YourStalker]

[QUOTE=ms333;50105890]Anyone else having crashes caused by the weld tool (according to Willox)?
I have like a daily crash with more or less the same crash log.
Here's a collection of crash logs + logs of welding if anyone would be so kind to take a look:[/QUOTE]

How long has this been going on? The smart weld tool does hundreds of welds a second, a bunch of times, and I've never encountered a game crash because of the welding.

[Dynn]

[QUOTE=YourStalker;50105987]How long has this been going on? The smart weld tool does hundreds of welds a second, a bunch of times, and I've never encountered a game crash because of the welding.[/QUOTE]

The only weld-related tool in here is the weld tool itself. Welding has been removed from precision and stacker - I dont have the smart weld tool. Precision and weld is the only allowed constraint-tools. I've prevented the phys_lengthconstraint entity from being spawned from the duplicator and loggings have later proved that it isn't caused by some weld duping.
This has been an issue for a few months - but I haven't really made use of the constraint-library in anything I've made unless EnableMotion counts:
[lua]
Movement.EnableMotion = false -- false will not allow props to move without being held by a physgun

function Movement.OnSpawnedEntity(ent)
ent.CanDisableMotion = true

if Movement.EnableMotion then
return
end

local PhysObj = ent:GetPhysicsObject()

if IsValid(PhysObj) then
PhysObj:EnableMotion(false)
end
end

CABR_NoMovementOSE = Movement.OnSpawnedEntity
GT.NoMovement.OSE = Movement.OnSpawnedEntity

hook.Add('PlayerSpawnedProp', 'CABR.Movement.Prop', function(_, _, ent)
Movement.OnSpawnedEntity(ent)
ent.ULXRemoval = true
end)

hook.Add('PlayerSpawnedSENT', 'CABR.Movement.SENT', function(_, ent)
Movement.OnSpawnedEntity(ent)
end)

hook.Add('CanPlayerUnfreeze', 'CABR.Movement.NoRUnfreeze', function(ply)
DarkRP.notify(ply, 1, 4, GT.Language.GetPhrase('nomovement_notify'))
return false
end)

hook.Add('PhysgunDrop', 'CABR.Movement.PhysDrop', function(ply, ent)
if not Movement.EnableMotion and ent.CanDisableMotion and IsValid(ent:GetPhysicsObject()) then
ent:GetPhysicsObject():EnableMotion(false)
end
end)
[/lua]