NOTE: Remmy said it was okay to lump these all together as they're all for MNScript. I've spoilered them all to make browsing through them better.
The ArrestTime function would be a corollary to the IsArrested function, like the wanted reason. This would allow you to adjust a theoretical bail payment based on how long they have left in jail.
Note: This has already been addressed slightly with the moving from bf_password.exe to bf_password.mscx
If
Note: This could also be flipped around, true to stop, false to allow.
Could slow down the PC, as all events would have to run in MNScript programs first before the PC could handle anything.
This RFC tries to bring some consistency into this (even if the old ones are still around).
Phew, it's over!
I'm open to any questions or comments (hence the title "RFC").
Thanks for reading.
Summary
AddIsArrested and ArrestTime functions to the Player class.Motivation
The CGPD arrest list is public via the website, just like the wanted list (which we can get, alongside the reason). It would also allow for better RP as Mayor and another source of income for them (a kiosk outside PD to allow people to bail out their friends).The ArrestTime function would be a corollary to the IsArrested function, like the wanted reason. This would allow you to adjust a theoretical bail payment based on how long they have left in jail.
Design
New functions in the Player class:Player.IsArrested()(returns aboolof if a player is arrested).number Player.ArrestTime()(returns anumberof how long they have until they are released, or 0 if they're not arrested)
Drawbacks
Don't really see any other than it "might" be too OP. I don't see this being the case. If this is the case, make the "IsArrested" function take a few fake lag cycles longer to have some sort of cost from calling it often. People already have auto-unarrest scripts, I don't see why this shouldn't be added because of this. There is a more long form discussion on this point in the DarkRP discord with Relman, it can be found here. I wouldn't want this to be denied because it's "too OP", I'd prefer points regarding this to be brought up so they can be addressed and responded to, instead of a flat denial.Alternatives
There are none really.Summary
Add aSlice function to the Array library which returns a "slice" of a given array of any type.Motivation
There's no real way to get (more than one) part of an array without looping through it, this RFC provides a way for this.Design
New function in the Array library:Array.Slice(any[] array, number start, number end)(returnsany[]of the array values been the start and end index, null if those are out of bounds)
Drawbacks
None really.Alternatives
There are none really.Summary
Adds aNSplit function to the String library which returns a string array of the string, split by a delimiter, up to a "max split" of n (parameter).Motivation
Right now, to achieve this in MNScript, you need to use IndexOf, which is fine for when you only want to split once, but more, you need to use String.Sub from that index until you reach the end. This is in-efficient.Design
New function in the String library:Array.NSplit(string str, string delimiter, number n)(returnsstring[]containing the string split by the delimiter a maximum of n times)
Drawbacks
None really.Alternatives
Doing what I said in the motivation.(No alliteration, sorry)
Summary
Add compound operators (+=, -=, *=, /=, %=, ^=, and ..=).Motivation
Currently in MNScript, the way you have to setup a for loop is using a while loop and incrementing a count like soi = i + 1, this RFC would reduce that to this i += 1 which is semantically better.Design
Multiple new operators:+=adds the expression on the right to the variable on the left and assigns it.-=subtracts the expression on the right to the variable on the left and assigns it.*=multiplies the expression on the right by the variable on the left and assigns it./=divides the variable on the left by the expression on the right and assigns it.%=find the remainder of the variable on the left after dividing by the expression on the right and assigns it.^=raises the variable on the left to the power of the expression on the right and assigns it...=concatantes the string on the right to the variable on the left and assigns it.
Drawbacks
Users could be confused at first by this syntax. Hydro has also said that this would require serious compiler work instead of how operators work already.Alternatives
Adding a ++ or -- operator, but this is not possible as MNScript is not tokenized.Summary
Add aNull function to the Util library which just returns a null value.Motivation
Currently in MNScript, you cannot have optional parameters nor can you return null (you must use a <Type>Result class or an erroneous value). This RFC tries to alleviate that by adding a function which returns a null value which can be assigned to a variable of any type.Design
New function in the Util library:Util.Null()(returns a null value)
Drawbacks
It doesn't look good semantically, a better way would be optional parameters.Alternatives
Adding aNULL keyword to MNScript.Summary
Allow a boolean to be returned in theIncomingNTM and ConsoleCommand events to stop the actual PC handling these messages and outputting something to the console.Note: This has already been addressed slightly with the moving from bf_password.exe to bf_password.mscx
Motivation
When adding custom console commands, or handling network transfer messages in a program. The PC sometimes outputs text to the console, for example with whois responses, orCommand not found for console commands. This RFC fixes this by allowing you to return a boolean value to stop the PC from handling it (events would not be processed by the PC, the PC wouldn't run a command if stopped). This would function like Device_PaymentButtonPressed.Design
Boolean return values are added for theIncomingNTM and ConsoleCommand event.If
true is returned, then the PC will handle the event. If false is returned, the PC will not handle the event.Note: This could also be flipped around, true to stop, false to allow.
Drawbacks
Could break old programs (you could just pass it to the PC if neither was returned).Could slow down the PC, as all events would have to run in MNScript programs first before the PC could handle anything.
Alternatives
Remove a load of annoying messages if a program didn't invoke it (for NTM). No real solution for console commands unless we can register them in MNScript.Summary
Refactor how the Peripheral library approaches Turrets by adding aGetConnectedTurret function to the Peripheral library and by adding MakeFriendlySteamID, MakeHostileSteamID, IsValid, and SetText to the Turret class in the Peripheral library.Motivation
Right now, the way you interact with turrets doesn't fit into how you interact with other peripherals (like VCMiners and Teleporters). It has top level functions in the Peripheral library which should really just be in the Turret class. While I'd love to remove these out right, we can't due to backwards compatibility.This RFC tries to bring some consistency into this (even if the old ones are still around).
Design
A function added to the Peripheral library:Peripheral.GetConnectedTurret()(returns aTurretinstance, which may or may not be valid (for checking if one is connected or not)).
Turret.MakeFriendlySteamID(string steamId)(same as Peripheral.TurretMakeFriendlySteamID)Turret.MakeHostileSteamID(string steamId)(same as Peripheral.TurretMakeHostileSteamID)Turret.IsValid()(returns aboolof whether a turret class is valid or not)Turret.SetText(string text)(same as Peripheral.TurretSetText)
Drawbacks
Can't see any.Alternatives
Can't see one.Phew, it's over!
I'm open to any questions or comments (hence the title "RFC").
Thanks for reading.
Last edited:
Donator