tgstation / tgstation-server Goto Github PK

The compiling state is the longest active state the tools will be in (by far).

Atm, canceling during compiling waits for the compile to finish, and then just doesn't stage the update. This isn't how one would expect that to work. It should just proc kill the compiler process.

Starting a new job while it's already compiling doesn't do anything right. It just fails to start the compiler, then the original compile job continues. No warning about an active task, nothing.

Ideally it should be a pop up modal. Giving 3 options, abort, cancel current job and continue, and forcefully continue.

Actually, if it's a compile its in the middle of doing, it should just abort the compile and do the new job, no prompts.

The way tgs2 did this, was actually a 10 second prompt before the compile started, giving the user the chance to stop, as well as the ability to just close it during the compile to abort, and a double warning next update run about a unfinished state, and the possibility the update job was still running. (because it had no way of knowing)

Being forced to wait 3 to 5 minutes to do something else if you realized you made a mistake or want to amend the update job isn't ideal

Server starts and shutdowns are relaying fine, but ahelp related messages aren't being sent.

Only a hard restart from the server tools remedies this

The last time it reported a new round was at noon EST, April 7th. It still gives out compile updates and such, but is not announcing new rounds.

Just some document that details what tgs3 expects from the game server

mmkay?

@lzimann is not fit to own this repo, shit needs to be done.

Use https://github.com/tgstation/byond-server

Also, it should be byond focused, not /tg/station focused.

No reason any code base, of any game, that is open sourced, can't use this framework. byond-server will be byond focused.

Bot Token Reset Due to Potential Abuse

It appears your bot, MimeBot, has connected to Discord more than 1000 times within a short time period. Since this kind of behavior is usually a result of a bug we have gone ahead and reset your bot's token.

Feature Request:

Automatic server repo update and changelog generation upon a PR being merged into the remote.

Each step doesn't necessary need its own line.

tgs2 intentionally kept it to start and stop lines for this reason.

There doesn't seem to be a command for telling dream daemon to enable the webclient.

basically. for example, give someone a login which can only update...

/config, /data and libmysql.dll shouldn't be hard coded

Unintended, they should be left alone

If there is a rsc in the folder, byond will try to re-use it, and even use it for resources not in the actual project folder.

This (feature) of byond is horribly bugged, random bits of old versions of now not used files will get interspaced where nulls or rsc metadata should be.

Example:

Ó....x">Photocopied papers will now retain their stamps</li>.... (. = unprintable character)
The Ó is the exact spot the last file ended (an ogg) at this point, there should be 18 bytes of meta data, followed by 4 bytes of payload size, a null terminated file name string (not part of the payload size), and the payload

Instead we have a random changelog entry.

This is a real example, from hippie.

tgs2 deleted the old staging folder every time before copying over from the repo to prevent things like this (and prevent now deleted files sticking around)

Update and testmerge pushes compiled changelogs after test merging, causing the test merge commits to get pushed too

tgstation/tgstation#29155

[00:09:50] <Mr_Bagil> REPO: Updating origin branch...(Hard Reset)
[00:09:53] <Mr_Bagil> REPO: Test merging PR #29155...
[00:09:54] <TheGhostOfWhibyl1> https://github.com/tgstation/tgstation/pull/29155 - '[wip][dnm]A* improvements' by MrStonedOne
[00:10:04] <TheGhostOfWhibyl1> [tgstation] tgstation-server pushed 6 new commits to master: https://github.com/tgstation/tgstation/compare/5836c10e3097...86c41964b99f
[00:10:04] <TheGhostOfWhibyl1> tgstation/master 85de154 MrStonedOne: astar improvements...
[00:10:04] <TheGhostOfWhibyl1> tgstation/master e5d3cd8 MrStonedOne: commiting debug version just so its on record somewhere if i want it again.
[00:10:04] <TheGhostOfWhibyl1> tgstation/master f952583 MrStonedOne: And the comparison debug version
[00:10:11] <TheGhostOfWhibyl1> [tgstation] tgstation-server closed pull request #29155: [wip][dnm]A* improvements (master...betterastar) https://github.com/tgstation/tgstation/pull/29155
[00:10:13] <TheGhostOfWhibyl1> [tgstation] tgstation-server pushed 1 new commit to master: https://github.com/tgstation/tgstation/commit/73f60400e86483abb1ab0842d30852bda5afcae0
[00:10:13] <TheGhostOfWhibyl1> tgstation/master 73f6040 tgstation-server: Automatic changelog generation for PR #29155 [ci skip]

@Cyberboss This can't happen. Me even having commit access to push compiled changelogs is on shaky grounds, and I kept it because I made damn sure shit like this never happened by treating the compile and push changelog code in tgs2 with more care and attention then I treat player facing non-parameterized sql code. I basically treated it like a loaded bomb.

In dream daemon, there was a button that allowed you to send announcements to all connected players shown as message from host.
It can be useful in certain scenarios, and it bypasses most gamecode and lag.

https://stackoverflow.com/questions/6771694/shared-assemblyinfo-for-uniform-versioning-across-the-solution

Detached the service, got an error about the service being dead after running the command line, updated, ran server tools and got "Topic delivery failed!" as my status

Easy enough to fix, instead of qdeling the world, just send a killme message instead

Application: TGServerService.exe
Framework Version: v4.0.30319
Description: The process was terminated due to an unhandled exception.
Exception Info: System.NullReferenceException
   at Discord.Net.WebSockets.GatewaySocket+<ProcessMessage>d__17.MoveNext()

Exception Info: System.AggregateException
   at System.Threading.Tasks.Task.ThrowIfExceptional(Boolean)
   at System.Threading.Tasks.Task.Wait(Int32, System.Threading.CancellationToken)
   at Discord.Net.WebSockets.WebSocket.<.ctor>b__33_1(System.Object, Discord.Net.WebSockets.TextMessageEventArgs)
   at System.EventHandler`1[[System.__Canon, mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b-CENSORED-9]].Invoke(System.Object, System.__Canon)
   at Discord.Net.WebSockets.WS4NetEngine.OnTextMessage(System.String)
   at Discord.Net.WebSockets.WS4NetEngine.OnWebSocketText(System.Object, WebSocket4Net.MessageReceivedEventArgs)
   at WebSocket4Net.WebSocket.FireMessageReceived(System.String)
   at WebSocket4Net.Command.Text.ExecuteCommand(WebSocket4Net.WebSocket, WebSocket4Net.WebSocketCommandInfo)
   at WebSocket4Net.WebSocket.ExecuteCommand(WebSocket4Net.WebSocketCommandInfo)
   at WebSocket4Net.WebSocket.OnDataReceived(Byte[], Int32, Int32)
   at WebSocket4Net.WebSocket.client_DataReceived(System.Object, SuperSocket.ClientEngine.DataEventArgs)
   at SuperSocket.ClientEngine.ClientSession.OnDataReceived(Byte[], Int32, Int32)
   at SuperSocket.ClientEngine.SslStreamTcpSession.OnDataRead(System.IAsyncResult)
   at System.Net.LazyAsyncResult.Complete(IntPtr)
   at System.Net.LazyAsyncResult.ProtectedInvokeCallback(System.Object, IntPtr)
   at System.Net.Security._SslStream.ProcessFrameBody(Int32, Byte[], Int32, Int32, System.Net.AsyncProtocolRequest)
   at System.Net.Security._SslStream.ReadFrameCallback(System.Net.AsyncProtocolRequest)
   at System.Net.AsyncProtocolRequest.CompleteRequest(Int32)
   at System.Net.FixedSizeReader.CheckCompletionBeforeNextRead(Int32)
   at System.Net.FixedSizeReader.ReadCallback(System.IAsyncResult)
   at System.Net.LazyAsyncResult.Complete(IntPtr)
   at System.Net.ContextAwareResult.CompleteCallback(System.Object)
   at System.Threading.ExecutionContext.RunInternal(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean)
   at System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean)
   at System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object)
   at System.Net.ContextAwareResult.Complete(IntPtr)
   at System.Net.LazyAsyncResult.ProtectedInvokeCallback(System.Object, IntPtr)
   at System.Net.Sockets.BaseOverlappedAsyncResult.CompletionPortCallback(UInt32, UInt32, System.Threading.NativeOverlapped*)
   at System.Threading._IOCompletionCallback.PerformIOCompletionCallback(UInt32, UInt32, System.Threading.NativeOverlapped*)

On that note, what is the best way to recover from this, the round is still going and what not, is there a way to start the service so it reattached, does it default to that, or would I have to wait for the round to end, task kill DD, then start the service?

I'm in the middle of building a docker container framework that can be used to host "edge" cdn byond servers that send the user the resources and then send them on to the real server.

The last step would be some way to know when the server's rsc has changed and trigger a rebuild of the docker image (I'll have it grab the rsc via the smb share that already exists for the game folder, that part isn't hard)

So I was thinking, it would be handy to create events that ran things.

You could do this the user friendly way and make an interface for the different types of events (restart, round end, crash, update, compile, etc), or you can just push unique event ids in windows event viewer and i can just make scheduled tasks based off of them.

Just try to be as granular as sanely possible and very particular in your documentation about what events trigger when.

It'd be nice if it handled compiling TGUI :)

Theoretically it should be easy to host multiple instances by opening multiple WCF hosts. The main issue is EVERY file access relies on CWD, so, that'll have to stop

compiling the change log in the repo when it wont be commited is keeping chained test merges from happening in alot of cases.

it causes there to be changed files so this triggers a merge error.

You could do a git reset to head (git reset --hard) to clear these out since they will get regenerated anyways. Since you reset to head it won't effect the current test merges.

I have an idea for how this could be done. Instead of killing the DD process, we merely let it go and reattach to it on service startup.

• Attachment can be done at any startup if there is a DD process running in the context of the service account
• This does mean we will miss any relays sent to the service during the operation. Maybe require an ACK from the service for each?
• Having this all be initiated by an installation is the problem we have a couple of options for notifying the server

1. Call a function through the interface: Ideal, but may be too dependency heavy
2. Write to a file the service looks out for: Too hacky imo
3. Use a native service command: https://msdn.microsoft.com/en-us/library/system.serviceprocess.servicebase.oncustomcommand(v=vs.110).aspx
4. Write an immutable base executable that loads a dll with the code and switch it out on updates: May be too complex

The hard part about any of the is getting our installer to dance to this tune

We shouldn't be verifying users using the username on Discord as it can be changed. Use the user ID instead

It relays updates and the server watchdog to IRC, but anything in-game isn't being relayed.

@Cyberboss

Its there without an actual build. You said you had to change something @Cyberboss?

See #13 (comment)

The public key is already encoded in the private key, and I was able to git the git client to work without it.

upstream bugreport: libgit2/libgit2sharp#1468
upstream bugreport: libgit2/libgit2#4289

Need to drop the quotes entirely and use the escape rules here: http://www.byond.com/docs/ref/info.html#/proc/params2list

https://msdn.microsoft.com/en-us/library/system.diagnostics.process.kill(v=vs.110).aspx

The bot may disconnect from irc or just start ignoring discord, you have to disable and re-enable the chat interface to fix it.

irc_check is missing from the server. Also for some reason the unknown command is irc_chec and not irc_check even though it's defined as irc_check in the tools, not sure what's going on here.

See comments in #40

Not sure if DD crashed or hung but this came up in logs: Failed to send topic: serviceCommsKey=;command=irc_check

Had to manually restart it

see title. It thinks the mention is part of the command

forcing a hung DD process to restart does nothing then attempts to start a new DD process while the old one is still up

[02:31:14] <Mr_Bagil> REPO: Updating origin branch...(Hard Reset)
[02:31:20] <Mr_Bagil> REPO: Merging PR #30610...
[02:31:21] [tgstation] Push: tgstation-server pushed 0 commits to master

Did somebody forget to verify that commit didn't error out?

Not sure why but in my B folder (A was live) the symlinks were missing, I clicked Update and the compilation failed. I assume this is because it couldn't read 'blank.png' in the title_screens folder. Would be nice to check if it exists before running DM.exe

Having these alerts trigger on 4 channels is annoying, having these alerts trigger on random shit like the toolkit updating is annoying.

There needs to either be a massive scaling back of the times we use this word, or a new word we can bind to has to be created, for headmins who want to get alerts when the server crashes/restarts.