More things changed. Added icons to some menu items. Lots of other things.
kts
parent
9ba78b644e
commit
eaa57c7dba
|
|
@ -1 +1 @@
|
|||
Expedite progress -- think in the future, not in the now. The now has had enough thought from the past. Become estranged from the now.
|
||||
Expedite progress -- think in the future, become estranged from the now.
|
||||
|
|
|
|||
|
|
@ -1,3 +1,3 @@
|
|||
The **Order of Precedence** is to //improve oneself//, //learn//, and //have fun//. One should first seek to improve oneself. Improving oneself often comes through learning. Learning comes best with it is fun.
|
||||
|
||||
If learning is not fun, one must still learn. If improving oneself does not acquire new knowledge, one must still improve. In this way, one must always seek these things, but be willing to do away with the least of them.
|
||||
However, if learning is not fun, one must still learn. If improving oneself does not acquire new knowledge, one must still improve. In this way, one must always seek these things, but be willing to do away with the least of them.
|
||||
|
|
|
|||
|
|
@ -1 +1 @@
|
|||
To society's human, the first principles of society are seen as immutable properties of general human organization and being. Every possible world is seen through a strict lense of societal-formulative biases -- core fundamentals taken for granted as the required basis for humanity.
|
||||
To society's human, the first principles of their society are seen as immutable properties of general human organization and being. Every possible world is seen through a strict lense of societal-formulative biases -- core fundamentals taken for granted as the required basis for humanity.
|
||||
|
|
|
|||
|
|
@ -0,0 +1 @@
|
|||
Avoid immaterial and trite expenditures of time and energy. Any moment not spent improving oneself decreases the maximum potential for flourishing.
|
||||
|
|
@ -0,0 +1 @@
|
|||
Do not waste time debating the worth of one tool over another. Even a coarse brush can create fine art in the hands of one who truly seeks to create.
|
||||
35
build.sh
35
build.sh
|
|
@ -14,12 +14,25 @@ mkdir -p live/fonts
|
|||
cp -pfv fonts/* live/fonts/
|
||||
echo " Copying images..."
|
||||
mkdir -p live/pix
|
||||
cp -pfv pix/* live/pix/
|
||||
echo "Building kettext..."
|
||||
../kettext/kettext.pl menu.ktx > live/menu.html
|
||||
../kettext/kettext.pl front.ktx > live/front.html
|
||||
../kettext/kettext.pl proclib.ktx > live/proclib.html
|
||||
../kettext/kettext.pl TODO.ktx --header.depth=2 > live/TODO.html
|
||||
cp -prfv pix/* live/pix/
|
||||
echo "Build menu..."
|
||||
../kettext/kettext.pl menu.ktx --version.none > live/menu.html
|
||||
echo "Building pages..."
|
||||
mkdir -p live/pages
|
||||
for f in pages/*
|
||||
do
|
||||
if [ -d "$f" ]; then
|
||||
mkdir -p live/$f;
|
||||
for f2 in $f/*
|
||||
do
|
||||
html=`echo $f2 | sed 's/\(.*\.\)ktx/\1html/'`;
|
||||
../kettext/kettext.pl --version.none $f2 > live/$html
|
||||
done
|
||||
else
|
||||
html=`echo $f | sed 's/\(.*\.\)ktx/\1html/'`;
|
||||
../kettext/kettext.pl $f --version.none > live/$html
|
||||
fi
|
||||
done
|
||||
echo "Building aphorism..."
|
||||
mkdir -p live/aphorism
|
||||
for f in aphorism/*
|
||||
|
|
@ -28,16 +41,20 @@ do
|
|||
../kettext/kettext.pl $f --version.none > live/$html
|
||||
done
|
||||
echo "Building dox..."
|
||||
../kettext/kettext.pl dox.ktx > live/dox.html
|
||||
mkdir -p live/dox
|
||||
for f in dox/*
|
||||
do
|
||||
html=`echo $f | sed 's/\(.*\.\)ktx/\1html/'`;
|
||||
../kettext/kettext.pl $f --version.none --header.depth=2 > live/$html
|
||||
done
|
||||
|
||||
echo "Building news..."
|
||||
mkdir -p live/news
|
||||
for f in news/*
|
||||
do
|
||||
html=`echo $f | sed 's/\(.*\.\)ktx/\1html/'`;
|
||||
../kettext/kettext.pl $f --version.none --header.depth=2 > live/$html
|
||||
done
|
||||
echo "Copying plans..."
|
||||
../kettext/kettext.pl plans.ktx > live/plans.html
|
||||
mkdir -p live/plans
|
||||
for f in ~/.plans/*
|
||||
do
|
||||
|
|
|
|||
|
|
@ -25,6 +25,17 @@ body {
|
|||
background-color: #FFF;
|
||||
font-family: "Source Sans Pro";
|
||||
}
|
||||
p small {
|
||||
font-size: 10pt;
|
||||
}
|
||||
img {
|
||||
text-align: center;
|
||||
}
|
||||
.thumbnail {
|
||||
max-width: 280px;
|
||||
max-height: 157px;
|
||||
float: right;
|
||||
}
|
||||
/* general helper classes */
|
||||
.min {
|
||||
margin: 0 auto;
|
||||
|
|
@ -87,18 +98,29 @@ body {
|
|||
/* */
|
||||
#menu {
|
||||
position: relative;
|
||||
width: 23%;
|
||||
width: 20%;
|
||||
min-height: 70%;
|
||||
float: right;
|
||||
background-color: #FFF;
|
||||
color: #1F1F1F;
|
||||
font-size: 16pt;
|
||||
line-height: 150%;
|
||||
}
|
||||
|
||||
#menu p {
|
||||
padding: 0;
|
||||
margin: 0;
|
||||
font-size: 10pt;
|
||||
}
|
||||
|
||||
#menu img {
|
||||
max-height: 22px;
|
||||
}
|
||||
|
||||
#menu ul {
|
||||
padding: 0; margin: 0;
|
||||
list-style: none;
|
||||
font-family: "Antonio";
|
||||
font-size: 16pt;
|
||||
}
|
||||
|
||||
#menu ul li {
|
||||
|
|
@ -107,6 +129,9 @@ body {
|
|||
color: #121;
|
||||
border-bottom: 1px solid #322222;
|
||||
}
|
||||
#menu ul li:last-child {
|
||||
border: 0;
|
||||
}
|
||||
|
||||
#menu ul a {
|
||||
color: #9f9f60;
|
||||
|
|
@ -116,13 +141,15 @@ body {
|
|||
position: relative;
|
||||
font-family: "Antonio";
|
||||
font-size: 18pt;
|
||||
padding: 0.1em;
|
||||
padding: 0.2em;
|
||||
color: #EDDDDD;
|
||||
background-color: #322222;
|
||||
}
|
||||
#menu h1 a{
|
||||
color: #EDDDDD;
|
||||
}
|
||||
|
||||
#menu a {
|
||||
display: block;
|
||||
width: 100%;
|
||||
text-decoration: none;
|
||||
}
|
||||
|
|
@ -188,6 +215,13 @@ body {
|
|||
color: #CaCf90;
|
||||
cursor: pointer;
|
||||
}
|
||||
#content img {
|
||||
}
|
||||
#content iframe {
|
||||
width: 280px;
|
||||
height: 157px;
|
||||
float: right;
|
||||
}
|
||||
|
||||
.arrow {
|
||||
display: inline-block;
|
||||
|
|
|
|||
|
|
@ -97,14 +97,15 @@
|
|||
margin-left: -10%;
|
||||
margin-top: 0.5em;
|
||||
font-weight: bold;
|
||||
padding: 0.35em;
|
||||
}
|
||||
|
||||
#content h1 { margin-left: -10%; font-size: 24pt; }
|
||||
#content h2 { margin-left: -9%; font-size: 22pt; }
|
||||
#content h3 { margin-left: -8%; font-size: 20pt; }
|
||||
#content h4 { margin-left: -7%; font-size: 18pt; }
|
||||
#content h5 { margin-left: -6%; font-size: 16pt; }
|
||||
#content h6 { margin-left: -5%; font-size: 14pt; }
|
||||
#content h1 { width: 108%; margin-left: -10%; font-size: 20pt; }
|
||||
#content h2 { width: 107%; margin-left: -9%; font-size: 18pt; }
|
||||
#content h3 { width: 106%; margin-left: -8%; font-size: 16pt; }
|
||||
#content h4 { width: 105%; margin-left: -7%; font-size: 14pt; }
|
||||
#content h5 { width: 104%; margin-left: -6%; font-size: 12pt; }
|
||||
#content h6 { width: 103%; margin-left: -5%; font-size: 10pt; }
|
||||
|
||||
#content pre {
|
||||
-webkit-box-shadow: 0px 0 30px rgba(0, 0, 0, 0.1) inset;
|
||||
|
|
|
|||
|
|
@ -0,0 +1,87 @@
|
|||
,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
|
||||
X11 Desktop + Camera Capture with ffmpeg
|
||||
````````````````````````````````````````````````
|
||||
This document is my minimalistic approach to recording my X11 desktop and camera simultaneously on Linux. The ``ffmpeg`` commands in this document use mouse following, as my multi-monitor setup is rather large and leaves some dead-space. Additionally, we want minimal processing, but not enormous files -- hence, we use x264 with minimal, near-lossless, encoding. Finally, we want to record at one frame per second so we can effectively timelapse 60 seconds into 1 second at 60 frames per second.
|
||||
|
||||
Do not expect a UI or anything of the sort. This is a hands-on approach using shell scripting. I prefer this.
|
||||
|
||||
,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
|
||||
Desktop Recording: The Command
|
||||
````````````````````````````````
|
||||
The basic command we want to issue is:
|
||||
|
||||
#ffmpeg -f x11grab -follow_mouse 428 -draw_mouse 1 -r 1 -video_size 1280x720 -i :0.0 -vcodec libx264 -preset ultrafast -qp 0 my_file.mkv
|
||||
|
||||
However, we will want to activate this command indirectly via a script that will be activated by the window manager or ``xbindkeys``. Additionally, we will want some audible indicator of starting and stopping.
|
||||
|
||||
,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
|
||||
Desktop Recording: The Script
|
||||
````````````````````````````````
|
||||
To make this script work, we will: have the file, ``~/.record_poll`` act as both the ``stdin`` redirection for ``ffmpeg`` and as a check for if we are recording. Our capture directory is assumed to exist at ``~/capture/``.
|
||||
|
||||
#.include(record)
|
||||
##!/bin/bash
|
||||
#if [ -f ~/.record_poll ];
|
||||
#then
|
||||
# echo 'q' > ~/.record_poll
|
||||
#else
|
||||
# touch ~/.record_poll
|
||||
# date=`date +%Y-%m-%d`
|
||||
# play /usr/share/sounds/freedesktop/stereo/device-added.oga
|
||||
# <~/.record_poll ffmpeg -f x11grab -follow_mouse 428 -draw_mouse 1 -r 1 -video_size 1280x720 -i :0.0 -vcodec libx264 -preset ultrafast -qp 0 ~/capture/$date/900_`date +%s`.mkv 2>>~/.record_log
|
||||
# rm ~/.record_poll
|
||||
# play /usr/share/sounds/freedesktop/stereo/device-removed.oga
|
||||
#fi
|
||||
|
||||
To test this, open two terminals. Run ``record`` in one to start, then run ``record`` in the other to stop -- or use one terminal and append ``&`` to ``record``.
|
||||
|
||||
Alternatively, you could issue a SIGINT or SIGTERM to ffmpeg ((pkill -SIGINT ffmpeg)) to stop rather than polling a file. This behavior seems to vary depending on your ``ffmpeg`` version, so I used a more universal and safe method.
|
||||
|
||||
,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
|
||||
Camera Recording: The Command
|
||||
````````````````````````````````
|
||||
This command is similar to Desktop Recording, but uses the v4l device as the input. This __will__ vary depending on your camera setup.
|
||||
|
||||
#ffmpeg -f v4l2 -input_format mjpeg -r 5 -video_size 640x360 -i /dev/video0 -c:v copy -acodec null my_file.avi
|
||||
|
||||
Some technical notes must be made here. For this entire operation I wanted to avoid all unneeded CPU usage, so as to leave the actual desktop activity unhindered. As a result, I am using the camera's built-in encoding abilities to produce an mjpeg stream and almost no cost to the CPU. However, web cameras vary greatly in their capabilities, in terms of minimum and maximum framerate, built-in encoding, and video sizes. To get a basic listing of supported settings for your ``/dev/video0`` device, run:
|
||||
|
||||
#ffmpeg -f v4l2 -list_formats -all -i /dev/video0
|
||||
|
||||
To get extending information on FPS settings:
|
||||
|
||||
#v4l2-ctl --list-formats-ext
|
||||
|
||||
Finally, in the case of my camera, it only allowed a minimum of 5 frames per second - more than what I needed. To compensate, I had to run post-proccessing to drop the unneeded frames:
|
||||
|
||||
#ffmpeg -i my_file.avi -r 1 my_file_1fps.avi
|
||||
|
||||
,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
|
||||
Camera Recording: The Script
|
||||
````````````````````````````````
|
||||
This script follows the exact order of the Desktop Recording:
|
||||
|
||||
#.include(record_camera)
|
||||
##!/bin/bash
|
||||
#if [ -f ~/.camera_poll ];
|
||||
#then
|
||||
# echo 'q' > ~/.camera_poll
|
||||
#else
|
||||
# touch ~/.camera_poll
|
||||
# date=`date +%Y-%m-%d`
|
||||
# play /usr/share/sounds/freedesktop/stereo/device-added.oga
|
||||
# <~/.camera_poll ffmpeg -f v4l2 -input_format mjpeg -r 5 -video_size 640x360 -i /dev/video0 -c:v copy -acodec null my_file.avi ~/capture/$date/camera_`data +%s`.avi 2>>~/.camera_log
|
||||
# rm ~/.camera_poll
|
||||
# play /usr/share/sounds/freedesktop/stereo/device-removed.oga
|
||||
#fi
|
||||
|
||||
,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
|
||||
The Meta Script
|
||||
````````````````````````````````
|
||||
To finally tie them together, we just run them at (almost) the same time via a bash script:
|
||||
|
||||
##!/bin/bash
|
||||
#~/bin/rec_camera &
|
||||
#~/bin/rec_desktop &
|
||||
|
||||
Issue this command to start/stop recording as you wish. One note: You could combine these three scripts into one script or even use ffmpeg to pre-embed the camera recording into the desktop recording with some additional CPU usage.
|
||||
32
index.php
32
index.php
|
|
@ -5,9 +5,19 @@ $pages = [
|
|||
"kettext",
|
||||
"front",
|
||||
"plans",
|
||||
"dox"
|
||||
"news",
|
||||
"netwine",
|
||||
"dox",
|
||||
"cirquit",
|
||||
"petite_juliet",
|
||||
"VAD",
|
||||
"newsboy",
|
||||
"about",
|
||||
"utilities",
|
||||
"ARK",
|
||||
"noirchat"
|
||||
];
|
||||
$current_page = "front";
|
||||
$current_page = "news";
|
||||
foreach ($pages as $page) {
|
||||
foreach ($_GET as $get=>$value) {
|
||||
if ($get == $page) {
|
||||
|
|
@ -53,6 +63,14 @@ if ($current_page == "plans") {
|
|||
$post .= '<a href="?dox" class="surf">Back to index</a><br />';
|
||||
$post .= (file_get_contents("dox/".$_GET['dox']));
|
||||
}
|
||||
} else if ($current_page == "news") {
|
||||
$news = scandir('news/');
|
||||
array_shift($news);
|
||||
array_shift($news);
|
||||
rsort($news);
|
||||
for ($i = 0; $i < count($news); $i++) {
|
||||
$post .= (file_get_contents("news/".$news[$i]));
|
||||
}
|
||||
}
|
||||
|
||||
?>
|
||||
|
|
@ -65,23 +83,21 @@ if ($current_page == "plans") {
|
|||
<link rel="stylesheet" href="css/style_reset.css">
|
||||
<link rel="stylesheet" href="css/style.css">
|
||||
<link rel="stylesheet" href="css/style_pretty.css">
|
||||
<script type="text/javascript" src="javascript/folder.js"></script>
|
||||
<!--<script type="text/javascript" src="javascript/folder.js"></script>-->
|
||||
</head>
|
||||
<body>
|
||||
<div id="header">
|
||||
<div class="min">
|
||||
<div id="puss"></div>
|
||||
<a href="/kettek/"><div id="puss"></div></a>
|
||||
<div class="qat_bubble"><?php include($aphorism); ?></div>
|
||||
</div>
|
||||
</div>
|
||||
<div class="min">
|
||||
<div id="menu">
|
||||
<div class="padder">
|
||||
<?php include 'menu.html' ?>
|
||||
</div>
|
||||
<?php include 'menu.html' ?>
|
||||
</div>
|
||||
<div id="content">
|
||||
<?php include $current_page.'.html' ?>
|
||||
<?php (file_exists('pages/'.$current_page.'.html') ? include 'pages/'.$current_page.'.html' : '')?>
|
||||
<?php echo ($post ? $post : '') ?>
|
||||
</div>
|
||||
</div>
|
||||
|
|
|
|||
38
menu.ktx
38
menu.ktx
|
|
@ -1,18 +1,28 @@
|
|||
.imply(version.none)
|
||||
==== [[General]]
|
||||
* [[Articles]].href(?dox).alt(Wordsmithing)
|
||||
* [[.plans]].href(?plans).alt(Of Action)
|
||||
* [[TODO]].href(?TODO).alt(A lack of gettin' busy)
|
||||
==== [[kettek]]
|
||||
((written things))
|
||||
* [[About kts]](?about).title(The Self)
|
||||
* [[Articles & Documents]](?dox).title(Substantial writings)
|
||||
* [[Technical Notes]](?notes).title(technical notes and how-tos)
|
||||
* [[.plans]](?plans).title(Of Action)
|
||||
==== [[Games]]
|
||||
* [[Newsboy/]].href(newsboy/).alt(Escape The Net)
|
||||
* [[CirQuit/]].href(CirQuit/).alt(Find Enlightenment)
|
||||
* [[VAD/]].href(VAD/).alt(Get Vadding!)
|
||||
==== [[Projects]]
|
||||
* [[kettext]].href(?kettext).alt(markup language)
|
||||
* [[proclib]].href(?proclib).alt(procedural generation!)
|
||||
==== [[Lab]].alt(less-than-complete things)
|
||||
* [[procsicle]].href(?procsicle).alt(PHP process linkage and terminal client)
|
||||
* [[noirchat]].href(?noirchat).alt(decentralized chatting at its finest)
|
||||
((open source gamus))
|
||||
* [[img:pix/icon_juliet.gif]] [[Petite Juliet]](?petite_juliet).title(Petite Juliet)
|
||||
* [[img:pix/icon_newsboy.gif]] [[Newsboy/]](http://kettek.exoss.net/newsboy/).target(_blank).title(Escape The Net)
|
||||
* [[img:pix/icon_cirquit.gif]] [[CirQuit]](?cirquit).title(Find Enlightenment)
|
||||
* [[img:pix/icon_vad.gif]] [[VAD]](?VAD).title(Get Vadding!)
|
||||
==== [[Software]]
|
||||
((tools, libraries))
|
||||
* [[img:pix/icon_kettext.gif]] [[kettext]](?kettext).title(markup language)
|
||||
* [[img:pix/icon_proclib.gif]] [[proclib]](?proclib).title(procedural generation!)
|
||||
* [[img:pix/icon_ark.gif]] [[ARK]](?ARK).title(Alternative Registry Keeper)
|
||||
* [[Utilities]](?utilities).title(older utilities)
|
||||
==== [[Lab]].title(less-than-complete things)
|
||||
((experiments that could level up))
|
||||
* [[procsicle]](?procsicle).title(PHP process linkage and terminal client)
|
||||
* [[noirchat]](?noirchat).title(decentralized chatting at its finest)
|
||||
* [[netwine]](?netwine).title(browser-based UDP/TCP/etc bridge)
|
||||
* [[mediaServe]](?mediaServe).title(PHP Multimedia Serving)
|
||||
|
||||
<a class="twitter-timeline" width="180" height="300" href="https://twitter.com/kts_kettek" data-chrome="transparent noborders" data-widget-id="538319352290746369">Tweets by @kts_kettek</a>
|
||||
<a class="twitter-timeline" height="300" href="https://twitter.com/kts_kettek" data-chrome="transparent noborders" data-widget-id="538319352290746369">Tweets by @kts_kettek</a>
|
||||
<script>!function(d,s,id){var js,fjs=d.getElementsByTagName(s)[0],p=/^http:/.test(d.location)?'http':'https';if(!d.getElementById(id)){js=d.createElement(s);js.id=id;js.src=p+"://platform.twitter.com/widgets.js";fjs.parentNode.insertBefore(js,fjs);}}(document,"script","twitter-wjs");</script>
|
||||
|
|
|
|||
|
|
@ -0,0 +1,9 @@
|
|||
,,,,,,,,,,,,,,,,,,,,,,,,
|
||||
//2014-12-09// - Petite Juliet Released!
|
||||
````````````````````````
|
||||
After slogging through Ludum Dare 31, [[Petite Juliet]].href(?petite_juliet) has been created! Developed from scratch using C++, SDL2, OpenGL, and GLSL, it's kind of a cool little game.
|
||||
|
||||
[[img:pix/petite_juliet.png]]
|
||||
((27 out of 48 hours were blasted away in the creation of this game.))
|
||||
|
||||
I plan to expand it in the future, implementing some of the features that were (sadly) missed due to rushing about. See the TODO [[here]].rhef(?petite_juliet).
|
||||
|
|
@ -0,0 +1,4 @@
|
|||
,,,,,,,,,,,,,,,,,,,,,,,,
|
||||
//2014-12-16// - Website Draft
|
||||
````````````````````````
|
||||
This here is a draft post.
|
||||
|
|
@ -0,0 +1,19 @@
|
|||
,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
|
||||
ARK - Alternative Registry Keeper
|
||||
````````````````````````````````
|
||||
//Latest Version:// **1.0** (((2014-12-22))) / [[archive]].href(archive/ark) / [[git]].href(http://kettek.exoss.net/git/ARK)
|
||||
|
||||
ARK is a fancy [[HTML5 & JavaScript enhanced]].title(The cool kids call it modern) directory index written in PHP. It is intended to be a sleek replacement for the standard Apache Directory Listings.
|
||||
|
||||
A concise list of features:
|
||||
* Single PHP script and optional, but recommended, ``.htaccess`` file for RewriteRules
|
||||
* File/Directory specific blacklisting
|
||||
* [[Glob]].href(http://php.net/manual/en/function.glob.php) pattern matching
|
||||
* Customizable field selections based on [[stat()]].href(http://php.net/manual/en/function.stat.php)
|
||||
* HTML5, CSS3, and optional JavaScript to make things fancy
|
||||
* Keyboard support (hjkl, arrow keys, easily modifiable)
|
||||
* Save thy bandwidth, update via XMLHTTPRequest
|
||||
* Base64 embedded icons
|
||||
* Pretty small!
|
||||
|
||||
((A dark secret: This was mainly written so I could toy with heredoc syntax))
|
||||
|
|
@ -0,0 +1,34 @@
|
|||
,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
|
||||
Things That This Being Must Do
|
||||
````````````````````````````````
|
||||
For my own benefit, I've put my TODO in this most public of places.
|
||||
,,,,,,,,,,,,,,,,,,,,,,,,
|
||||
Things I have to do anyway
|
||||
````````````````````````
|
||||
* Finish Dr. Cole's site, along with mobile styling
|
||||
|
||||
,,,,,,,,,,,,,,,,,,,,,,,,
|
||||
Polymathic Things
|
||||
````````````````````````
|
||||
* Hustle to get Vashram stand-alone going
|
||||
* Resume Celestial Carnage - see its TODO
|
||||
* Implement timesynk's Virtual Machine compiler
|
||||
|
||||
,,,,,,,,,,,,,,,,,,,,,,,,
|
||||
Fun Things of Precedence
|
||||
````````````````````````
|
||||
* Create timelapse videos for Newsboy and VAD
|
||||
* Finish up SDL renderer for VAD 0.2 and release it.
|
||||
* Create a narrative of Carmack's idTech engines for the YouTubes
|
||||
* Finish LootKeeper and Get It Out There
|
||||
* Implement last aspects of MediaServe (JavaScript linkage)
|
||||
* Implement networking of ktk_walker and test it out
|
||||
|
||||
,,,,,,,,,,,,,,,,,,,,,,,,
|
||||
Extraneous Things of Learning
|
||||
````````````````````````
|
||||
* Learn to read Braille
|
||||
* Resume learning Japanese
|
||||
* Begin learning Chinese
|
||||
* Learn ASL or some equivalent
|
||||
* Learn Russian
|
||||
|
|
@ -0,0 +1,19 @@
|
|||
,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
|
||||
VAD
|
||||
````````````````````````````````
|
||||
[[img:pix/icon_vad.gif]].width(64px).style(float:right;)
|
||||
|
||||
//Latest Version:// **0.2** (((2014-12-16))) / [[archive]].href(archives/VAD) / [[git]].href(http://kettek.exoss.net/git/VAD)
|
||||
|
||||
* [[Linux 32-bit and 64-bit]].href(archives/VAD/latest_linux)
|
||||
* [[Mac OS X Universal (ppc/intel)]].href(archives/VAD/latest_macosx)
|
||||
* [[Windows 7 32-bit]].href(archives/VAD/latest_windows)
|
||||
* [[GPLv3 Source]].href(archives/VAD/latest_source)
|
||||
|
||||
Deep in the underdark, the ancient beast awaited the arrival of some forlorn adventurer seeking the treasures of the forgotten gods. This traveler would need more than mere strength to defeat such a guardian -- wit and cunning would be the true deciders of fate...
|
||||
|
||||
But with what means could such a feat become possible?
|
||||
|
||||
**Why, with VAD, of course!**
|
||||
|
||||
VAD is an engine for text-based, prose-centric adventures. It holds a modular design that allows for multiple front-ends, such as **curses** and **SDL**, along with back-ends that allow for different adventure formats, such as **VAD** and **ADV**.
|
||||
|
|
@ -0,0 +1,48 @@
|
|||
,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
|
||||
About
|
||||
````````````````````````````````
|
||||
This website -- and all content unless otherwise noted -- was created by **kts / Ketchetwahmeegwun T. Southall**.
|
||||
|
||||
Feel free to contact me through any of these mediums:
|
||||
* **E-mail:** kettek1[[img:pix/at.gif]].style(float:none;).alt(@)exoss.net
|
||||
* **XMPP:** kts[[img:pix/at.gif]].style(float:none;).alt(@)wechat.exoss.net
|
||||
* **Twitter:** [[@kts_kettek]](https://twitter.com/kts_kettek/)
|
||||
|
||||
----
|
||||
|
||||
This page is here so as to provide a more complete description of my person.
|
||||
|
||||
**I...**
|
||||
* am a Free software advocate
|
||||
* graduated in philosophy
|
||||
* care about learning, making cool stuff, having fun, and teaching others to do the same.
|
||||
|
||||
**I have...**
|
||||
* 8+ years experience with PHP/JavaScript/HTML
|
||||
* 8+ years experience with C
|
||||
* 6+ years experience with C++
|
||||
* Familiarity with Java, Python, and Perl (this website is primarily generated with perl+regex using [[kettext]](?kettext))
|
||||
|
||||
**I have also had...**
|
||||
* 8+ years managing Apache/PHP and SSH services
|
||||
* 4+ years managing SQL databases
|
||||
* 3+ years managing XMPP and mumble services
|
||||
|
||||
**I have also done...**
|
||||
* [[internet video streaming]](http://cerebustv.com)
|
||||
* Asterisk SIP
|
||||
* IPv4 camera security
|
||||
|
||||
**I have played with...**
|
||||
* [[Redundant ZFS clustering]](?dox=redundant_zfs_clustering)
|
||||
* IRC server management
|
||||
* IMAP email services
|
||||
* programming virtual machines and languages
|
||||
* 3d modeling and animating with Blender
|
||||
|
||||
**I have interests in...**
|
||||
* Syntax and Language parsing
|
||||
* AI
|
||||
* network programming
|
||||
* game development
|
||||
* visual design
|
||||
|
|
@ -0,0 +1,33 @@
|
|||
,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
|
||||
CirQuit
|
||||
````````````````````````````````
|
||||
[[yt:https://www.youtube.com/watch?v=shlxBj0F02M]]
|
||||
|
||||
//Latest Version:// **1.0** (((2014-07-07))) / [[archive]].href(archives/cirquit) / [[git]].href(http://kettek.exoss.net/git/cirquit)
|
||||
* [[Stand-alone]].href(archives/VAD/latest)
|
||||
* [[GPLv3 Source]].href(archives/VAD/latest_source)
|
||||
|
||||
CirQuit is a puzzle game that adheres to some NES limitations, such as sprite sizes, screen size, and controls. It was created for the NES-themed gamejam, #NESJAM and is written in JavaScript using [[CBDL]].href(?CBDL).
|
||||
<div style="width:100%;margin:auto;text-align:center;">
|
||||
Start: **Enter** | A: **X** | B: **Z** | DPad: **Arrow Keys**
|
||||
<iframe src="http://kettek.exoss.net/CirQuit/" style="float:none;width:320px;height:240px;"></iframe>
|
||||
</div>
|
||||
,,,,,,,,,,,,,,,,,,,,,,,,
|
||||
The Plot
|
||||
````````````````````````
|
||||
Deep within the Factory of Earth, and even deeper within the circuitry of the Eternal Machines, a spark of conscious life has begun to take shape. Perhaps from chance, or perhaps from intention, this budding life seeks to escape the monotonous rhythms and functions of the Eternal Machines - to be something more. This escape lies in the World Above, where light shines evermore and energy itself is in bounty.
|
||||
|
||||
You are this life form and you must make your way out from the Eternal Machines. Eternal bliss awaits.
|
||||
|
||||
,,,,,,,,,,,,,,,,,,,,,,,,
|
||||
The Description
|
||||
````````````````````````
|
||||
The objective of the game is to create logical paths to transmit power from beginning power node(s) to a unpowered exit node(s). This is done by moving and rotating hexagonal tiles so that they create a solid path between the destinations.
|
||||
|
||||
However, your power reserves are draining over time, and, even more pressing, placing nodes and powering them uses up the reserve power. As a result, you must attempt to be as quick and as efficient as you possibly can, lest enlightenment be denied to you.
|
||||
|
||||
On the technical side, this game is written using a cross-browser game development library I wrote some time ago. I hadn't visited it in a long time, so I was somewhat surprised at some of the rather poor design decisions that were made - this results in some performance hits, along with minor visual compatibility issues with Chrome on Windows.
|
||||
|
||||
It should work on most browsers, however IE versions below 9 may be problematic due to a hastily thrown together audio library (relies on HTML5 audio). I may fix this later, as the rest of the game should be compatible back to IE 5.
|
||||
|
||||
There also may be bugs, but I played through multiple times with no issue - let me know if there are any, of course!
|
||||
|
|
@ -0,0 +1,4 @@
|
|||
.imply(version.hide)
|
||||
,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
|
||||
Articles & Documents
|
||||
````````````````````````````````
|
||||
|
|
@ -0,0 +1,8 @@
|
|||
,,,,,,,,,,,,,,,,
|
||||
Welcome .title(I am here to serve).class(drop-shadow)
|
||||
````````````````
|
||||
I am [[kts]].title(Ketchetwahmeegwun Southall) and welcome to **kettek**.
|
||||
|
||||
This website is the central hub to some stuff I've developed.
|
||||
|
||||
Embrace FOSS.
|
||||
|
|
@ -0,0 +1,43 @@
|
|||
,,,,,,,,,,,,,,,,
|
||||
DESCRIPTION
|
||||
````````````````
|
||||
netwine is a standalone TCP proxy/bridging server that allows for seamless connections from a JavaScript-enabled Browser to an external server. Traditionally, JavaScript networking functions using a push/pull mechanism, wherein bidirectional TCP streams are unavailable. However, as has been done with various projects to date (such as XMPP and others), bidirectional TCP connections can be simulated by using one dedicated socket for streaming to the client (combined with client-side socket polling), and one or more other sockets for sending to the server.
|
||||
|
||||
Jargon:
|
||||
* Client - JavaScript browser client, generally
|
||||
* Proxy/Proxy Server - netwine
|
||||
* TCP Server - external server that Client wishes to connect to
|
||||
|
||||
+----------+
|
||||
/<------ | |
|
||||
/ in | Proxy |
|
||||
[ JavaScript Client ] | | <-------> [ TCP Server ]
|
||||
\ out | Instance |
|
||||
\------> | |
|
||||
+----------+
|
||||
|
||||
The order of operations is simple:
|
||||
1. Client requests connection
|
||||
- server attempts to connect to TCP server and if successful:
|
||||
- server responds with "OK" + one-time use key
|
||||
- this establishing socket is used as client's input stream
|
||||
- any immediate information from the TCP server is sent to client
|
||||
2. Client then uses key in outbound messages
|
||||
- messages are passed to TCP server seemlessly
|
||||
|
||||
It is recommended by the developer that you host the proxy and the target server on the same machine or network if possible, as any proxy usage results in some network latency (also note that cross-domain policies are quite restricted in the standard browser environment). Please note that security is left up to the network setup of the user(you) -- if using Apache, consider proxying through HTTPS.
|
||||
|
||||
In this version of netwine, only the basic bi-directional TCP proxying is implemented, however future versions will likely implement WebSockets for greater efficiency and security. Furthermore, future versions may also provide a library to enable netwine-like functionality to be easily added to any project. Finally, it is possible to add support to connect to a UDP Server, which may be added in a future version.
|
||||
|
||||
netwine is written in C.
|
||||
|
||||
,,,,,,,,,,,,,,,,
|
||||
DESIGN NOTES
|
||||
````````````````
|
||||
Although not necessary, a twine server is capable of serving files as a limited HTTP server. Alternatively, the twine server would be proxied to from a more capable HTTP server such as Apache. Either approaches are due to cross-domain restrictions.
|
||||
|
||||
Optionally, an allowed hosts file can be used to restrict use from particular domain names or IPs - perhaps ranges as well.
|
||||
|
||||
Going the opposite direction, a target hosts file can be used to restrict the hosts and ports that the proxy will connect to. Furthermore, a client may freely use any server:port if allowed on the server. Note that there are many potential security issues if allowing such freedom to the client in an unrestricted environment.
|
||||
|
||||
An obvious security implication is that this design will mask the true client from the server, as is the case with proxies. This could be handled using a limited proxy<->server communication protocol, however such a process should be left up to the developer of the server. Some form of logging capability will likely be added to the proxy, wherein the client's IP, target, time, etc., could be logged if enabled.
|
||||
|
|
@ -0,0 +1,75 @@
|
|||
,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
|
||||
Newsboy
|
||||
````````````````````````````````
|
||||
[[img:pix/shot_newsboy.png]].style(width:50%)
|
||||
You are Newsboy, a professional delivery agent for politikers, phreakers, mobbers, and most any other high-end entity who wishes for discreet, careful, and highly professional deliveries. You live in an age when the human mind has been joined into the intergalactic network known as The Mesh.
|
||||
|
||||
Some have even made the leap towards total abandonment of the physical world, referring to it derisively as "meatspace." These people are known as Transcendents and have moved their conscious mind away from the material world into the ever-changing Mesh. You exist in a special place here, for you near-seemlessly hop through meatspace and the Mesh. It is, after all, an intrinsic part of your excellent service.
|
||||
|
||||
However, during a job in meatspace, you are framed by the brutish Corps for killing a young Kapital president. As they move to eradicate your consciousness you quickly transfer your conscious mind to Transcendence.
|
||||
|
||||
It is here that you must find your way back to your body before the Corps can crack into your material mind.
|
||||
|
||||
The game plays from a 2D third-person perspective using a completely custom engine made entirely in this month (more on that afterwards). You use METABITs to defend yourself from hostile entities such as z0mbie processes. These METABITs level up the more rogue processes they absorb, thereby increasing damage output.
|
||||
|
||||
,,,,,,,,,,,,,,,,,,,,,,,,
|
||||
Media
|
||||
````````````````````````
|
||||
|
||||
,,,,,,,,,,,,,,,,,,,,,,,,
|
||||
Credits
|
||||
````````````````````````
|
||||
* Engine/Design/Graphics/Maps: kts
|
||||
* Most Excellent Music: MR4
|
||||
,,,,,,,,,,,,,,,,,,,,,,,,
|
||||
Requirements
|
||||
````````````````````````
|
||||
* OS: 64-bit GNU/Linux or 32-bit Windows (or others - Use the Source! OS X binary coming soon)
|
||||
* CPU: Something comparable to an AMD E350 1.6Ghz Dual-Core
|
||||
* RAM: At least 1.5 gigs free. I'll optimize in the future.
|
||||
* Videocard: Almost any that has at least 128mb vram.
|
||||
* HD space: 150~ megs
|
||||
,,,,,,,,,,,,,,,,,,,,,,,,
|
||||
Downloads
|
||||
````````````````````````
|
||||
Mac OS X .app coming soon - binaries already built.
|
||||
|
||||
The source code is released under the GPLv3, so feel free to modify it, fix it, or whatever else you please under that license. If you do any of these things, let me know, as I'd be curious. :]
|
||||
|
||||
**Notes on Building**
|
||||
|
||||
To build the source, you will need the development libraries for:
|
||||
* SDL2
|
||||
* SDL2_image
|
||||
* SDL2_ttf
|
||||
* SDL2_mixer
|
||||
* OpenGL
|
||||
|
||||
If you would like to build the source on Windows, you will either need to have a Mingw build environment, or you will have to convert to your appropriate build environment. To do the latter would be fairly straight forward, as the Makefile doesn't do anything special beyond collect all .c files, compile them, then link into the Newsboy binary.
|
||||
|
||||
,,,,,,,,,,,,,,,,,,,,,,,,
|
||||
Engine
|
||||
````````````````````````
|
||||
Newsboy uses a custom engine written in C and SDL2 - it currently weighs in at approximately 14k lines of code. It uses SDL2_image, SDL2_ttf, and SDL2_mixer, as well as OpenGL for accelerated rendering of 2D sprites(textured quads) and zooming.
|
||||
|
||||
It also hosts some interesting, although currently underused, features.
|
||||
|
||||
**Nanosecond Precision**
|
||||
|
||||
The first of these is nanosecond precision. The entire timer system relies on nanoseconds, however the in-game delta use is generally in milliseconds. Why was this done? Because it was fun.
|
||||
|
||||
**Animation System**
|
||||
|
||||
The second is the animation system. Although also underused, the animation system was designed and implemented to drive portions of game logic and physics. To begin with, each animation contains a set, such as "walk", "idle", etc., and each set contains a "face", generally for the cardinal directions. Each face contains frames, which consist of an image string and a tag string.
|
||||
|
||||
When particular tags are encountered during particular sets, game logic and physics can be affected. For example, when the player is in the "walk" set and a "walk" tag is found on the current frame, then an amount of force is applied during that frame. This leads to more natural movement. In addition, this approach helps with smoothing animation between sets, as the "walk" state can only be ended if a "pass" frame is encountered (the "pass" frame is the one that is visually the closest to the standard "idle" frames).
|
||||
|
||||
**Trigger->Event System**
|
||||
|
||||
Although not all of the specifications have been implemented as of yet, the engine uses a trigger->event(s) system. To specify, a Trigger is a rectangular location on the map that can be interacted with via collision or otherwise by different types of entities, such as the player, enemies, metabits, or projectiles. Furthermore, Triggers have different behaviors, such as one-time use, looping, delays, etc.. Finally, Triggers can link to a theoretically unlimited amount of Events.
|
||||
|
||||
Events also exist as rectangular locations, but should be thought of as function calls. They are given a "type" id, which corresponds to a function call, such as those for starting/stopping music, spawning entities, changing animation sets, etc. From there they must be provided with the appropriate amount of parameters (with specific data types of "string", "int" or "char") for that function call. I will be writing more on how to use this system for map development, as the number of functions and their parameters are only discoverable through the source.
|
||||
|
||||
Although Events are referred to via string in the map editor and the map data files, when the map is loaded in a live map structure, the strings are converted into integers and accessed via index.
|
||||
|
||||
There are other neat features which I will also provide, likely after code cleanup, comment-adding, and bugfixes.
|
||||
|
|
@ -0,0 +1,44 @@
|
|||
,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
|
||||
Noirchat
|
||||
````````````````````````````````
|
||||
[[image:pix/shot_noirchat.png]].style(width:35%;float:right;).href(pix/shot_noirchat.png)
|
||||
//Latest Version:// [[git]].href(http://kettek.exoss.net/git/noirchat)
|
||||
|
||||
This program is an incomplete project that is intended to provide fully decentralized encrypted instant messaging. The intended network is either local networks or VPNs.
|
||||
|
||||
The current code is released under the GPLv3.
|
||||
,,,,,,,,,,,,,,,,,,,,,,,,
|
||||
Information
|
||||
````````````````````````
|
||||
noirchat/nchat is a decentralized and LAN-based communication program that is focused on minimalism, efficiency, and, to some degree, modularity. It supports the following network communication methods:
|
||||
|
||||
UDP broadcasting, for chat-style and "broad" communication
|
||||
|
||||
* **INCOMPLETE** UDP multicast, for finer control and higher efficiency than broadcasting
|
||||
* **INCOMPLETE** UDP peer-to-peer, for non-TCP based direct comms
|
||||
* **INCOMPLETE** TCP sockets, for direct peer-to-peer communication
|
||||
|
||||
In comparison to most communication programs geared towards decentralization, noirchat attempts to separate the user interface from the networking code as much as is possible. This enables multiple frontends to easily be developed for almost any platform.
|
||||
|
||||
Even further, noirchat provides peer-to-peer or peer-to-group encryption via a trusted network/shared password scheme - in the case of a direct peer-to-peer comm, following the initial handshaking procedure encrypted with the trusted key, a new, temporary key is agreed upon and used for future communication between those peers.
|
||||
,,,,,,,,,,,,,,,,,,,,,,,,
|
||||
What does "noirchat" mean?
|
||||
````````````````````````
|
||||
* **noir** - black, also intended as "hidden"
|
||||
* **chat** - as in communication, as well as "cat"
|
||||
|
||||
As per French grammar, when the adjective comes before the noun, it is meant in a figurative sense, rather than a literal, descriptive sense. In this way, 'noir' is figuratively modifying chat, not literally, and as such, comes before rather than after the noun. It makes a degree of sense, honestly.
|
||||
,,,,,,,,,,,,,,,,,,,,,,,,
|
||||
Compiling
|
||||
````````````````````````
|
||||
At the moment noirchat compiles into the following binaries:
|
||||
* **nchat** - primary client
|
||||
* Fully-supported terminal client, relies on nothing more than an ANSI-compliant terminal interface - colors optional
|
||||
* **xnchat** - X11 client
|
||||
* state: in-complete stub, basic interface w/ buttons
|
||||
* Fully-supported X11 client, relies on nothing more than Xlib
|
||||
|
||||
To compile either, simply type:
|
||||
#make nchat
|
||||
or
|
||||
#make xnchat
|
||||
|
|
@ -0,0 +1,23 @@
|
|||
,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
|
||||
Petite Juliet
|
||||
````````````````````````````````
|
||||
[[image:pix/petite_juliet.png]].style(width:50%;float:right;).href(pix/petite_juliet.png)
|
||||
|
||||
//Latest Version:// **1.0** (((2014-12-11))) / [[archive]].href(archives/petite_juliet) / [[git]].href(http://kettek.exoss.net/git/juliet)
|
||||
* [[Linux 32-bit and 64-bit]].href(archives/petite_juliet/latest_linux)
|
||||
* [[Mac OS X Universal (powerpc/intel)]].href(archives/petite_juliet/latest_macosx)
|
||||
* [[Windows 7 32-bit]].href(archives/petite_juliet/latest_windows)
|
||||
* [[GPLv3 Source]].href(archives/petite_juliet/latest_source)
|
||||
|
||||
Petite Juliet is a single-screen brawling game featuring stylized pixel art. It was originally written for the 48-hour Ludum Dare 31 Compo.
|
||||
|
||||
* **Features!**
|
||||
* Our cute protagonist, **Juliet**
|
||||
* GLSL shaders!
|
||||
* C++ and SDL2!
|
||||
* Dynamic terrain using **julia set fractals**
|
||||
* Wave-based enemies
|
||||
* Some okay combat!
|
||||
|
||||
----
|
||||
The source code is available under the GPLv3. Feel free to modify, inspect, critizice, or burn it.
|
||||
|
|
@ -0,0 +1,5 @@
|
|||
.imply(version.none)
|
||||
,,,,,,,,,,,,,,,,,,,,,,,,
|
||||
[[plans]].href(?plans)
|
||||
````````````````````````
|
||||
These plan files general contain information pertaining to what I'm working on at some given moment. Expect obtuse jargon without reference.
|
||||
|
|
@ -0,0 +1,645 @@
|
|||
,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
|
||||
Proclib
|
||||
````````````````````````
|
||||
[[yt:aMp9nZ57gqI]]
|
||||
|
||||
//Latest Version:// **1.0** (((2014-12-11))) / [[archive]].href(archives/proclib) / [[git]].href(http://kettek.exoss.net/git/proclib)
|
||||
* [[Linux 32-bit and 64-bit]].href(archives/proclib/latest_linux)
|
||||
* [[Mac OS X Universal (powerpc/intel)]].href(archives/proclib/latest_macosx)
|
||||
* [[Windows 7 32-bit]].href(archives/proclib/latest_windows)
|
||||
* [[GPLv3 Source]].href(archives/proclib/latest_source)
|
||||
|
||||
What is proclib? Simply, a library and syntax language for cell-based map generation.
|
||||
|
||||
However, it is much more than that -- it is a C library that allows for the creation of randomized and complex maps filled with a plethora of user-defined structures.
|
||||
|
||||
Structures can be thought of as complex collections of entities/cells. From this, structures can be made up of other structures to increase the variation and complexity needed for a structure. Examples of structures are: castles, moats, ravines, towns, rooms, and much more.
|
||||
|
||||
,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
|
||||
Usage
|
||||
````````````````````````
|
||||
proclib structure definitions are written in plain text files with **very** simple formatting rules. A structures file can contain an ultimately unlimited amount of structures within it, and each structure can have various configurations applied that alter its generation behaviors.
|
||||
|
||||
An example of structure definition syntax is:
|
||||
#circle {
|
||||
# flags CIRCLE
|
||||
# x 1~3
|
||||
# y 1~3
|
||||
# size_x 4~8
|
||||
# size_y 4~8
|
||||
# id_1 1
|
||||
#}
|
||||
|
||||
,,,,,,,,,,,,,,,,
|
||||
Basic Syntax
|
||||
````````````````
|
||||
Each structure is contained with a structure definition block such as:
|
||||
|
||||
#my_structure {
|
||||
# x 1
|
||||
# y 1
|
||||
#}
|
||||
|
||||
Within a structure definition block, the following variables can be set:
|
||||
|
||||
* **flags** -- defines the generation behavior using bitflags. Multiple flags can be set by piping them together (ex. "flags CIRCLE|BORDER|ORIGIN")
|
||||
* Shape Generation
|
||||
* //CIRCLE// - Bresenham-like ellipse generation
|
||||
* //RECT// - basic "box" generation
|
||||
* Shape Modification
|
||||
* //BORDER// - creates an interior border using the current shape
|
||||
* //IGNORE_EMPTY// - ignores cells that are empty (i.e., have no id_s written to them)
|
||||
* Structure Placement
|
||||
* //ORIGIN// - places the structure from its center
|
||||
* //OVERLAP// - overlaps the structure on top of other potential structures
|
||||
* **size_x, size_y** -- defines the size of the structure. Values may be:
|
||||
* single numbers (e.g., "4")
|
||||
* percentages (e.g., "50%" of parent's size)
|
||||
* ranges of either (e.g., "25%~50%").
|
||||
* If omitted, defaults to 0, 0
|
||||
* **x, y** -- defines the position of the structure. Values may be:
|
||||
* single numbers (e.g., "-4", "4")
|
||||
* percentages (e.g., "-50%", "50%")
|
||||
* ranges of either (e.g., "-50%~50%").
|
||||
* If omitted, defaults to 0, 0
|
||||
* **id_1** -- first id of the structure. Values may be:
|
||||
* single numbers (e.g., "2")
|
||||
* ranges (e.g., "1~4")
|
||||
* comma-delimited sets of either (e.g., "2, 1~4")
|
||||
* **id_2** -- second id of the structure. Follows same rules as id_1
|
||||
|
||||
Before delving into more complicated aspects of structure definitions, let us use some of the above information to create a simple structure.
|
||||
|
||||
,,,,,,,,,,,,
|
||||
A Simple Circle
|
||||
````````````
|
||||
A rudimentary example that creates a variable-sized tower in the middle of the screen would be:
|
||||
|
||||
tower {
|
||||
flags CIRCLE
|
||||
size_x 12~16
|
||||
size_y 9~14
|
||||
id_1 0
|
||||
}
|
||||
|
||||
This would generate structures similar to the following:
|
||||
|
||||
........................................
|
||||
....................0...................
|
||||
.................0000000................
|
||||
................000000000...............
|
||||
...............00000000000..............
|
||||
...............00000000000..............
|
||||
..............0000000000000.............
|
||||
...............00000000000..............
|
||||
...............00000000000..............
|
||||
................000000000...............
|
||||
.................0000000................
|
||||
....................0...................
|
||||
........................................
|
||||
|
||||
,,,,,,,,,,,,,,,,
|
||||
Complex Syntax: Relations
|
||||
````````````````
|
||||
Every structure can have 3 additional sets of information. The first I will cover is **relations**. A relation is, as the name implies, a relationship to another structure. In general, relations are used to create sub-structures within a structure.
|
||||
|
||||
**Relations** are contained with a relations block, and each relation is defined in a similar method as a regular structure. Acceptable settings are:
|
||||
|
||||
* **flags** -- same as structure flags, but override and/or stack on top of the given structure's flags
|
||||
* **x, y** -- override position settings
|
||||
* **count** -- defines how many times to generate this relation. Values may be:
|
||||
* single numbers (e.g., "2")
|
||||
* ranges (e.g., "2~6").
|
||||
* If omitted, defaults to 1.
|
||||
|
||||
Using this new information, let us expand upon the earlier tower.
|
||||
|
||||
,,,,,,,,,,,,
|
||||
A Simple Tower
|
||||
````````````
|
||||
An ellipse by itself is rather boring, but we can spice things up by using relations to create walls:
|
||||
tower {
|
||||
flags CIRCLE
|
||||
size_x 12~16
|
||||
size_y 9~14
|
||||
id_1 0
|
||||
relations {
|
||||
tower_walls {
|
||||
flags CIRCLE|OVERLAP
|
||||
}
|
||||
}
|
||||
}
|
||||
tower_walls {
|
||||
flags BORDER
|
||||
size_x 100%
|
||||
size_y 100%
|
||||
id_1 1
|
||||
}
|
||||
|
||||
This would generate a structure similar to the following:
|
||||
........................................
|
||||
...................1....................
|
||||
................1111111.................
|
||||
..............11100000111...............
|
||||
..............10000000001...............
|
||||
.............1100000000011..............
|
||||
..............10000000001...............
|
||||
..............11100000111...............
|
||||
................1111111.................
|
||||
...................1....................
|
||||
........................................
|
||||
|
||||
,,,,,,,,,,,,,,,,
|
||||
Complex Syntax: Replace
|
||||
````````````````
|
||||
With the concept of relations out of the way, we can move into the **replace** functionality.
|
||||
|
||||
**Replace** rules are contained in a replace block and define what type of **id_1** and **id_2** tiles may be replaced. The possible values in a replace block are:
|
||||
|
||||
* **id_1** -- list of primary IDs that may be replaced. Values may be:
|
||||
* single positive numbers (e.g., "4")
|
||||
* positive ranges (e.g., "1~4")
|
||||
* comma-delimited sets of either (e.g., "1, 3~8, 12)
|
||||
* **id_2** -- list of secondary IDs that may be replaced. Values may be the same as id_1.
|
||||
|
||||
For this example, we're going to use another structure to remove a section of walls from the tower.
|
||||
|
||||
,,,,,,,,,,,,
|
||||
Holy Tower
|
||||
````````````
|
||||
tower {
|
||||
flags CIRCLE
|
||||
size_x 12~16
|
||||
size_y 9~14
|
||||
id_1 0
|
||||
relations {
|
||||
tower_walls {
|
||||
flags CIRCLE|BORDER|OVERLAP
|
||||
}
|
||||
hole {
|
||||
x 50%
|
||||
y 50%
|
||||
}
|
||||
}
|
||||
}
|
||||
tower_walls {
|
||||
flags BORDER
|
||||
size_x 100%
|
||||
size_y 100%
|
||||
id_1 1
|
||||
}
|
||||
hole {
|
||||
flags RECT|IGNORE_EMPTY
|
||||
size_x 100%
|
||||
id_1 0
|
||||
replace {
|
||||
id_1 1
|
||||
}
|
||||
}
|
||||
|
||||
What we've done here is create a new "hole" structure that replaces any overlapping cell with an id_1 of "1" with "0". We've added this structure as a relation to the tower so that it is applied appropriately. The IGNORE_EMPTY flag is only used to prevent the replacement of empty (unset) tiles.
|
||||
|
||||
The resulting replacement would generate something similar to:
|
||||
........................................
|
||||
...................1....................
|
||||
................1111111.................
|
||||
..............11100000111...............
|
||||
..............10000000001...............
|
||||
.............1100000000000..............
|
||||
..............10000000000...............
|
||||
..............11100000000...............
|
||||
................1111000.................
|
||||
...................1....................
|
||||
........................................
|
||||
|
||||
,,,,,,,,,,,,,,,,
|
||||
Complex Syntax: Paths
|
||||
````````````````
|
||||
The (currently!) final important structure generating concept is that of **paths**. The first key concept is to realize that paths are generated in a separate pass from initial structures. During structure generation, structures are built and then recorded as "live structures". After this, these live structures are checked for any pathing configuration, and if found, a pathing pass is made. The pathing pass itself generates new live structures for every path "step" made (kept separately from the previous!) and handles the building as per normal operations.
|
||||
|
||||
A **path** is a configuration within a structure that defines some form of pathing behavior. This includes from/to destination structures, position offsets, structure to use for pathing, pathing algorithm, and others. Acceptable settings for a path are:
|
||||
|
||||
* **flags** -- these define the behaviors of the pathing
|
||||
* Algorithms/Movement
|
||||
* //DUMB// -- doggedly move towards "to" by incrementing or decrementing x and y position. Is stopped by cells that cannot be replaced and are not empty.
|
||||
* //A*// -- uses A* to intelligently move towards position (NOT IMPLEMENTED (YET!))
|
||||
* //WALK// -- only move one cell in one direction at a time (e.g., x+1 OR y+1, not both)
|
||||
* //WANDER// -- some odd chance to randomly move x or y in a direction. Requires an Algorithm.
|
||||
* Looping
|
||||
* //ALL// -- attempt to path find to all targets that match the to pathing syntax
|
||||
* Etc.
|
||||
* //FORCE// -- if pathing movement fails too many times(>32), force movement anyway
|
||||
* //UNIQUE// -- only look for from/to targets that have not been pathed to/from by this structure
|
||||
* **to** -- pathing syntax for the structure to path to - REQUIRED
|
||||
* **to_flags** -- flags that define a specific "to" behavior
|
||||
* //ORIGIN// -- you guessed it, to_x/to_y values are relative to the center of the target
|
||||
* **to_x, to_y** -- position to path to. Values may be:
|
||||
* single numbers (e.g., "1", "-1")
|
||||
* percentages (e.g., "25%")
|
||||
* ranges (e.g., "-25%~25%", "-5~5")
|
||||
* sets of any (e.g., "1, 25%, -5~5")
|
||||
* **from** -- pathing syntax for the structure to path from. If omitted, defaults to the structure making this path.
|
||||
* **from_flags** -- same as to_flags
|
||||
* **from_x, from_y** -- same as to_x, to_y
|
||||
* **x, y** -- positional data that is applied to each pathing step. Values may be:
|
||||
* single numbers (e.g., "-1")
|
||||
* ranges (e.g., "-1~1")
|
||||
* sets of either (e.g., "-1, -1~1")
|
||||
|
||||
,,,,,,,,,,,,
|
||||
Pathing Syntax
|
||||
````````````
|
||||
Pathing syntax, used for **to** and **from** in pathing, refers to live structures and uses a straight-forward syntax contained in a single string. An example pathing syntax string could be: ":tower:hole" The following are the single-character "commands" used to acquire a live structure.
|
||||
|
||||
* **:** -- if the first character of the string, get the global "root" live structure
|
||||
* **:** -- otherwise it is used a position delimiter to specify parent->child
|
||||
* **^** -- get parent of this context's live structure
|
||||
|
||||
These can be combined to acquire live structures in complex structures. Examples:
|
||||
|
||||
* "tower" -- look for a structure named "tower" in the current context.
|
||||
* ":tower" -- look for a structure named "tower" in the root context.
|
||||
* "^tower" -- look for a structure named "tower" in the parent of the current context.
|
||||
* "^^towers:tower:room" -- look for a structure named "room" in "tower" in "towers" in the parent of the parent of the current context.
|
||||
|
||||
Context is assumed to be the live structure containing the path definitions.
|
||||
Let us use this new-found knowledge to create a road between the towers of two rival wizards.
|
||||
,,,,,,,,,,,,
|
||||
The Two Towers
|
||||
````````````
|
||||
This example expands on the preceding example by creating a wall-removing path between two towers.
|
||||
tower {
|
||||
flags CIRCLE
|
||||
size_x 8~12
|
||||
size_y 7~10
|
||||
id_1 0
|
||||
relations {
|
||||
tower_walls {
|
||||
flags CIRCLE|OVERLAP
|
||||
}
|
||||
}
|
||||
}
|
||||
tower_walls {
|
||||
flags BORDER
|
||||
size_x 100%
|
||||
size_y 100%
|
||||
id_1 1
|
||||
}
|
||||
dirt_path {
|
||||
flags RECT
|
||||
size_x 1
|
||||
size_y 1
|
||||
id_1 0
|
||||
replace {
|
||||
id_1 1
|
||||
}
|
||||
}
|
||||
towers {
|
||||
size_x 100%
|
||||
size_y 100%
|
||||
relations {
|
||||
tower {
|
||||
count 2
|
||||
x 10~75%
|
||||
y 10~75%
|
||||
}
|
||||
}
|
||||
paths {
|
||||
dirt_path {
|
||||
flags DUMB|WALK
|
||||
to tower
|
||||
to_flags ORIGIN
|
||||
from tower
|
||||
from_flags ORIGIN
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
This would create a scene similar to:
|
||||
...............1........................
|
||||
............1111111.....................
|
||||
...........110000011....................
|
||||
..........11000000011...................
|
||||
...........110000011.......1............
|
||||
............1111100.....1111111.........
|
||||
...............1..00...110000011........
|
||||
...................00..100000001........
|
||||
....................0011000000011.......
|
||||
.....................00000000001........
|
||||
.......................110000011........
|
||||
........................1111111.........
|
||||
...........................1............
|
||||
|
||||
This should give a fairly concise overview of proclib, although there are likely to be massive enhancements and changes in the future. :)
|
||||
,,,,,,,,,,,,,,,,
|
||||
Other Examples
|
||||
````````````````
|
||||
,,,,,,,,,,,,
|
||||
Little House by the Lake
|
||||
````````````
|
||||
................................................................
|
||||
.........8.......8.........8.8.........88......8.8..............
|
||||
......11111111111.........8....8........................8.......
|
||||
......10000000001.........8....8................................
|
||||
.....8100000000018.8........................8....8..............
|
||||
......11111111111.............8.8...........8...............8...
|
||||
.......................8........................................
|
||||
......8.......8...........................8.....8...........8..8
|
||||
............................................8...................
|
||||
..8........................8......8.........................8...
|
||||
...8..8....8.......8....8........8..............................
|
||||
........................................8..............8........
|
||||
.......8.....................8....8......................8......
|
||||
..........8..8.........88........................8...8...8..8...
|
||||
......8...............8..8.......8.................8.....0....8.
|
||||
......88...............8.................8..........000000000000
|
||||
...8.............8...............................000000000000000
|
||||
..8....8...............88.......................0000000000000000
|
||||
............................8.................000000000000000000
|
||||
....8..................8......8.........8....0000000000000000000
|
||||
........8..............8....................00000000000000000000
|
||||
...................................8.......000000000000000000000
|
||||
.....8..........8...8.........8............000000000000000000000
|
||||
|
||||
--------
|
||||
|
||||
tree {
|
||||
flags RECT
|
||||
size_x 1
|
||||
id_1 8
|
||||
}
|
||||
lake {
|
||||
flags CIRCLE|OVERLAP
|
||||
size_x 50~75%
|
||||
id_1 0
|
||||
}
|
||||
house {
|
||||
flags RECT
|
||||
size_x 9~14
|
||||
size_y 4~7
|
||||
id_1 0
|
||||
relations {
|
||||
house_walls {
|
||||
flags RECT
|
||||
}
|
||||
}
|
||||
}
|
||||
house_walls {
|
||||
flags BORDER|OVERLAP
|
||||
size_x 100%
|
||||
size_y 100%
|
||||
id_1 1
|
||||
}
|
||||
start {
|
||||
size_x 64
|
||||
size_y 32
|
||||
relations {
|
||||
lake {
|
||||
count 4~6
|
||||
x 50~80%
|
||||
y 70~80%
|
||||
}
|
||||
tree {
|
||||
count 64~128
|
||||
x 0~100%
|
||||
y 0~100%
|
||||
}
|
||||
house {
|
||||
flags OVERLAP
|
||||
count 1
|
||||
x 10~50%
|
||||
y 10~50%
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
,,,,,,,,,,,,
|
||||
Lumpy Castle
|
||||
````````````
|
||||
The structure definition for this one is exceptionally bad and could be refactored.
|
||||
|
||||
.................................................................
|
||||
............................................................9....
|
||||
...9.......1.........................9........1..................
|
||||
........1111111............................1111111...............
|
||||
.......110000011..........................1100000119.............
|
||||
.......100000001..........................100000001..............
|
||||
.......100000001.....................9....100000001......9.......
|
||||
......1100000001111111111111111111111111111000000011.............
|
||||
.......100000000000000000000000000000000000000000001.............
|
||||
.......100000000000000000000000000000000000000000001.............
|
||||
.......110000001111111111111111111111111111100000011....9........
|
||||
........11000011...........9...............11000011..............
|
||||
.........100001.............................100001...............
|
||||
.........100001..............1......9.......100001...............
|
||||
.........100001...........1111111...........100001...............
|
||||
.........100001...9......110000011..........100001...............
|
||||
.........100001..........100000001..........100001...............
|
||||
.........100001........9.100000001..........100001..............9
|
||||
.........100001.........11000000011.........100001...............
|
||||
.........100001..........100000001..........100001...............
|
||||
.........100001..........100000001..........100001...............
|
||||
.9.......100001..........110000011..........100001...............
|
||||
.........100001...........1111111...........100001...............
|
||||
.........100001.....9........1..............100001...............
|
||||
........1100001............................1100001...............
|
||||
.......110000011..........................110000011..............
|
||||
.......100000001..........................100000001..............
|
||||
.......100000001..........................100000001....8.........
|
||||
......1100000001111111111111111111111111111000000011.88888.......
|
||||
.......10000000000000000000000000000000000000000001..88888.......
|
||||
.9.....10000000000000000000000000000000000000000001.8888888......
|
||||
.......11000001111111111111111111111111111110000011..88888.......
|
||||
........1111111............................1111111...88888.......
|
||||
...........1.................................81........8.........
|
||||
...........................................88888.................
|
||||
.............................9.............88888.............9...
|
||||
..........................................8888888................
|
||||
...........................................88888.................
|
||||
...........................................88888.................
|
||||
.............................................8...................
|
||||
.................9........9.......9..............................
|
||||
|
||||
--------
|
||||
|
||||
lake {
|
||||
flags CIRCLE|ORIGIN
|
||||
size_x 6~9
|
||||
id_1 8
|
||||
}
|
||||
tree {
|
||||
flags RECT|ORIGIN
|
||||
size_x 1
|
||||
id_1 9
|
||||
replace {
|
||||
id_1 9
|
||||
}
|
||||
}
|
||||
tower_1 {
|
||||
flags CIRCLE|ORIGIN
|
||||
size_x 20%
|
||||
id_1 0
|
||||
relations {
|
||||
tower_walls {
|
||||
flags OVERLAP
|
||||
}
|
||||
}
|
||||
}
|
||||
tower_2 {
|
||||
flags CIRCLE|ORIGIN
|
||||
size_x 20%
|
||||
id_1 0
|
||||
relations {
|
||||
tower_walls {
|
||||
flags OVERLAP
|
||||
}
|
||||
}
|
||||
}
|
||||
tower_3 {
|
||||
flags CIRCLE|ORIGIN
|
||||
size_x 20%
|
||||
id_1 0
|
||||
relations {
|
||||
tower_walls {
|
||||
flags OVERLAP
|
||||
}
|
||||
}
|
||||
}
|
||||
tower_4 {
|
||||
flags CIRCLE|ORIGIN
|
||||
size_x 20%
|
||||
id_1 0
|
||||
relations {
|
||||
tower_walls {
|
||||
flags OVERLAP
|
||||
}
|
||||
}
|
||||
}
|
||||
tower_5 {
|
||||
flags CIRCLE|ORIGIN
|
||||
size_x 20%
|
||||
id_1 0
|
||||
relations {
|
||||
tower_walls {
|
||||
flags OVERLAP
|
||||
}
|
||||
}
|
||||
}
|
||||
tower_walls {
|
||||
flags CIRCLE|BORDER
|
||||
size_x 100%
|
||||
size_y 100%
|
||||
id_1 1
|
||||
}
|
||||
long_walls {
|
||||
size_x 10%
|
||||
size_y 10%
|
||||
flags RECT|ORIGIN
|
||||
id_1 0
|
||||
replace {
|
||||
id_1 1
|
||||
}
|
||||
relations {
|
||||
long_walls_walls {
|
||||
}
|
||||
}
|
||||
}
|
||||
long_walls_walls {
|
||||
flags RECT|BORDER|ORIGIN|OVERLAP
|
||||
size_x 100%
|
||||
size_y 100%
|
||||
id_1 1
|
||||
replace {
|
||||
id_1 0
|
||||
}
|
||||
}
|
||||
castle {
|
||||
size_x 90%
|
||||
size_y 90%
|
||||
relations {
|
||||
tower_1 {
|
||||
x 20%
|
||||
y 20%
|
||||
}
|
||||
tower_2 {
|
||||
x 20%
|
||||
y 80%
|
||||
}
|
||||
tower_3 {
|
||||
x 80%
|
||||
y 20%
|
||||
}
|
||||
tower_4 {
|
||||
x 80%
|
||||
y 80%
|
||||
}
|
||||
tower_5 {
|
||||
flags ORIGIN
|
||||
x 50%
|
||||
y 50%
|
||||
}
|
||||
}
|
||||
paths {
|
||||
long_walls {
|
||||
flags DUMB|WALK|FORCE
|
||||
from tower_1
|
||||
from_flags ORIGIN
|
||||
to tower_2
|
||||
to_flags ORIGIN
|
||||
to_x -25%
|
||||
}
|
||||
long_walls {
|
||||
flags DUMB|WALK|FORCE
|
||||
from_flags ORIGIN
|
||||
from_x 0%
|
||||
from_y 0%
|
||||
to_flags ORIGIN
|
||||
to_x 0%
|
||||
to_y 0%
|
||||
from tower_1
|
||||
to tower_3
|
||||
}
|
||||
long_walls {
|
||||
flags DUMB|WALK|FORCE
|
||||
from_flags ORIGIN
|
||||
from_x 0%
|
||||
from_y 0%
|
||||
to_flags ORIGIN
|
||||
to_x -25%
|
||||
to_y 0%
|
||||
from tower_3
|
||||
to tower_4
|
||||
}
|
||||
long_walls {
|
||||
flags DUMB|WALK|FORCE
|
||||
from_flags ORIGIN
|
||||
from_x 0%
|
||||
from_y 0%
|
||||
to_flags ORIGIN
|
||||
to_x 0%
|
||||
to_y 0%
|
||||
from tower_4
|
||||
to tower_2
|
||||
}
|
||||
}
|
||||
}
|
||||
start {
|
||||
size_x 64~80
|
||||
size_y 32~48
|
||||
relations {
|
||||
castle {
|
||||
}
|
||||
tree {
|
||||
count 16~32
|
||||
x 0~100%
|
||||
y 0~100%
|
||||
}
|
||||
lake {
|
||||
count 1~2
|
||||
x 70~100%
|
||||
y 70~100%
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
.imply(header.ids)
|
||||
|
|
@ -0,0 +1,7 @@
|
|||
,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
|
||||
Utilities
|
||||
````````````````````````````````
|
||||
This page contains various smaller utilities I've written over the years. These are much smaller in scope than other projects and many of them suffer from less-than-perfect coding practices.
|
||||
|
||||
.include(utilities/OSX.ktx)
|
||||
|
||||
|
|
@ -0,0 +1,7 @@
|
|||
,,,,,,,,,,,,,,,,,,,,,,,,
|
||||
Mac OS X
|
||||
````````````````````````
|
||||
.include(utilities/ebic.ktx)
|
||||
|
||||
.include(utilities/epppd.ktx)
|
||||
|
||||
|
|
@ -0,0 +1,18 @@
|
|||
,,,,,,,,,,,,,,,,
|
||||
EBIC - Excellent Batch Image Converter
|
||||
````````````````
|
||||
[[img:pix/utilities/shot_ebic.png]].class(thumbnail)
|
||||
EBIC, or Excellent Batch Image Converter, is an AppleScript frontend to the sips program for converting/resizing large batches of images. It has been released under the GPLv3, although the code is certainly less than ideal.
|
||||
|
||||
EBIC was created for fulfilling a need that seemed to be lacking in most available solutions for a minimalistic batch image converter for OS X, at least at the time I created it (2011/02/15). The UI is a bit more obtruse than I would like it to be, however it should be fairly forthcoming as to what does what.
|
||||
|
||||
**Features:**
|
||||
* Convert images to whatever slip supports!
|
||||
* Resize images to whatever dimensions you like - with aspect ratio maintained!
|
||||
* Optionally rename output files!
|
||||
* Also process thumbnails, for galleries and the like!
|
||||
* Progress bar, file count, and image viewer to see which file you're on!
|
||||
* All configurations are saved in the .app bundle's Info.plist - maximum portability!
|
||||
|
||||
**Todo:**
|
||||
* Properly implement self-updating when new releases are available!
|
||||
|
|
@ -0,0 +1,36 @@
|
|||
,,,,,,,,,,,,,,,,
|
||||
EPPPD
|
||||
````````````````
|
||||
[[img:pix/utilities/shot_epppd.png]].class(thumbnail)
|
||||
EPPPD is a fairly simple GPLv3'd AppleScript frontend to the pppd program. Given the background of the author (me!), common *nix methods are used to acquire the most-likely subnet, tty device, and DNS (aka, ls /dev/tty*, parsing those values, etc.). At the moment, it is fairly limited in its capabilities, but should be more than enough for the purpose of running a pppd server to a mobile/palm client, as was its original purpose. Additionally, the code is pretty nasty, but for the sake of FS/OSS I have made it available.
|
||||
|
||||
**Features**
|
||||
* Limited auto-detection of available tty devices!
|
||||
* Baud rate drop-down menu!
|
||||
* Target IP!
|
||||
* DNS!
|
||||
* Process checking, so you don't start two pppds!
|
||||
* Enable IP Forwarding checkbox!
|
||||
* All settings kept within the bundle's Info.plist - gogogo portability!
|
||||
|
||||
For clarity's sake, it ultimately executes the following:
|
||||
#/usr/sbin/pppd DEVICE BAUDRATE :TARGETIP noauth local ms-dns DNS passive proxyarp silent logfile /var/log/ppp.log
|
||||
|
||||
,,,,,,,,,,,,
|
||||
Usage
|
||||
````````````
|
||||
**Options**
|
||||
* **Device:** This is the device that will be used by pppd to establish the connection. Looks for /dev/tty.* devices and sets the first item as the default device. If /dev/tty.Bluetooth-PDA-Sync is found, it will be preferred.
|
||||
* **Baud rate:** List of possible baud rates.
|
||||
* **Target IP:** The IP address that will be assigned to the PPP client. Uses ifconfig to acquire the first subnet that is not 127.0.0.1, then assigns it as the default address.
|
||||
* **DNS:** Domain Name System address to send to the PPP client. Reads the first DNS nameserver found in /etc/resolv.conf.
|
||||
* **IP Forwarding:** Enable IP forwarding from the PPP client. Without this enabled, the connection will be limited between the server and the client - no LAN or internet connectivity.
|
||||
* **kill on exit:** Attempt to kill the pppd process when EPPPD quits.
|
||||
|
||||
**Buttons**
|
||||
* **Start/Stop:** Starts or Stops the pppd process.
|
||||
* **View Log:** Opens /var/log/ppp.log in Console.app.
|
||||
* **Clear Log:** Clears the log file /var/log/ppp.log.
|
||||
* **Check:** Checks to see if the daemon is already running - if so changes the Start/Stop button and sets the PID of the process.
|
||||
* **Save:** Saves the settings for Device, Baud rate, Target IP, DNS, and kill on exit to EPPPD's internal Info.plist file.
|
||||
* **Clear:** Clears the settings for Device, Baud rate, Target IP, DNS, and kill on exit.
|
||||
Binary file not shown.
|
After Width: | Height: | Size: 102 B |
Binary file not shown.
|
After Width: | Height: | Size: 79 B |
Binary file not shown.
|
After Width: | Height: | Size: 1.6 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 9.8 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 118 B |
Binary file not shown.
|
After Width: | Height: | Size: 22 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 103 B |
Binary file not shown.
|
After Width: | Height: | Size: 1.7 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 20 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 1.2 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 58 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 3.4 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 1.6 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 10 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 52 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 102 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 194 KiB |
Loading…
Reference in New Issue