Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

Randomized Backstories

67 (25.9%)

Genetic Additions

98 (37.8%)

Mess Hall

50 (19.3%)

Revamped Area

44 (17%)

Total Members Voted: 257

[quinnr]

Did you know:
Setting up a laser beam or proximity sensor and setting a radio on it will alert the radio with a *beep beep*.

So setting up one in EVA can be very helpful. (although you need 2, so they can't steal one.)

Also, THERMITE ROCKS!

[beorn080]

Throwing monkeys sets off sensors.

[quinnr]

Lag!

[head]

My gf is playing aion on the good computer.

Anyone think it's a good idea to set up a bug/additions tracker?

[quinnr]

Bug tracker might be a good idea.

I saw you added zombie suicide!

[beorn080]

Zombie suicide should release a Mustard Gas like cloud of spores that can infect people without internals.

[quinnr]

That would be awesome.

[head]

That would be awesome.

Zombie suicide is going to visible for zombies only whenever i get around to it.

[Orb]

I think zombies(in my personal opinion) could be rebalanced in the following way.

Zombies have double the stun resistance of normal humans(unlike the near immunity of it).

And to compensate, zombies dont get harmed from plasma.

This will provide two things. One, zombies arent trapped because of plasma spamming everywhere. Two, humans can use stun guns and such to actually take out zombies, instead of having to inject the halls with plasma. Zombies still die from fire and so on.

One last thing, zombies should "barely" get harmed by space(such as cold damage), so people arent floating around all day, not suiciding because they are idiots.

I would suggest that zombies can take two stuns in say 10 seconds, and the third one knocks them out for half the time "variable" for a regular human. Of course, I dont know how any of this would be programmed, but its a suggestion, nethertheless.

[Jackrabbit]

Zombie suicide sorts out the spacing problem. If someone doesn't see it, just direct them to it.

[Smitehappy]

I've been thinking. What would be the overhead performance wise on having certain actions being logged? Not everything like interacting with doors and the like. Things associated with griefing like cause of death, tracking what player killed what, actions involving bombs, etc?

[quinnr]

That's what I was wondering too.

[qwertyuiopas]

Nearly have a working banlog verb. It lets you write to file("ban/[ckey(target)].ban.log") where ckey(target) is:

-The ckey of a client currently on the server
-A ckey in the ban list
-A ckey in the unban list
-An IP in the ban list

It writes a
----------

Followed by a timestamp, and then it will write the writer's key and message.

Each line of the message woul be preceeded by a > to prevent faking.

Edit:
Some tinkering later, and I have it nearly complete!
Last change is the > line starts. Once that is done...

[qwertyuiopas]

Success.

----------
Date: Wednesday March 10 2010
Time:20:32:41
Admin: uristqwerty
>Ban reasoning here
>Ban reasoning there
>
>a
>
>fbv
>ag
>a
>ga
>erg

Everything is working perfectly!

It will only accept banned players/IPs, active players, and players who were unbanned, so that false names cannot be used as spam or anything similar.

It can only be read through notepad by the host, but I am sure someone will add an in-game reader, and even without it, it is still immensely useful.

Also suggested: log ban-based proc calls. So actual bans will show up alongside the admin ban comments.

Forgot-to-post-edit:
Added some security, and a proc to log ban events for other coders to call. It would be for logging things like bans and jobbans, not writing comments, as it doesn't prefix each line with >, except the first. (On the main ban log writer that line would be the admin: line, and the comment would follow. That way, comments can be distinguished from automated loggings.)

That proc also has the advantage of using the same timestamp format and general layout.
Example of it's use, would be placed at the start of the fullban proc(after the return on bad arguments line)

Code: [Select]

logBanEvent(M.ckey,"crban_fullban:\nBanner:[banner]\nReason[reason]")
Okay, final tests, and I am ready to share the code.

Okay, how is the format?

Code: [Select]

----------
Date: Wednesday March 10 2010
Time:20:58:17
Admin: uristqwerty
Comment:
>Ban reasoning here


----------
Date: Wednesday March 10 2010
Time:20:58:20
Admin: uristqwerty
Comment:
>Ban reasoning here


----------
Date: Wednesday March 10 2010
Time:20:58:24
Admin: uristqwerty
Comment:
>Ban reasoning here
One bug, but it is almost a feature: If you submit it by hitting enter with the focus outside of the reason box, the reason is left blank. This only coommonly occurs when an admin(me) writes the name last or doesn't edit the reason. Since the only way to make that mistake would be to try to dismiss the box quickly, I'll leave it in as a feature.

[head]

looking awesome.