gaspersic/kubedoom
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Add efacf056cd

Browse Source
This commit is contained in:
David Zuber
2019-09-01 14:14:08 +01:00
parent 924ff5f5ef
commit 8e8907f48b
631 changed files with 202169 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

194
dockerdoom/trunk/psdoom/CHANGELOG Normal file
View File

@ -0,0 +1,194 @@
Changelog for psDooM:
Release 2012.02.05 - Migrate psDooM into Chocoloate Doom
-Merge 2000.05.03-2000.05.03b psDooM patches into Chocolate Doom 1.6.0
but reject branding, save file changes, xd-launch, versioning
from psDooM.
-Rebrand Chocolate Doom to psdoom
-Fix linux detection broken by 2000.05.03a. Solaris needs testing.
Release 2000.05.03.b - Changes since 2000.05.03.a
-Changed shell scripts in 'contrib' dir to shorten command length when
displayed with 'ps'.
-Use ~/.psdoom rather than ~/.xdoom for savegames, config files, etc.
Users need to copy current .doomrc and .xdlaunchrc files to ~/.psdoom.
-Added references to psDooM in startup header text, X resources, and
window title bar.
-Modified xdlaunch (ps-xdlaunch) to run ps-xdoom.
-Added ability to pass psDooM-specific command line flags to ps-xdoom
through ps-xdlaunch.
Release 2000.05.03.a - Changes since 2000.05.03
-Support for Solaris' version of 'ps'.
-Added command line flag that allows pid monsters to be damaged by
things other than the player. This is the original behavior of the
program. (-nopssafety)
Release 2000.05.03 - Changes since 2000.02.21
-Moved project to SourceForge. (http://psdoom.sourceforge.net/)
-Changed distribution format and file name:
psdoom-YYYY.MM.DD-patch.tar.gz == patch to apply to latest XDoom.
psdoom-YYYY.MM.DD-src.tar.gz == source of the entire psDooM tree.
psdoom-YYYY.MM.DD-bin.tar.gz == linux-x86 psDooM binaries.
psdoom-YYYY.MM.DD-data.tar.gz == custom ps-management levels for use
with registered Doom, Ultimate Doom, or Doom ][.
-Executibles are now called ps-*doom (ie. ps-sxdoom) rather than
*doom.ps (ie. sxdoom.ps).
-'make install-<platform>' now installs psDooM.
-Installs into /usr/local/games/psdoom/ rather than into XDoom's
/usr/local/games/xdoom/
-Created install script for binary distribution.
-Created some psDooM documentation and a directory for it (psdoomdoc).
-Based on the 20000305 release of XDoom.
-Added command line flag to entirely disable 'ps' portion of the
program. (-nopsmon)
-Added command line flag to disable actual re-nice and kill of processes
for program interface demonstration purposes. (-nopsact)
-Added command line flag to make 'no monsters' persistant across new
games and level warping. (-nomonsters.) == no monsters, period :-)
-Pid monster spawning is not affected by the '-nomonsters' or
'-nomonsters.' command line flags.
-Added command line flag to respawn items like in -altdeath games.
(-respawnitems) It has no effect when recording or playing a demo.
-Added command line flag to cause every username to be added to
the list of users whose processes to display. (-psallusers)
-Added command line flag to cause specified usernames to be added to the
list of users whose processes to display. Without any supplied
username(s), assume current user. (-psuser [username1[ username2...]])
-Added command line flag to cause specified usernames to be added to the
list of users whose processes not to display. Without any supplied
username(s), assume current user.
(-psnotuser [username1[ username2...]])
-If none of the userlist-related command line flags are given, the
program defaults to showing only the current user's processes if not
running the program as root. The root user sees all processes by
default. The current username is determined by looking at the
environment variables PSDOOMUSER, LOGNAME, USER, and USERNAME in that
order.
-Demo playing and recording on E1M1 or MAP01 bypass the 'ps' portion
of the program.
-Fixed a bug that caused trouble with the first automatic demo after
ending a game from the menu (Options -> End Game).
Release 2000.02.21 - Changes since 2000.02.01
-Save and restore is handled better now. Pid monsters are not saved
to file and are properly respawned upon level load.
-Moved more code around. Un-hid the call to cleanup_pid_list() within
the pr_check() routine. Now, all calls to pr_check() are immediately
followed by a call to cleanup_pid_list(). Also, pr_check() is not
called if leveltime == 0. That caused it to be called twice upon
level start: once for the level initialization and once for the first
gametick.
-Made custom levels for registered Doom 1, Ultimate Doom, and Doom 2.
*Any* level that has 3 1024x1024 areas for monster spawning such that
the bottom left coordinates of the squares are at (0,0); (2048,0); and
(4096,0), respectively, will work.
-The level loads automatically as the first map (either E1M1 or MAP01).
The custom Doom 1 map must be named psdoom1.wad and the custom Doom 2
map named psdoom2.wad for the automatic load to happen.
-Command line switch to suppress automatic loading of a custom process
management level. Manage processes on default E1M1 or MAP01.
(-nopslev)
-If you're playing Doom 1, Ultimate Doom, or Doom 2, but DON'T have the
custom level loaded, pid monsters are spawned in the courtyard on the
first level (either E1M1 or MAP01).
-If you're not playing on the first map, and/or you're using add-on
maps 'Plutonia Experiment' or 'TNT - Evilution', the 'ps' portion of
the program is not used.
-Pid monsters spawn at least one radius inside the edge of their
1024x1024 box on custom levels. This prevents them from spawning
in the 'void space' outside the custom level map.
Release 2000.02.01 - Changes since 2000.01.26
-Finished implementation of resurrecting pid monsters that died in
XDoom, but not on the machine. It does an archvile-type respawn on
the monster if possible, or removes the body and does a respawn
otherwise. This does NOT require the Doom ][ wad since we just use
the archvile's code; not its sprites.
-Fixed a bug that caused Doom to sometimes crash when it started a level
after pid monsters had been spawned. cleanup_pid_list() tried
operating on memory that may have changed during the load.
-Began handling save and restore gracefully. It's highly recommended
that you do *not* use save/restore yet.
Release 2000.01.26 - Changes since 2000.01.18
-Made the 'ps' call include the 'a' and 'x' flags to doublecheck
for *all* machine processes (all users/no terminal).
-Allowed the process manager itself to be spawned as a pid monster.
-Fixed pid monster kill % calculation. I broke it when I moved
pid-specific code from P_SpawnMapThing() to add_new_process().
-Advanced process management implemented:
If a process is killed/removed outside XDoom, it is removed from
XDoom.
Update process names on exec() call (same pid, different name).
(ie. mingetty --> -bash after login)
Framework is there for implementing resurrection of a pid monster
who's represented process didn't die on the machine (it trapped the
kill signal or user doesn't have permission to kill it).
-Pid monsters don't spawn in/on other things. Period. If a newly
spawned monster would collide with something else after all the
repositioning (below), it is not spawned. The next update of the
process list will try spawning again after whatever was blocking it
moved (hopefully).
Release 2000.01.18 - Changes since 2000.01.14
-Only call pr_renice() on the monster's first damage. Since subsequent
calls re-niced from +5 to +5, CPU cycles were being wasted.
-Pid monsters can only be damaged and killed by a player. They
still act as if they were damaged by targeting whatever hit them.
-Put back the pid monster variety now that they can't kill each
other off. (daemons spawn as demons, others spawn as sargents)
Release 2000.01.14 - Changes since 2000.01.04
-Moved pid-specific mobj initialization from P_SpawnMapThing() to
add_new_process(). This allows us to get rid of the pid-specific
enhancements to the mapthing_ext_t type, also.
-Better replacement code for mobj collisions in add_new_process().
Now, the monster is placed by altering its x,y by its radius and twice
its radius until it does not collide. Spawn at original location if
the alternate placements don't work out. Stupid ASCII art
representation:
y y y
x x x
y x X x y
x x x
y y y
(X is original location, x are tested first, then y are tested)
Release 2000.01.04 - Changes since 1999.12.29
-Do not draw the monster's pid info if the whole monster is blocked
(by anything: wall, floor, and/or ceiling).
-Draw the monster's pid info at the top of the monster's sprite rather
than in the center of the screen.
-Don't consider the pid monsters in the end-of-level total kill %.
-Pass the mobj back to add_new_process() for further operations on it.
-In add_new_process(), check the newly created mobj for collisions.
If it is colliding, try re-positioning it to the north, east,
west, and south by the mobj's radius, respectively, until no
collisions are found. Spawn at original location if the alternate
placements don't work out. Stupid ASCII art representation:
x
x X x
x
(X is original location, x are the tested locations)
Release 1999.12.29 - Changes since 0.01d
-Fixed a compiler warning about modifying a const variable.
-Fixed a bug in pr_poll() which prevented new processes from
being spawned.
-Temporarily made all pid monsters spawn as demons to prevent them
from killing each other off while trying to develop code.
-Moved the call to pr_renice() after the check to see if pr_kill()
should be called. After all, what's the point of re-nicing the
process if we're going to kill it anyway?
-Display the last 7 characters of the process name rather than the
first 7. ie: '/sbin/mingetty' would appear as 'ingetty' rather
than '/sbin/m'
-Do not draw the monster's pid info if the whole monster is blocked
by a wall or column that extends from floor to ceiling.
Release 0.01d - Changes since 0.01c (???)
-Added process names in addition to the pid numbers.
-Don't draw the monster's pid info if the monster is too far away.
-Don't draw the monster's pid info if the monster is too close to
the edge of the screen.

339
dockerdoom/trunk/psdoom/COPYING Normal file
View File

@ -0,0 +1,339 @@
GNU GENERAL PUBLIC LICENSE
Version 2, June 1991
Copyright (C) 1989, 1991 Free Software Foundation, Inc.
675 Mass Ave, Cambridge, MA 02139, USA
Everyone is permitted to copy and distribute verbatim copies
of this license document, but changing it is not allowed.
Preamble
The licenses for most software are designed to take away your
freedom to share and change it. By contrast, the GNU General Public
License is intended to guarantee your freedom to share and change free
software--to make sure the software is free for all its users. This
General Public License applies to most of the Free Software
Foundation's software and to any other program whose authors commit to
using it. (Some other Free Software Foundation software is covered by
the GNU Library General Public License instead.) You can apply it to
your programs, too.
When we speak of free software, we are referring to freedom, not
price. Our General Public Licenses are designed to make sure that you
have the freedom to distribute copies of free software (and charge for
this service if you wish), that you receive source code or can get it
if you want it, that you can change the software or use pieces of it
in new free programs; and that you know you can do these things.
To protect your rights, we need to make restrictions that forbid
anyone to deny you these rights or to ask you to surrender the rights.
These restrictions translate to certain responsibilities for you if you
distribute copies of the software, or if you modify it.
For example, if you distribute copies of such a program, whether
gratis or for a fee, you must give the recipients all the rights that
you have. You must make sure that they, too, receive or can get the
source code. And you must show them these terms so they know their
rights.
We protect your rights with two steps: (1) copyright the software, and
(2) offer you this license which gives you legal permission to copy,
distribute and/or modify the software.
Also, for each author's protection and ours, we want to make certain
that everyone understands that there is no warranty for this free
software. If the software is modified by someone else and passed on, we
want its recipients to know that what they have is not the original, so
that any problems introduced by others will not reflect on the original
authors' reputations.
Finally, any free program is threatened constantly by software
patents. We wish to avoid the danger that redistributors of a free
program will individually obtain patent licenses, in effect making the
program proprietary. To prevent this, we have made it clear that any
patent must be licensed for everyone's free use or not licensed at all.
The precise terms and conditions for copying, distribution and
modification follow.
GNU GENERAL PUBLIC LICENSE
TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION
0. This License applies to any program or other work which contains
a notice placed by the copyright holder saying it may be distributed
under the terms of this General Public License. The "Program", below,
refers to any such program or work, and a "work based on the Program"
means either the Program or any derivative work under copyright law:
that is to say, a work containing the Program or a portion of it,
either verbatim or with modifications and/or translated into another
language. (Hereinafter, translation is included without limitation in
the term "modification".) Each licensee is addressed as "you".
Activities other than copying, distribution and modification are not
covered by this License; they are outside its scope. The act of
running the Program is not restricted, and the output from the Program
is covered only if its contents constitute a work based on the
Program (independent of having been made by running the Program).
Whether that is true depends on what the Program does.
1. You may copy and distribute verbatim copies of the Program's
source code as you receive it, in any medium, provided that you
conspicuously and appropriately publish on each copy an appropriate
copyright notice and disclaimer of warranty; keep intact all the
notices that refer to this License and to the absence of any warranty;
and give any other recipients of the Program a copy of this License
along with the Program.
You may charge a fee for the physical act of transferring a copy, and
you may at your option offer warranty protection in exchange for a fee.
2. You may modify your copy or copies of the Program or any portion
of it, thus forming a work based on the Program, and copy and
distribute such modifications or work under the terms of Section 1
above, provided that you also meet all of these conditions:
a) You must cause the modified files to carry prominent notices
stating that you changed the files and the date of any change.
b) You must cause any work that you distribute or publish, that in
whole or in part contains or is derived from the Program or any
part thereof, to be licensed as a whole at no charge to all third
parties under the terms of this License.
c) If the modified program normally reads commands interactively
when run, you must cause it, when started running for such
interactive use in the most ordinary way, to print or display an
announcement including an appropriate copyright notice and a
notice that there is no warranty (or else, saying that you provide
a warranty) and that users may redistribute the program under
these conditions, and telling the user how to view a copy of this
License. (Exception: if the Program itself is interactive but
does not normally print such an announcement, your work based on
the Program is not required to print an announcement.)
These requirements apply to the modified work as a whole. If
identifiable sections of that work are not derived from the Program,
and can be reasonably considered independent and separate works in
themselves, then this License, and its terms, do not apply to those
sections when you distribute them as separate works. But when you
distribute the same sections as part of a whole which is a work based
on the Program, the distribution of the whole must be on the terms of
this License, whose permissions for other licensees extend to the
entire whole, and thus to each and every part regardless of who wrote it.
Thus, it is not the intent of this section to claim rights or contest
your rights to work written entirely by you; rather, the intent is to
exercise the right to control the distribution of derivative or
collective works based on the Program.
In addition, mere aggregation of another work not based on the Program
with the Program (or with a work based on the Program) on a volume of
a storage or distribution medium does not bring the other work under
the scope of this License.
3. You may copy and distribute the Program (or a work based on it,
under Section 2) in object code or executable form under the terms of
Sections 1 and 2 above provided that you also do one of the following:
a) Accompany it with the complete corresponding machine-readable
source code, which must be distributed under the terms of Sections
1 and 2 above on a medium customarily used for software interchange; or,
b) Accompany it with a written offer, valid for at least three
years, to give any third party, for a charge no more than your
cost of physically performing source distribution, a complete
machine-readable copy of the corresponding source code, to be
distributed under the terms of Sections 1 and 2 above on a medium
customarily used for software interchange; or,
c) Accompany it with the information you received as to the offer
to distribute corresponding source code. (This alternative is
allowed only for noncommercial distribution and only if you
received the program in object code or executable form with such
an offer, in accord with Subsection b above.)
The source code for a work means the preferred form of the work for
making modifications to it. For an executable work, complete source
code means all the source code for all modules it contains, plus any
associated interface definition files, plus the scripts used to
control compilation and installation of the executable. However, as a
special exception, the source code distributed need not include
anything that is normally distributed (in either source or binary
form) with the major components (compiler, kernel, and so on) of the
operating system on which the executable runs, unless that component
itself accompanies the executable.
If distribution of executable or object code is made by offering
access to copy from a designated place, then offering equivalent
access to copy the source code from the same place counts as
distribution of the source code, even though third parties are not
compelled to copy the source along with the object code.
4. You may not copy, modify, sublicense, or distribute the Program
except as expressly provided under this License. Any attempt
otherwise to copy, modify, sublicense or distribute the Program is
void, and will automatically terminate your rights under this License.
However, parties who have received copies, or rights, from you under
this License will not have their licenses terminated so long as such
parties remain in full compliance.
5. You are not required to accept this License, since you have not
signed it. However, nothing else grants you permission to modify or
distribute the Program or its derivative works. These actions are
prohibited by law if you do not accept this License. Therefore, by
modifying or distributing the Program (or any work based on the
Program), you indicate your acceptance of this License to do so, and
all its terms and conditions for copying, distributing or modifying
the Program or works based on it.
6. Each time you redistribute the Program (or any work based on the
Program), the recipient automatically receives a license from the
original licensor to copy, distribute or modify the Program subject to
these terms and conditions. You may not impose any further
restrictions on the recipients' exercise of the rights granted herein.
You are not responsible for enforcing compliance by third parties to
this License.
7. If, as a consequence of a court judgment or allegation of patent
infringement or for any other reason (not limited to patent issues),
conditions are imposed on you (whether by court order, agreement or
otherwise) that contradict the conditions of this License, they do not
excuse you from the conditions of this License. If you cannot
distribute so as to satisfy simultaneously your obligations under this
License and any other pertinent obligations, then as a consequence you
may not distribute the Program at all. For example, if a patent
license would not permit royalty-free redistribution of the Program by
all those who receive copies directly or indirectly through you, then
the only way you could satisfy both it and this License would be to
refrain entirely from distribution of the Program.
If any portion of this section is held invalid or unenforceable under
any particular circumstance, the balance of the section is intended to
apply and the section as a whole is intended to apply in other
circumstances.
It is not the purpose of this section to induce you to infringe any
patents or other property right claims or to contest validity of any
such claims; this section has the sole purpose of protecting the
integrity of the free software distribution system, which is
implemented by public license practices. Many people have made
generous contributions to the wide range of software distributed
through that system in reliance on consistent application of that
system; it is up to the author/donor to decide if he or she is willing
to distribute software through any other system and a licensee cannot
impose that choice.
This section is intended to make thoroughly clear what is believed to
be a consequence of the rest of this License.
8. If the distribution and/or use of the Program is restricted in
certain countries either by patents or by copyrighted interfaces, the
original copyright holder who places the Program under this License
may add an explicit geographical distribution limitation excluding
those countries, so that distribution is permitted only in or among
countries not thus excluded. In such case, this License incorporates
the limitation as if written in the body of this License.
9. The Free Software Foundation may publish revised and/or new versions
of the General Public License from time to time. Such new versions will
be similar in spirit to the present version, but may differ in detail to
address new problems or concerns.
Each version is given a distinguishing version number. If the Program
specifies a version number of this License which applies to it and "any
later version", you have the option of following the terms and conditions
either of that version or of any later version published by the Free
Software Foundation. If the Program does not specify a version number of
this License, you may choose any version ever published by the Free Software
Foundation.
10. If you wish to incorporate parts of the Program into other free
programs whose distribution conditions are different, write to the author
to ask for permission. For software which is copyrighted by the Free
Software Foundation, write to the Free Software Foundation; we sometimes
make exceptions for this. Our decision will be guided by the two goals
of preserving the free status of all derivatives of our free software and
of promoting the sharing and reuse of software generally.
NO WARRANTY
11. BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY
FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN
OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES
PROVIDE THE PROGRAM "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED
OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS
TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE
PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING,
REPAIR OR CORRECTION.
12. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING
WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY AND/OR
REDISTRIBUTE THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES,
INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING
OUT OF THE USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED
TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY
YOU OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER
PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE
POSSIBILITY OF SUCH DAMAGES.
END OF TERMS AND CONDITIONS
Appendix: How to Apply These Terms to Your New Programs
If you develop a new program, and you want it to be of the greatest
possible use to the public, the best way to achieve this is to make it
free software which everyone can redistribute and change under these terms.
To do so, attach the following notices to the program. It is safest
to attach them to the start of each source file to most effectively
convey the exclusion of warranty; and each file should have at least
the "copyright" line and a pointer to where the full notice is found.
<one line to give the program's name and a brief idea of what it does.>
Copyright (C) 19yy <name of author>
This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 2 of the License, or
(at your option) any later version.
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
You should have received a copy of the GNU General Public License
along with this program; if not, write to the Free Software
Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
Also add information on how to contact you by electronic and paper mail.
If the program is interactive, make it output a short notice like this
when it starts in an interactive mode:
Gnomovision version 69, Copyright (C) 19yy name of author
Gnomovision comes with ABSOLUTELY NO WARRANTY; for details type `show w'.
This is free software, and you are welcome to redistribute it
under certain conditions; type `show c' for details.
The hypothetical commands `show w' and `show c' should show the appropriate
parts of the General Public License. Of course, the commands you use may
be called something other than `show w' and `show c'; they could even be
mouse-clicks or menu items--whatever suits your program.
You should also get your employer (if you work as a programmer) or your
school, if any, to sign a "copyright disclaimer" for the program, if
necessary. Here is a sample; alter the names:
Yoyodyne, Inc., hereby disclaims all copyright interest in the program
`Gnomovision' (which makes passes at compilers) written by James Hacker.
<signature of Ty Coon>, 1 April 1989
Ty Coon, President of Vice
This General Public License does not permit incorporating your program into
proprietary programs. If your program is a subroutine library, you may
consider it more useful to permit linking proprietary applications with the
library. If this is what you want to do, use the GNU Library General
Public License instead of this License.

27
dockerdoom/trunk/psdoom/CREDITS Normal file
View File

@ -0,0 +1,27 @@
This list of credits for psDooM is in no particular order, save for id
Software coming first. I'll try to keep it more or less cronological.
id Software: http://www.idsoftware.com
--For writing Doom in the first place.
--For giving eager programmers the GPL'd source.
Udo Munk: um@compuserve.com
--For programming XDoom and maintaining it.
<Everyone listed in Udo's CREDITS file>
--For helping out with XDoom.
Dennis Chao: dlchao@cs.unm.edu
--For coming up with the brilliant idea of using Doom for process
management and wading through the XDoom code to implement it.
Mark H. Hamilton: mark.h.hamilton@gtemail.net
--For coming up with the psDooM moniker "DooM for Sys A's".
psDooM is currently maintained by:
David Koppenhofer (djk@users.sourceforge.net)

311
dockerdoom/trunk/psdoom/README Normal file
View File

@ -0,0 +1,311 @@
psDooM is a process monitor and manager for *nix systems.
It could be considered a graphical interface to the 'ps', 'renice', and
'kill' commands.
psDooM is based on XDoom, which is based on id Software's 'Doom'.
This project started out as a proof-of-concept program for the web page
"Doom as a tool for system administration" at
http://www.cs.unm.edu/~dlchao/flake/doom by Dennis Chao at the University
of New Mexico. Dennis took the GPL'd sources of XDoom and added code so
that processes running on the system would be instantiated as monsters,
and wounding and killing them corresponds to renicing and killing the
processes.
I (David Koppenhofer) loved the idea of combining two of my favorite
computer subjects (Linux and Doom). Therefore, I began to enhance and
customize the program.
Goals of this project include:
1) Add even more functionality to the process manager such as the ability
to send various kill signals and a way to shut down the machine
_cleanly_ from the program.
2) Add networking support so multiple admins can work the machine at the
same time and/or remotely administer a machine.
3) Everything else in the TODO file.
4) Possibly make other interfaces besides one to 'ps', such as a file
management module.
5) Make psDooM the de-facto standard for graphical process manipulation
on the *nix platform. :-)
------------------------------------------------------------------------
Supported Platforms
------------------------------------------------------------------------
psDooM has been tested on the following platforms:
Linux x86 2.0.x, X11, and [S]VGA
Solaris SPARC 2.6, X11
psDooM can probably be made to work on any version of UNIX which runs
XDoom. It uses several system commands in order to do its work: 'ps',
'renice', and 'kill'. Formats of the commands _must_ be as follows:
*** LINUX 'ps' ***
ps h a x u OT == no header, list other user's processes, list processes
without a controlling terminal, in 'user format',
sorted by process start time. example output follows:
root 1 0.0 0.9 764 388 ? S 18:39 0:01 init
root 2 0.0 0.0 0 0 ? SW 18:39 0:00 (kflushd)
root 3 0.0 0.0 0 0 ? SW< 18:39 0:00 (kswapd)
root 28 0.0 0.8 736 348 ? S 18:39 0:00 /sbin/kerneld
root 143 0.0 1.2 816 472 ? S 18:39 0:00 syslogd
root 152 0.0 1.3 896 528 ? S 18:39 0:00 klogd
daemon 163 0.0 1.0 784 404 ? S 18:39 0:00 /usr/sbin/atd
david 218 0.0 2.1 1280 856 1 S 18:39 0:00 -bash
root 221 0.0 0.7 724 296 4 S 18:39 0:00 /sbin/mingetty tty4
david 598 0.0 1.2 844 472 2 R 22:14 0:00 ps h a x u OT
*** SOLARIS 'ps' ***
/usr/bin/ps -A -o user= -o pid= -o tty= -o comm=
list all processes, show username, show process id, show terminal,
show user's command, suppress headers. example output follows:
root 1 ? init
root 28 ? /sbin/kerneld
root 2 ? (kflushd)
root 3 ? (kswapd)
root 152 ? klogd
root 143 ? syslogd
daemon 163 ? /usr/sbin/atd
david 598 2 ps
david 218 1 -bash
root 221 4 /sbin/mingetty
renice +5 <pid> == renices process number <pid> to +5 priority.
kill -9 <pid> == sends a SIGKILL to process number <pid>.
------------------------------------------------------------------------
Obtaining the Source
------------------------------------------------------------------------
The latest version of psDooM can be found on the homepage at:
http://psdoom.sourceforge.net/
------------------------------------------------------------------------
Problem Reports
------------------------------------------------------------------------
If you find a problem with psDooM, you can e-mail me at
djk@users.sourceforge.net. You could also go to the psDooM SourceForge
Project Page at http://sourceforge.net/project/?group_id=3418
and use the facilities there (like 'bug report', 'support request', etc).
However, please be sure that it is a psDooM problem rather than an XDoom
issue. The easiest way to tell the difference is to run XDoom with the
same level and options (if at all possible). If the problem occurs there
as well, it's XDoom's fault, not psDooM's. Obviously, if the problem
involves any of the psDooM-specific command line flags or 'pid monsters',
it is a psDooM-related issue. :-) I cannot guarantee that I can solve
your problem. I'm doing this in my spare time for the fun of it; this
software is provided on AS IS basis.
------------------------------------------------------------------------
Building psDooM from Source
------------------------------------------------------------------------
If you're reading this file from the binary distribution, you don't need
to know how to build psDooM from source. Go on to the next section. :-)
If you're intrested in building psDooM from source and you're reading
this file, you've either untarred the psDooM sources or have successfully
applied the psDooM patch to XDoom.
See Udo's "INSTALL" file in ../xdoomsrc/doc for details on building from
here on.
Changes to the XDoom code are generally denoted by '*** PID BEGIN ***'
and '*** PID END ***' in the source files. The files pr_process.c and
pr_process.h are new files for psDooM.
------------------------------------------------------------------------
Executing psDooM
------------------------------------------------------------------------
NOTE: Throughout the explanation, I'll refer to the program as 'psDooM',
even though the executable you actually run will likely be called
something else (like ps-sxdoom).
If you can run XDoom, you're well on your way to running psDooM.
Be sure to see the XDoom docs (and other Doom-related material) in
../xdoomsrc/doc/ (or ../xdoomdoc/ if you're using the binary
distribution), as it applies to psDooM also, with a few cavaets:
* I have yet to test demo recording compatability with XDoom and other
Doom ports.
* Save games aren't compatable with XDoom (and other ports, I imagine).
* Netgames won't work on levels that have pid monsters in them, due to
consistancy check errors. Netgames on levels without pid monsters
should work, but this is untested as well.
* psDooM is installed into the directory /usr/local/games/psdoom rather
than /usr/local/games/xdoom. Shell scripts are still installed in
/usr/local/bin.
* psDooM looks for its default configuration files (.doomrc, .xdlaunchrc)
and savegame files (doomsav?.dsg) in ~/.psdoom rather than in ~/.xdoom.
Now, with those out of the way, we can get to the good stuff. :-)
psDooM can monitor processes with shareware Doom 1, registered Doom 1,
Ultimate Doom, or Doom 2. 'Plutonia Experiment' and 'TNT - Evilution'
will run, but no process monitoring will be done.
The first level (either E1M1 or MAP01), and only the first level, will
contain monsters that represent processes currently running on the machine
('pid monsters'). The machine's process list is checked at regular
intervals. Processes that are new since the last check are spawned as new
monsters, while processes no longer running on the machine are removed
from the level. Process monitoring is not done if playing on a level
other than the first one or while recording/playing a demo.
A 'pid monster' is identified by the text 'floating' in front of it. This
text denotes its process id number and the last 7 characters of the
process name. The text is not shown if the monster is too far away from
the player or too close to the edge of the screen.
Wounding a 'pid monster' corresponds to executing a 'renice +5' on the
associated process. Killing a 'pid monster' sends a 'kill -9' to the
associated process. Since the renice and kill actions are done by a
system call, they are governed by the permissions of the user running
psDooM. For example, if a normal user, 'jschmoe', kills a 'pid monster'
whose real process is owned by 'jdoe', nothing would happen to the
underlying process on the machine because jschmoe doesn't have the rights
to alter jdoe's processes. The 'pid monster' that jschmoe killed will be
resurrected in psDooM during the next process check. The resurrection
denotes that the process on the machine never really went away; its Doom
representation was only temporarily stopped from moving around.
In the original implementation of the program, 'pid monsters' could be
killed not only by the program's user, but also by other 'pid monsters'
and normal Doom monsters on the level. The reasoning behind this behavior
was that "on very heavily-loaded machines, it is not uncommon for the
OS to kill random processes." Unfortunately, the number of monsters
in a given area must be depressingly small in order for them to avoid both
intentional infighting and friendly fire. Since monsters would tend to
kill each other off until only a few remained in the area, the user was
severely hampered in the ability to orderly control processes on the
machine. Therefore, the default behavior of psDooM is to ensure the
player is the only character in the game who can wound and kill 'pid
monsters'. This avoids accidental process deaths from monster infighting.
Unfortunately, it doesn't prevent accidental process deaths from a user's
poor aim. ;-} The original behavior of 'pid monsters' being as vunerable
as other monsters may be enabled with the command line flag:
-nopssafety
Causes the 'pid monsters' to not be protected against damage from each
other, normal Doom monsters, and the environment. Normally, only the
player may inflict damage on 'pid monsters'.
Which processes are represented by default depends on whether you're
running psDooM as the root user or not. If you are root, then all
processes are shown. Normal users see only their own processes by
default. The current username is determined by looking at the environment
variables PSDOOMUSER, LOGNAME, USER, and USERNAME (in that order).
Changing these variables will _not_ change the permissions of your
username with regard to process renicing and killing; they're just used to
determine username for the 'userlist'-related options. The default
'userlist' behavior may be nullified by giving some command line arguments
to psDooM.
NOTE: specifying _any_ of these options will cause psDooM to ignore the
default settings for the current username. The list of users whose
processes to show will start out empty.
-psallusers
Effectively adds every username to the list of users whose processes
to show.
-psuser [username [username]...]
Adds username(s) to the list of users whose processes to show. If no
username is specified, the current username (as determined by the
environment variables listed above) is added to this list.
-psnotuser [username [username]...]
Adds username(s) to the list of users whose processes NOT to show. If
no username is specified, the current username (as determined by the
environment variables listed above) is added to this list.
Examples of 'userlist' command line flags:
%ps-xdoom -psallusers
This command will show every user's processes.
%ps-xdoom -psallusers -psuser jschmoe jdoe
The '-psuser jschmoe jdoe' is extraneous here; users jschmoe and jdoe
are included in '-psallusers'.
%ps-xdoom -psallusers -psnotuser
This will show everybody's processes except your own. Remember, your
username is determined automatically by psDooM according to what
PSDOOMUSER, LOGNAME, USER, or USERNAME is set to in the environment.
%ps-xdoom -psnotuser jdoe
This will show no processes, even if you're running psDooM as root.
Remember, specifying any 'userlist' command line option causes the
defaults to not be used; the list of users whose processes to show
starts out empty.
The 'pid monster' locations depend on what version of Doom you're using
and whether you have the custom process management levels (available on
the psDooM web site).
If you have registered Doom 1, Ultimite Doom, or Doom 2, you can use a
custom level designed for process management. There is one level designed
for Doom 1 (psdoom1.wad) and another designed for Doom 2 (psdoom2.wad).
If those files are present (or linked to) in the program's directory and
have the correct name (as given above), the level will automatically load
as E1M1 or MAP01, unless suppressed with the command line flag:
-nopslev
Suppresses the automatic loading of the custom level psdoom*.wad and
makes psDooM assume pid monster coordinates for the stock E1M1 or
MAP01. It has no effect if you don't have the custom level or if
you're using shareware Doom 1.
NOTE: The command 'ps-xdoom -nopslev -file psdoom1.wad' will not work for
process management. While the custom level will be loaded, psDooM would
assume E1M1 coordinates for the 'pid monster' placement. The E1M1
coordinates do not correlate to anywhere meaningful on the psdoom*.wad
maps.
Locations of the 'pid monsters' within the levels are as follows:
For shareware Doom 1, and registered Doom 1 or Ultimite Doom without the
custom level:
psDooM spawns the 'pid monsters' in the 'hidden' courtyard on E1M1.
To get there, go through the room with the zig-zag floor with poison
around it and open the miscolored wall on the right, before the door to
leave that room.
For Doom 2 without the custom level:
psDooM spawns the 'pid monsters' in the 'hidden' courtyard on MAP01.
To get there, activate the switch to (and get on) the lift in the room
before the exit. Then, once the lift raises, activate the rear wall and
walk into that secret alcove. When you leave the lift, a door to the
courtyard will have opened on the right side of the room, past the
window on the right.
For the custom levels:
psDooM spawns you in a room with equiptment and weapons. The switch
ahead of you exits the level, and the three doors take you to rooms
containing 'pid monsters'.
There are several other command line flags that affect how psDooM runs:
-nopsmon
Disables process monitoring entirely. Nice if you want to play an E1M1
or MAP01 level that isn't set up for process monitoring.
-nopsact
Disables the system calls to 'renice' and 'kill' when 'pid monsters'
are wounded and killed. This is good if you only want to monitor
processes, not manage them.
-nomonsters.
Yes, there is a period at the end of this command. It does the same
thing as the '-nomonsters' flag, but is persistant across new games and
level warps.
NOTE: 'pid monsters' are NOT affected by the '-nomonsters' and
'-nomonsters.' flags; use -nopsmon to turn them off instead.
-respawnitems
Like you think it may work, this flag causes items to respawn as they
do in '-altdeath' games (Invun, Invis, and dropped items don't
respawn; everything else does). This flag has no effect when recording
or playing a demo because it messes up timing.
The XDoom distribution includes a graphical front-end to xdoom, called
xdlaunch. It allows the user to specify XDoom command line flags by
clicking option boxes and using dropdown lists. This utility has been
renamed to ps-xdlaunch and modified to run psDooM. Also, a place in the
front-end was added so a user can manually type additional command line
flags to pass to ps-xdoom. psDooM-specific options can be shown by
pressing a button in ps-xdlaunch. This utility requires TCL/TK.

173
dockerdoom/trunk/psdoom/TODO Normal file
View File

@ -0,0 +1,173 @@
Here are a few ideas to improve this process manager:
N == not planned
? == possible, but not planned and/or is it necessary?
- == not started, but planned
O == in progress
X == done AFAIK
X-display last 7 characters of process name rather than first 7
ie: '/sbin/mingetty' would appear as 'ingetty' rather than '/sbin/m'
X-make text disappear when entire pid monster sprite is obstructed
X-make text 'float' with the monster (adjust y-value of print)
X-pid monsters don't count towards end-level 'kills' percent
X-pid monsters don't spawn in/on other things
N-toggle monster inter-fighting (ie. CacoDemon vs Imp on(default)/off )
N-toggle monster intra-fighting (ie. Human vs Human on(default)/off
Demon vs Demon on/off(default) )
X-OR as an alternative to the above 2, have pid monsters only take damage
from a player
O-command line flag to allow pid monsters to be damaged normally
(-nopssafety)
X-better process management:
N-non-blocking process manager so pauses aren't as noticable
NOTE: pauses would still be there with the non-blocking
process manager - tested by disabling pr_poll() call
and running a sh script on a seperate terminal that
called 'ps' every 5 seconds: pauses were still noticable
X-if a process is killed/removed outside xdoom, remove it from xdoom
X-update process names (ie. mingetty --> -bash after login )
?-compare pid monster name to incoming name and copy the name
as a result of that comparison
NOTE: right now, the name update happens to every pid monster
every time the ps list is updated. would adding a check
to see if the name needs to change speed things up? in other
words, how much faster is strncmp() than memcpy()?
X-if a process monster is killed in doom, but the actual process doesn't
die on the machine, resurrect the monster's body like the archvile
does; if we can't raise the monster, remove the body and respawn the
monster
X-gracefully handle save and restore
X-only re-nice a monster the first time it is damaged
?-OR with successive damages, get the process' priority, and re-nice
to 2(?) more than the current level until it reaches 20 (the maximum)
NOTE: must be careful about shotgun and other rapid-file or
multiple damage weapons because one could re-nice monsters
to +20 really fast
X-customized level map for managing processes
NOTE: *any* level that has 3 1024x1024 areas for monster spawning such
that the bottom left coordinates of the squares are at (0,0);
(2048,0); and (4096,0), respectively, will work
NOTE: current custom level details and decorations may need tweaking
X-if the custom level isn't (or can't) be loaded, use stock E1M1 in
doom 1 (or MAP01 in doom 2) for process management
X-custom level loads automatically, like xdoom.wad. the custom doom 1
map must be named psdoom1.wad and the custom doom 2 map named
psdoom2.wad for the automatic loading to happen
X-command line flag to disable automatic loading of custom level; manage
processes on stock E1M1 or MAP01
(-nopslev)
?-custom level for shareware doom (psdooms.wad); must get permission
from id software before doing this
X-game acts like normal xdoom if not playing on E1M1/MAP01 or if playing
any 'Plutonia Experiment' or 'TNT - Evilution' level
X-command line flag to entirely disable 'ps' portion of the program
(-nopsmon)
X-command line flag to disable actual re-nice and kill of processes
(-nopsact)
X-command line flag to make 'no monsters' persistant across new
games and warping
(-nomonsters.) == no monsters, period :-)
X-pid monster spawning not affected by '-nomonsters' or '-nomonsters.'
command line flags
X-command line flag to respawn items like in -altdeath games
(-respawnitems)
X-this flag should have no effect in demo recording or playback; it
would mess up the demo timing
X-command line flags for determining which user processes to spawn
X-command line flag to cause every username to be added to the list of
users whose processes to display
(-psallusers)
X-command line flag to cause specified usernames to be added to the
list of users whose processes to display -- without any supplied
username(s), assume current user
(-psuser [username1[ username2...]])
X-command line flag to cause specified usernames to be added to the
list of users whose processes not to display -- without any
supplied username(s), assume current user
(-psnotuser [username1[ username2...]])
X-if none of the userlist-related command line flags are given, the
program defaults to showing only the current user's processes if
not running the program as root -- root sees all processes by
default -- current username is determined by looking at the
environment variables PSDOOMUSER, LOGNAME, USER, and USERNAME in
that order
X-ensure that demo playing and recording do not use the 'ps' portion of
the program
X-the demo that plays immediately after ending a game (options->end game)
on a level with pid monsters is messed up; fix it
?-use c functions like setpriority() and kill() rather than the
system() call (would this speed things up significantly?)
--put command line options into an in-game menu
--ability to have multi-admin netgames
--ability to administer processes on a machine other than the one running
psdoom
--more general format for custom level areas for pid monster spawning
--'PSINFO' lump in wads tells engine where to spawn pid monsters and on
what level(s)
--current behavior is used if no PSINFO lumps are given
NOTE: format of this textual lump is sorta in my head: one lump
specifies all maps and coordinates -- ExMy or MAPxx lines
seperate coordinate grouping lines within the lump
{ExMy or MAPxx}, {R, A, or U} (one of these lines per level)
* to denote which map the info is for and the method by which
processes are placed in the spawnboxes of that level
* 'R' tells psdoom to spawn pid monsters in a
round-robin-esque manner among the given spawnboxes:
pid #'s are mod'ed by the total number of spawnboxes on
that level and the pid monster is spawned in the resulting
numbered box
ie. pid# 1432 is being spawned on a level with 5 boxes:
1432%5 = 2; pid monster will be spawned in the third
(0, 1, 2) box listed in the lump
* 'A' tells psdoom to use the relative area of the spawnboxes
to determine the chances of spawning a pid monster in each
* 'U' tells psdoom that there are user-specified percentages
for determining chances of pid monster spawning for the
spawnboxes
{x, y, dx, dy, nn} (one or more of these lines per level)
* a point of origin and the length of the sides for a box (in
doom map units) on that level for processes to spawn in
* the final argument is a field that is only used if the 'U'
flag is given above: it gives the percent chance of a pid
monster spawning in this spawnbox
* if the running total of user-specified percentages becomes
greater than 100%, the remaining spawnboxes will not have
monsters spawn in them
* if the nn is not there for a given area, the remaining
part up to 100% is assigned to that spawnbox
--make pid monsters less aggressive towards (afraid of?) player
--pid text is not placed well when screen is not at largest or second
largest size; fix it
--more info about processes
--monster type reflects cpu/mem usage
--more text information (space limited)
NOTE: perhaps could print more info as the monster gets closer
and takes up more of the view
--shutdown/reboot machine with psdoom*.wad level exit switch(s)
NOTE: need to make a custom texture to notify user of this interface
--type of weapon determines what signal to send with the kill command
on monster death (eg. pistol=kill -1, shotgun=kill -2, ...
plasma & BFG=kill -9 ???)
NOTE: rocket launcher probably not a good choice because of collateral
damage (maybe protect pid monsters?)
O-modify xdlaunch (ps-xdlaunch) to run ps-xdoom
O-add psdoom-specific command line flags to ps-xdlaunch
--incorporate the Back Orifice port of psdoom
--command line flag to use Back Orifice rather than local admining
(-psbo)
O-support multiple operating systems (the ones xdoom supports)
--freebsd
X-linux
--openserver 5
--unixware 2
--unixware 7
O-solaris
--aix
O-use ~/.psdoom rather than ~/.xdoom for savegames, config files, etc
O-add references to psdoom in startup header text, X resources, and window
title bar