General bugfix/cleanup dump

[GoogleCodeExporter]

This issue addresses non-specific code cleanup and minor bugfixes

Original issue reported on code.google.com by KelsonG...@gmail.com on 2 Aug 2008 at 9:08

[GoogleCodeExporter]

Cleanup: Atoms.dm: /atom/moveable/Move(NewLoc, direct)
Suggest: Update code to avoid blocking northeast if north open and east isn't

Original comment by KelsonG...@gmail.com on 2 Aug 2008 at 9:12

Attachments:

• 1.patch

[GoogleCodeExporter]

Looks like it already does this in your new code since it flows through?

+   if(direct & NORTH)
+       if(step(src,NORTH))
+           if(direct & EAST)   step(src,EAST)
+           if(direct & WEST)   step(src,WEST)
+           return 1
...
+   if(direct & EAST)
+       if(step(src,EAST))
+           if(direct & NORTH)  step(src,NORTH)
+           if(direct & SOUTH)  step(src,SOUTH)
+           return 1

the 2nd code block will execute if the first one fails to, with the first 
trying N
then E, and the 2nd trying E then N

Original comment by maddi...@lightbound.net on 2 Aug 2008 at 9:20

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

the step function has side effects, so im fairly sure that code does not in 
fact work
properly in all situations (if the direction is northeast, it could end up going
north->east->north, for instance)

Original comment by kur...@gmail.com on 2 Aug 2008 at 9:30

[GoogleCodeExporter]

Neg Maddi - if it steps north, but can't step east, then you won't move NE. May 
have
been able to travel east then north, however - that isn't checked (maintaining
consistency with original code). If we wanted to change that ability, we could 
use
either a temp dummy or can/get_steps.

Kurper, that is consistent with the original function.

Original comment by KelsonG...@gmail.com on 2 Aug 2008 at 11:44

[GoogleCodeExporter]

a generic 'TryEnter' or something proc may be required (unless it's already 
present
in the 'CheckEnter' stuff).

We may have to do what OpenSS13 did and split most of /atom/DblClick out into 
it's
own function and try to make it generic enough that it can check if small 
objects can
move, and it large dense objects can move (since right now it just checks "can I
reach this?" using a dummy object that has flags|=TABLEPASS

Original comment by maddi...@lightbound.net on 2 Aug 2008 at 11:51

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Minor Bugfix: bad comparison in alert/process led to all sensors alerting

Original comment by KelsonG...@gmail.com on 3 Aug 2008 at 12:24

Attachments:

• 3.patch

[GoogleCodeExporter]

Minor Enhancement: Allows AI to use Move anytime (current camera not required)

Original comment by KelsonG...@gmail.com on 3 Aug 2008 at 12:35

Attachments:

• 4.patch

[GoogleCodeExporter]

Minor Change: INFINITY = 1e99 now declared in globals.dm (= to 1.#INF at 1e30 
though)

Original comment by KelsonG...@gmail.com on 3 Aug 2008 at 12:46

Attachments:

• 5.patch

[GoogleCodeExporter]

Minor Change: /atom/movable/Move moved to atoms.dm with similar code

Original comment by KelsonG...@gmail.com on 3 Aug 2008 at 12:50

Attachments:

• 6.patch

[GoogleCodeExporter]

Minor Change: Adds smoke when computers are hit

Re: Movement - If we're interested in changing that, I suggest a new issue for 
it

Original comment by KelsonG...@gmail.com on 3 Aug 2008 at 4:05

Attachments:

• 2.patch

[GoogleCodeExporter]

Minor Changes: Helpers.dm: shuffle now uses pick (instead of random), findname 
now
returns the /mob instead of 1 (although nothing uses it), centertext now uses
add_lspace (instead of replicating functionality), removed redundant returns

Original comment by KelsonG...@gmail.com on 3 Aug 2008 at 1:28

Attachments:

• 7.patch

[GoogleCodeExporter]

Minor Enhancement: datumvars.dm now /admin/admin_powers/debug.dm, host given 
access
to /proc/delete in non-sandbox modes (be careful, lots of code makes bad 
assumptions
about things existing)

Original comment by KelsonG...@gmail.com on 3 Aug 2008 at 1:49

Attachments:

• 8.patch

[GoogleCodeExporter]

Minor Change: appended /game/sun.dm to /atom/sun.dm, updated directional names
Suggest: Changing solar code as it requires too much babysitting at present

Original comment by KelsonG...@gmail.com on 3 Aug 2008 at 4:05

Attachments:

• 9.patch

[GoogleCodeExporter]

Suggest: Changing solar code as it requires too much babysitting at present

Tracked under issue #197

Original comment by maddi...@lightbound.net on 3 Aug 2008 at 4:08

[GoogleCodeExporter]

Random TODO:
- shuttle still counts as space (try throwing an object)
- gases still created when placing a tile in space (in some cases)
- AI can still control most of the station after 'hardline' cut
- closing a closet on a siphon stops it from operating

Original comment by KelsonG...@gmail.com on 6 Aug 2008 at 9:10

[GoogleCodeExporter]

I don't want the host able to delete stuff in non-sandbox modes, the UNIX-y 
model of
"assume that the host knows what they're doing" is not even remotely applicable 
to
SS13. I want to reduce the potential for admin abuse, not increase it.

Original comment by kur...@gmail.com on 6 Aug 2008 at 8:54

[GoogleCodeExporter]

all of these but #8 are now applied

Original comment by kur...@gmail.com on 6 Aug 2008 at 9:01

[GoogleCodeExporter]

I've been looking at the issue more from the other side; what commands would 
make the
admin's job easier. The other day an admin spawned an object in an "illegal" 
location
which required a restart to fix since no one could remove it. This isn't to 
excuse
the admin's mistake (de-admined now), but just an example of current power
limitations. I think limiting the command to the host pre-empts most abuse - 
after
all, he can "delete" all objects by just shutting down the game.

Original comment by KelsonG...@gmail.com on 12 Aug 2008 at 5:05

[GoogleCodeExporter]

that might not be a good idea, it'd be good for abakahn/ratama/evarr to be able 
to
spawn things for game modes, but i wouldnt want him able to permaban people 
probably

Original comment by kur...@gmail.com on 12 Aug 2008 at 7:43

[GoogleCodeExporter]

Minor Bugfix: Assistants no longer spawn at null if no space is available in
area/arrival/start (instead /mob/carbon/New() retries for 5 minutes then aborts)

Original comment by KelsonG...@gmail.com on 14 Aug 2008 at 3:03

Attachments:

• 10.patch

[GoogleCodeExporter]

Patches 8 & 10 applied

Original comment by KelsonG...@gmail.com on 16 Aug 2008 at 6:17

• Changed state: Accepted
• Added labels: Priority-Low
• Removed labels: Priority-Medium

[GoogleCodeExporter]

Original comment by KelsonG...@gmail.com on 29 Aug 2008 at 2:26

• Added labels: Branch-Kelson, Phase-Kelson-1

[GoogleCodeExporter]

Code cleanup of drag.dm and items.dm; committed as attached to rev 564

Original comment by KelsonG...@gmail.com on 29 Aug 2008 at 10:42

• Added labels: Revision564

Attachments:

• 11.patch

[GoogleCodeExporter]

Code cleanup of /mob/carbon/movement.dm; committed as attached to rev 566
- primarily removed redundant function calls and terrible program flow
- added log_bug command to logging.dm (logs to "BUG: [text]")
- removed pointless and confusing debug message

Original comment by KelsonG...@gmail.com on 31 Aug 2008 at 9:15

• Removed labels: Revision564

Attachments:

• 12.patch