tonnyf22 tonnyf22

IoC containers for Unity game engine

Deprecated libraries

Be careful, multiple famous IoC containers are deprecated. At a first glance, it may seem fine to forgive lack of recent commits. After all, if it's mature, then all the basics are done and polished and bugless. In other words, if it the project would be active, then all the new commits would be just exlusively about advanced features. Right? No. The world of game development doesn't work like that. It must innovate rapidly and fretting about backward compatibility is not compatible with this reality.

XDG - Base Directory Specification `(extended)`

Directories

Base

The intended use-case for BaseDirectories is to query the paths of user-invisible standard directories that have been defined according to the conventions of the operating system the library is running on.

ANSI Escape Sequences

Standard escape codes are prefixed with Escape:

Ctrl-Key: ^[
Octal: \033
Unicode: \u001b
Hexadecimal: \x1B
Decimal: 27

Regular Colors

Value	Color
\e[0;30m	Black
\e[0;31m	Red
\e[0;32m	Green
\e[0;33m	Yellow
\e[0;34m	Blue
\e[0;35m	Purple

Hyperlinks (a.k.a. HTML-like anchors) in terminal emulators

[ Update 2025-03-24: Commenting is disabled permanently. Previous comments are archived at web.archive.org. ]

Most of the terminal emulators auto-detect when a URL appears onscreen and allow to conveniently open them (e.g. via Ctrl+click or Cmd+click, or the right click menu).

It was, however, not possible until now for arbitrary text to point to URLs, just as on webpages.

Documentation-Driven Development

The philosophy behind Documentation-Driven Development is a simple: from the perspective of a user, if a feature is not documented, then it doesn't exist, and if a feature is documented incorrectly, then it's broken.

Document the feature first. Figure out how you're going to describe the feature to users; if it's not documented, it doesn't exist. Documentation is the best way to define a feature in a user's eyes.
Whenever possible, documentation should be reviewed by users (community or Spark Elite) before any development begins.
Once documentation has been written, development should commence, and test-driven development is preferred.
Unit tests should be written that test the features as described by the documentation. If the functionality ever comes out of alignment with the documentation, tests should fail.
When a feature is being modified, it should be modified documentation-first.
When documentation is modified, so should be the tests.

	/*** MIT LICENSE
	Copyright (c) 2022 torcado

	Permission is hereby granted, free of charge, to any person
	obtaining a copy of this software and associated documentation
	files (the "Software"), to deal in the Software without
	restriction, including without limitation the rights to use,
	copy, modify, merge, publish, distribute, sublicense, and/or sell
	copies of the Software, and to permit persons to whom the
	Software is furnished to do so, subject to the following

	using System;
	using UnityEditor;
	using UnityEngine;

	// Use Example 1: [VTRangeStep(0f, 10f, 0.25f)]
	// Use Example 2: [VTRangeStep(100, 1000, 25)]
	namespace Victor.Tools
	{
	[AttributeUsage(AttributeTargets.Field, Inherited = true, AllowMultiple = false)]
	public sealed class VTRangeStep : PropertyAttribute

	// Original rules: https://github.com/coldfix/udiskie/wiki/Permissions
	// Changes: Added org.freedesktop.udisks2.filesystem-mount-system, as this is used by Dolphin.

	polkit.addRule(function(action, subject) {
	var YES = polkit.Result.YES;
	// NOTE: there must be a comma at the end of each line except for the last:
	var permission = {
	// required for udisks1:
	"org.freedesktop.udisks.filesystem-mount": YES,
	"org.freedesktop.udisks.luks-unlock": YES,


	## Modified commands
	alias diff='colordiff' # requires colordiff package
	alias grep='grep --color=auto'
	alias more='less'
	alias df='df -h'
	alias du='du -c -h'
	alias mkdir='mkdir -p -v'
	alias nano='nano -w'
	alias ping='ping -c 5'