login
April 28, 2024, 02:20:47 pm

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Topics - stormeus

Pages: 1 ... 5 6 [7] 8 9
91
Script Showroom / [Module] Improved Hashing
« on: July 23, 2013, 01:38:20 am »
This is a release I had on the LU forum that I just never got around to posting here.



Stormeus' Improved Hashing ( lu_hashing2 )

This module is an improvement and a variant of Liberty Unleashed's lu_hashing module, which ships with the server. This version offers a wider variety of hashing functions which are more secure, while still offering backward-compatibility by allowing the use of the SHA1 and (insecure!!) MD5 algorithms.

Functions
Acceptable for password hashing and storage
  • SHA224( szString )
  • SHA256( szString )
  • SHA384( szString )
  • SHA512( szString )
  • RIPEMD128( szString )
  • RIPEMD160( szString )
  • RIPEMD256( szString )
  • RIPEMD320( szString )
  • WHIRLPOOL( szString )
NOT acceptable for password hashing and storage.
  • SHA1( szString )

    Algorithmically weak and contains weaknesses that make it relatively easy to crack. This function is only provided for backwards-compatibility. If you are creating a new script, DO NOT USE THIS.

  • MD5( szString )

    MD5 has flaws in its algorithm that allows it to be broken relatively easily. This function is only provided for backwards-compatibility. If you are creating a new script, DO NOT USE THIS.

  • base64_encode( szString )
    base64_decode( szString )


    base64 is easily encoded and decoded. Storing passwords with base64 is not recommended ever because it is extremely easy to reverse.

Installation
Extract lu_hashing2.dll/so to your Modules folder. Place this line of code somewhere in onScriptLoad:
     LoadModule( "lu_hashing2" );

Download
Windows binary [.dll]
Linux binary [.so]
Source code

Test script [.nut]

Screenshot

92
Information and FAQs / Vice War III: Game Rules
« on: July 15, 2013, 06:44:43 am »
No hacking and no advantageous modifications

This should go without explanation. Any hacks, trainers, or modifications to your game that give you an unfair advantage over other players is banned, including, but not limited to:
  • Health and armour freezing or regeneration
  • Teleporting, jetpacking, or turbo hacks
  • Instant reloading
  • Hacking weapons or ammunition
  • Modifications that remove tear gas particles
  • Map modifications
  • Aimbots
  • Vehicle health hacks
  • "Car controller" (cc 1)

No death evading

You may not quit, kill, or intentionally crash VC:MP as you are dying or near death. You may, however, quit after the death message appears in the chatbox (Player1 killed Player2).

Ban evading is strictly forbidden

Joining the server after being banned, or joining the server before a tempban on you has expired will result in you being permanently banned from the event on sight.

No breaching accounts

In conjunction with the above rule, each applying player is granted exactly one account. Any attempt to coerce administrators into resetting a password that is not yours, exploiting the server to join an account that is not yours, or otherwise joining under any nickname under the one you were given will result in a permanent ban.

No spamming

Flooding the chatbox with repeated messages or random garbage, like so:

Player1: SPAM
Player1: SPAM
Player1: SPAM
Player1: SPAM
Player1: SPAM
      Player1: wefewofewfwae
Player1: fwaefaewfawewd
Player1: ewdcsadcsd
Player1: sdcsaxcdmsa
Player1: sdfcas

Is frowned upon and may result in you being muted or kicked.

Glitching is restricted as follows:

Wallglitching allowed only in areas accessible on foot
You may NOT use vehicles such as cars or helicopters to access areas to wallglitch.

Sliding is not allowed
Frequent sliding will result in a tempban or ban from the event, depending on the punishing administrator.

Rocket glitching is banned
Unconditional; you may not rocket glitch at all, especially in any way that prevents you from taking knockback or damage from rockets.

Heli-killing is allowed EXCEPT from under the map
You may heli-kill players from above ground except when heli-killing teammates, which will result in an automatic kill.

Ghost city is banned
If you know what it is, don't use it. If you don't know what it is, it won't be explained to you by staff members, as only those who know what it is would be capable of exploiting it.

No abusing administrative powers

Any attempts from moderators or administrators to use the commands they were entrusted with to give their team or themselves an unfair advantage over opponents or for any purpose other than enforcing these rules will result in demotion and/or a ban from the event.

93
Suggestions / [Implemented] Map markers for bases
« on: July 15, 2013, 05:58:27 am »
For Vice War, map markers will be displayed to show each base. However, the way each base will be shown has yet to be determined. There are two options currently being considered, which are listed below. Please vote on whichever one you feel would work best.

Option A
Each base is labeled with a different letter. Base #1 will be A, #2 will be B, etc.

Option B
Each base starts off with a white icon to show that they are neutral. As bases are captured by either team, the marker is changed to a blue or red icon.

None of the above
Make a post elaborating your own idea for base markers.

94
General Discussions / MOVED: Expulsion for [VU]Habla
« on: July 15, 2013, 05:06:42 am »

95
Diplomacy / VU - Team Red
« on: July 13, 2013, 07:13:07 am »
VU will be joining Team Red because it's the closest thing to orange.

96
VC:MP General / Frame Limiter: Is Many Evil or No?
« on: July 09, 2013, 02:31:38 am »
As I'm certain anyone reading this thread is aware of, there's a long-standing theory in the VC:MP community that disabling your frame limiter or adjusting your FPS to a higher value causes players to warp for whatever reason. Disabling frame limiter or using FPS hacks to circumvent the limit is oft considered a move comparable to cheating and has been considered ban-worthy if you were caught doing it.

On the topic of frame limiters, this happen earlier today in #VU:
Code: [Select]
<aXXo> Marcell adjust his FPS to a higher value every time he dies hhhhhhhhh
<[EAF]Alarba> deso was hacking
<[EAF]Alarba> 60fps
<Stormeus> What effect does having frame limiter disabled have on gameplay, though?
<Stormeus> oh no
<Stormeus> a high fps
<Stormeus> whatever shall we do with smooth gameplay
<Stormeus> I honestly want to see a video side-by-side comparison
<Stormeus> Of someone in VC:MP at 30fps
<Stormeus> And at 60fps

Though Deso wasn't adjusting his FPS, I was honestly curious as to whether or not VC:MP's sync caused disabling the frame limiter to cause any sort of distortion or irregularities in combat, so Shadows (heekzs) and I set off to record gameplay to compare different frame rates, the most important being the baseline of 30fps, a laggier 10fps, and a heightened 60fps.

From what I can tell from the videos I recorded, a player running VC:MP at 30fps would see no irregularities between someone playing at 30fps and another playing at 60fps. There was no observable warp that had not been caused by latency, and shooting seemed consistent.

These observations, on top of Charley's analysis on running speed at different frame rates (which also found no measurable difference between 30fps and 60fps) leads me to believe that disabling your frame limiter has absolutely no substantial weight or advantage in gameplay, for several reasons:

Running speed
As mentioned above, players who play at 60fps move at the same speed that players at 30fps move at. Just because there are more frames being drawn in a 1-second interval does not mean that the game itself is running faster. It simply makes your view look much smoother while moving.

Combat and "warp"
Combat animations are not interrupted and there is no warping or stuttering to players with latencies that differ by even a couple hundred milliseconds, even if one player has their frame limiter on and the other person has their frame limiter off, as shown in the video below.

It's my belief that any warp that actually is caused by disabling frame limiter is due to VC:MP sending more information in a one-second period about where the player is and what they're doing, since R2 does not interpolate player movements, animations, and positions in an accurate manner, and simply warps them into place. Since the player is updating their position more frequently, this should actually make it easier to shoot them since the need for lead aim can be reduced by the player's frequent position updates.

Warp may also be caused by players attempting to perform various glitches while running with an increase frame rate, which either makes their glitches less effective as they are updating too frequently to give off the intended effect (see above) or does nothing other than giving the appearance of warping in place.

Network traffic and packet parsing
Because they are running at a higher frame rate, they also parse more incoming packets more frequently, meaning that as long as you're running at an acceptable frame rate with decent latency, combat becomes simpler as lead aim and glitching become less feasible.

Is this concrete? No, and on top of the fact that I'm taking an issue as trivial as whether or not disabling frame limiter affects how you shoot people in a video game seriously enough to write a paper on it is ridiculous in itself, but the idea here it should be something that is looked into more closely before banning people for "frame limiter hacks." (Which, honestly, sounds absolutely absurd in any context whatsoever.)


97
Script Showroom / Dispelling the "TIMERS ARE BAD" myth
« on: July 05, 2013, 08:25:34 pm »
Over the past few weeks, I have had a large number of people asking me for help with scripts and one question that came up in particular was timers. For that, I'm making this thread for the sole purpose of linking people here when they ask if using timers is bad.



  • "How often should I be running timers?"
  • "Are timers bad?"
  • "I need to run this code but I don't want to use timers because I heard they are bad to use."

Timers are not bad unless they are used badly.
(And to know that, there are several things that you should know about scripted timers.)



What are timers?
Timers are functions in a script that are run at predetermined intervals for a certain number of repetitions (or ad infinitum). Timers can be used within scripts to perform actions at a later time, when they cannot be controlled by other events in the scripts.

For example, you may need to use a timer for a heal command if you want players to wait three seconds to heal. There are no events like onPlayerThreeSecondsHavePassed that you can use to perform such a task, so you would need to use a timer to control when players can heal.

However, you should not use timers for performing actions such as saving statistics in a database or file when that can be done in events such as onPlayerDeath, onPlayerKill, or onPlayerTeamKill.

But please do not ever do anything like that in onPlayerMove. EVER.

How do timers work?
The VC:MP server (both Pawn and Squirrel) rely on an internal loop when they run to process packets and other information, which is relayed to connected clients. In order to prevent draining the CPU, the servers wait 16ms after processing all the packets in its queue, before processing any queued packets again, repeating this process continuously until the server closes.

Timers are simply an extension of existing script functions that takes advantage of that 16ms period of sleep. An internal list of timers created by the scripts is maintained, and every time the server processes information, it also adds the amount of time it waited (16ms) to a counter maintained for each individual timer. Once that counter reaches the time interval (e.g. NewTimer( "function", 1000, 1 ) -- 1000 is the interval), the function is called, and the timer is either called infinitely or until the timer has run as many times as it asked to.

How many timers should I be using?
You can use as many timers as you want as long as you're not performing a ridiculous amount of instructions in them. For example, you can have a timer for a countdown running every 1000ms, and another timer for random messages every 15 seconds. Combining them and doing something like this:

Code: [Select]
RandomMessageTime <- 0;
Countdowns <- 0;
function Countdown()
{
    Countdowns = 3;
}

function MyTimer()
{
    if( ++randomMessageTime == 15 )
    {
        Message( "This timer sucks balls." );
        randomMessageTime = 0;
    }

    if( Countdowns > 0 )
    {
        Message( Countdowns-- );
    }
}

NewTimer( "MyTimer", 1000, 0 );

Does nothing but make your code messier and emulate the very behavior that the server already does to make your life more convenient.

I combined a few of my timers, so I have one timer running every second to save stats, keep track of a last man standing script, and print messages. Is this okay?
NO. Now you have so much action going on in one timer that is running so frequently (every second), performance will be even worse than if you had split up these timers.

But my friends recommended that trick to me!
Your friends are complete dumbasses.

What should I avoid in timers then?
Try to avoid saving to databases in timers that are running for very frequent amounts of time (less than 60 seconds). Also avoid writing to files, including INIs or saving hash tables, for the same reason.

Don't use timers to spawn other timers, especially when using intervals that are too low. This could cause an avalanche of timers that could lag your server to the point of being unusable, if it does not crash.

So why do people say timers are bad?
Originally, to keep noobs from using timers to do all of the bad things I told you about above. Now, because people actually believe that timers are bad.

I don't understand this thread.
You should not be using timers at all, then.



This rant has been paid for by the "Stop Scripting Stupidly" Foundation.

98
VC:MP General / VC:MP 0.4 Public Beta #1 - LIVE NOW
« on: July 04, 2013, 01:00:11 pm »



There is a public beta test of VC:MP 0.4 going on now!
Please read the entire thread before joining.



Testing Information
The test has already begun and will continue until the beta testing team believes that enough information for bugfixes has been collected. Beta testers and developers may ask you to do certain actions in order to find bugs or other issues in the server, and in those cases, you should do as they say. Otherwise, you should play as your normally would on any other server.

The gamemode is an Attack/Defense and Capture The Flag hybrid. Two teams of players each have their own bases and points, and the objective is for a team to capture the opponent's base by standing on their point for a combined 15 seconds. You can get more information by joining the server.





99
Music / If y'all don't know
« on: July 04, 2013, 09:23:47 am »
This guy goes by the name of Lupe Fiasco.






100
Accepted Applications / Application - Stormeus
« on: July 03, 2013, 11:21:42 pm »
Which game are you applying for, VC:MP, SA:MP, LU or all?: All

Nick: Stormeus

Previous Nicks: [VU]Stormeus, [IT]Stormeus

Timezone/Country: America/New York (UTC -4)

Age: 16

Do you speak English? Yes

Time you have played vcmp/samp: >2 years

Previous clans: VU due to inactivity (I'M BACK BAABYYYY), IT due to its disbanding several years ago

Do you use mIRC: da

Why you want to join VU: The same reason I joined in the first place -- I know a lot of VUs and find you lot to be a pretty cool and exciting bunch, even if some of you do get on my nerves at rare times. :P

Favourite weapon: The M60 just because I can't aim with my crappy touchpad

Which VUs do you know: Veteran, Castagna, Charley, aXXo, Thijn, Skirmant (acquainted), ferrari32, Pallazo, Ryne, Eddy, m[D]z, Habla, Las3r, MadKiLLeR, WiLsOn, Shadow, Lazee, tato (acquainted), GrinDBanG, Yuri (acquainted)

Would you be interested in competing in clan wars?: si NO I HAVE TOO MUCH SUCK


101
VC:MP General / RAY DID NOT HACK THE VC:MP FORUM
« on: August 04, 2012, 09:16:10 am »
More to come after this.
seriously just trust me on this one

102
Farewell Board / Resigning from the clan
« on: July 26, 2012, 08:17:33 am »
Instead of the usual rant, I'm just going to say that I, personally, feel incapable of wearing the [VU] tag anymore. My participation in clan affairs has reduced to nothing, on top of the fact that I still suck at combat. ::)

Because of that, and my reduced activity across VC:MP altogether, I'm leaving VU a (slightly) more skilled individual, rather than bearing a tag that, in my case, bears little to no meaning. I simply do not have the time or energy to keep up anymore.

Stay frosty,
Stormeus

103
Script Showroom / Hooking events in script releases
« on: July 17, 2012, 06:31:37 am »
Just sharing a method I thought would be helpful to those who hadn't known about it before:

Squirrel compiles all scripts into optimized bytecode that can either be stored in-memory or flushed to disk and then read in memory later. When the compiler parses a script, it processes and (in dofile's case) runs everything inside a makeshift function called main().

While most people don't think about it, you can basically do this in any file you want:
Code: [Select]
function onServerStart()
{
    print( "Server started" );
}

// This would actually work
print( "myfile.nut parsed" );

In addition to that, functions are declared as variables, unlike Pawn. In fact, the Squirrel manual even makes mention of the ability to create "local functions," which I won't go into detail on since that's beside the point here. Essentially, creating a function such as function onServerStart() is syntactically the same as doing this:
Code: [Select]
onServerStart <- function()
{
    print( "Server started" );
}

Because of that, you can overwrite a function like so:
Code: [Select]
function onServerStart() { print( "You shouldn't be able to see this." ); }

onServerStart = function()
{
    print( "im in ur base, stealin ur funcshunz" );
}

// Or
function onOverwrittenServerStart()
{
    print( "1 2 3 4" );
}

// Comment this line out to test the first example
onServerStart = onOverwrittenServerStart;

Writing over a function doesn't necessarily remove it from memory, however. As long as a reference is kept to the original function, the original function can still be called. You can keep a reference by simply storing it in a global variable.
Code: [Select]
function onServerStart() { print( "aaaa" ); }

oldServerStart <- onServerStart;
onServerStart = function() { print( "bbbb" ); }

You can then call the old function since it still has a valid reference.
Code: [Select]
function onServerStart() { print( "aaaa" ); }

oldServerStart <- onServerStart;
onServerStart = function() { oldServerStart(); print( "bbbb" ); }

You can now use the above method to hook a script's events without having to manually edit scripts, functions, and commands. You can instead do something like this to add to someone's onPlayerCommand function without really having to worry about manual editing:
Code: [Select]
function onPlayerCommand( player, command, arguments )
{
    print( "hook-free" );
}

// In another file, probably
oldOnPlayerCommand <- null;

// Hook function
function myFunction( player, command, arguments )
{
    // Call old onPlayerCommand if needed
    if( oldOnPlayerCommand )
        oldOnPlayerCommand( player, command, arguments );

    // I dunno
    print( "nah" );
}

// Check if onPlayerCommand is defined
if( "onPlayerCommand" in getroottable() )
{
    // Store the old function
    oldOnPlayerCommand = onPlayerCommand;

    // Hook it
    onPlayerCommand = myFunction;
}
else
{
    // Define it
    onPlayerCommand <- myFunction;
}

104
Script Showroom / SqHTTP: Socket-Based HTTP Server
« on: May 17, 2012, 02:07:48 am »
Became extremely bored, wrote an HTTP server using Squirrel sockets over the course of two days. The server supports:
  • HTTP requests
  • Error handling (sending 500 Internal Server Errors on a script parsing exception)
  • Query strings (in format of http://server/page/?param1=value1&param2=value2)
  • All functions provided by VC:MP Squirrel
  • Modules loaded by your scripts
  • Writing dynamic pages and static pages from existing files

The purpose of the server is to provide a limited form of providing web services to scripters directly from their game servers, such as a stats panel and remote administration, and is not suitable for forums, transmitting files, and probably some other complex things I couldn't be arsed to script into the server. ::)

I don't anticipate this server script taking off any time in the near future, so I won't be providing much support for it, though it may prove to be useful for any projects I do in the future, and possibly for someone else as well.

Without the example pages provided, the server is 603 lines long.

Download (1.0.0)
http://stormeus.vicelegends.com/SqHTTP.7z

105
Script Showroom / [Squirrel] Undocumented Functions
« on: April 06, 2012, 11:21:22 pm »
Seeing that most of us here are pretty decent scripters, I'm going to leave a list of undocumented functions in the Squirrel server that were found. I really don't like the idea of having "zomg excloosive" scripts when these functions are present in every copy of the Squirrel server. I also don't like having one server be able to use scripts that were accidentally skipped over when documenting the wiki, as it lowers the quality of other servers and makes the community overall shittier.

tl;dr morphine and gudio be mad

I did not do this alone. Gudio had found some other functions, and Morphine encouraged me to find the functions and, if my memory serves me right, found a couple as well. If you must ask what these do or how you use these, close this tab or window right now.

I decided not to post this on the official VC:MP Squirrel forum because god knows how many nabs await there.



Level 1
Stuff with no wiki pages

Player.SetIgnoredBy( Player playerToBlock, Boolean toBlock )
This will make the player ignore the given playerToBlock parameter, if toBlock is true. In other words, they'll be muted only to that player. When set to false, they are unmuted to the blocking player.

Player.IsIgnoredBy( Player playerPossiblyBlocked )
Returns boolean (true/false) value of whether the Player object is ignoring the playerPossiblyBlocked parameter.

SetWeaponDamage( Integer weapon, Float damage )
Does what it says on the label; default values for weapons are unknown. It's likely they correspond to the game's weapon configuration.

RemoveAllPickups( void )
Does what it says on the label; should remove all pickups.



Level 2
Shit that doesn't even appear on the wiki

onPlayerCrashDump( Player player, CrashAddress crash )
Called when a player performs a crash dump. However, their disconnection is not automatic. You will need to kick the player to make good use of this event.

onBannedConnectionAttempt( String IP )
Called when an RCON-banned player queries or attempts to join the server. Only their IP is passed, as a proper Player object is impossible to create given the nature of the event.

String Player.Velocity
Simply prints the string "Velocity" and is of no use.

Vector2D Vehicle.Velocity
Working vehicle velocity counter which can be useful for making speedometers. Returns a two-dimensional vector (x, y) which can then be used to calculate speed using this code:

Code: (Squirrel) [Select]
local v = player.Vehicle.Velocity;
local s = ( ( sqrt( (v.x * v.x) + (v.y * v.y) ) * 230 ) + 0.5).tointeger(); // kilometers per hour

GetPickupCount( void )
Simply returns the pickup count. Good if you dynamically create pickups but don't want to reach the limit.

GetVehicleCount( void )
Like GetPickupCount, returns the number of vehicles on the server.

CreateStaticVehicle( Integer model, Vector pos, Float angle, Integer col1, Integer col2 )
Working alias to CreateVehicle and can be used at any point in the script like CreateVehicle.

SetPlayerDesyncedPos( Player player, Vector pos )
Unknown if working. If it does work, this function presumably sets a desynced player's position, which will appear unchanged to synced players.

SetVehicleDesyncedPos( Vehicle vehicle, Vector pos )
See SetPlayerDesyncedPos



Level 3
Console commands

unload_script filename
Unloads a script according to filename

load_script filename
Loads a script according to filename (see: load_script)



Orange -- Unknown if working



This information is likely going to be copied to the official Squirrel wiki... eventually. ::)

Pages: 1 ... 5 6 [7] 8 9