Recent Posts

Pages: [1] 2 3 ... 10
1
Some might wonder, "Why C Shell?"
Various reasons: C-like syntax, better built-ins, better scripting, a rich set of mathematical and logical operators, many convenient features (auto-correct, history substitution, built-in math).
It's also very secure; being "limited" makes it secure. (E.g: Nesting is minimal, thus preventing Shell injections at all costs; there are better ways to achieve what one want.)

The C Shell teaches how to safely write scripts. It's very cool. :)
The limitations aren't drawbacks.
http://parallel.vub.ac.be/documentation/linux/unixdoc_download/Scripts.html
2
NEW: Ported to C Shell. (Still need to work on rcon_kills and rcon_commands.)
[As of now, all scripts have been ported.]

The C Shell is powerful, more reliable and suitable for this project.
The code relies in the same repository, but in a new branch.
https://github.com/Krush206/soldat-shell/tree/csh
3
CTF/INF maps / Re: [CTF] Blood for the Blood God
« Last post by Aeronic on October 31, 2021, 08:02:01 am »
Another lockdown, another update.  I feel the new changes better reflect how I'd like the map to play, particularly around bases.  See top post to download. 

Changelog:

1.4 - 1.7.4
* major change to player spawn location: both teams now always spawn in a new room located behind their flag
* spawn room jump pads allow players to get out of spawn quickly by using one-way-through polys
* opened hole in front defensements to allow more routing possibilities
* removed some scenery, and where necessary corresponding colliders
* removed scenery files, including most instructive graphics - ugly and unnecessary.  Also lowers download size
* changed 0pixel polys to work throughout the entire rope; added ropes to top route (grenade gfx removed from ropes)
* added hole in the floor of the murder holes above the entrances to the low routes, through which grenades can be thrown
* added anti-flag/flag carrier polys in the low-mid base entrances; as an attempt to slow flag escapees by forcing either a skillcheck or seeking another route
* lowered maximum jet fuel amount from 170 to 130
* added hidden polys to golden statue area so that it may be visible on minimap (F3)
* changed some grenade spawn locations
* minor poly fixes & improvements
* minor visual & readability improvements
4
The Lounge / Re: So I'm with FliesLikeABrick...
« Last post by GymPolice on September 22, 2021, 04:50:51 am »
That's awesome, Flab! That's the kinda energy in the room I'd expect from Soldat players. :P
5
The Lounge / Re: So I'm with FliesLikeABrick...
« Last post by FliesLikeABrick on September 16, 2021, 08:59:32 pm »
Still lookin' sharp, Bricks! FLAB stopped by one time when he was visiting his servers here in Chicago. Stop by again sometime, Bricks. I have money now, so we can actually hang out somewhere. >_>

Came across this thread on Google results when I was looking for something else, I figure I'll reply and go for "longest-ever old thread bump"?

I ended up moving to Chicago for a while, and a few months (or maybe a year) after we moved there - March 2013 -- a bunch of people came over to our apartment:
- Joe flew up from FL
- MM flew in from Poland on his way to the GDC conference
- Geti also stopped by no the way to GDC
- Kazrak took the train in from the suburbs


Picture I dug up, starring the back of MM's head, I think this was the day before Kazrak came and visited
6
Instead, why not find a way to pass netcat's stdin and stdout to your script's stdin and stdout, and operate on incoming lines as you receive them, using `while read line` or similar? That way you aren't busy waiting (as each loop iteration will block on reading an incoming message), won't drop messages, and will consume far fewer resources.
I have done what you suggested and seems to be working well. As a side note, since netcat cannot run programs within a socket, I had to use socat to attach stdin and stdout to the script. Busybox's netcat and Nmap's Ncat are two other options, but I did not opt to use them, since socat is more of a complete, advanced tool and I'm mostly used to it.
I will upload the sources to GitHub as soon as I reimplement the other scripts (have reimplemented only rcon_commands as of now).
7
Backticks are old and some shenanigans can happen with them and they are still there only for backward compatibility afaik.

To be fair, that's most of Unix and computing in general.

Personally, I think backticks are cooler and I usually go for them first, and then switch to $( ) when I need to nest something.
8
Backticks are old and some shenanigans can happen with them and they are still there only for backward compatibility afaik.
9
- In cases like https://github.com/Krush206/soldat-shell/blob/main/rcon_balancer#L91 why not use $( $( ) ) type nested shell execution as opposed to backticks which you had to escape?
I have always been used to backticks, but I will consider to replace them.
- It seems like /tmp is hard coded in various places, might be helpful to make that customizable
Since this is the default directory for temporary files, I did not really want to use something random/unknown. Regardless, I may implement custom variables. However, the recommendation to have a tmpfs mount will always remain.
- Have you considered the possibility for shell injection, eg if a player has malicious characters in their names?
Not really, but I'm making a note of and considering this, too.
It looks like the main loop of these scripts is an infinite busy-wait where you check for recognizable commands in /tmp/cmds, and if there are any you take action and immediately wipe the file. I have a few concerns with this approach:

- with each iteration of the while loop (numerous per second as there are no sleeps) you'll be spawning off numerous `grep` processes, especially if none of them match (each elif). This would consume excessive resources

- if there are many incoming messages at once, some of them will get dropped/ignored as the relevant `grep` might miss them

Instead, why not find a way to pass netcat's stdin and stdout to your script's stdin and stdout, and operate on incoming lines as you receive them, using `while read line` or similar? That way you aren't busy waiting (as each loop iteration will block on reading an incoming message), won't drop messages, and will consume far fewer resources.
You are right. I have always been concerned of the same reasons, too. Thanks for the input, I will replace the loop statement and implement netcat within the script.
When writing Bash script I cannot recommend ShellCheck enough. It checks your code for best practices and errors. There's command line version and many text editors support it, at the very least I know for sure that Visual Studio Code does support it.
This may come handy. Thanks.
10
When writing Bash script I cannot recommend ShellCheck enough. It checks your code for best practices and errors. There's command line version and many text editors support it, at the very least I know for sure that Visual Studio Code does support it.
Pages: [1] 2 3 ... 10