In response to Ter13
I don't respect anyone. I've stated his way of doing is objectively non-optimal and he'd only have to change the code files once to get this to work.

Runtime performance should be preferred over compilation time, but compilation time isn't hugely impacted by this. That's his delusion. I suspect this same kind of mentality is the kind of work ethnic that goes into Space Station 13 and makes it run and compile so poorly.

He probably can't read my posts either, but I really don't care. This isn't the only time hes been wrong, but numerous others, that I ended up deleting the post in response to, because I thought I had too harsh of a demeanor. Occasionally in the past, he gave input that supported my argument, so I didn't deny it, but the information given was still inaccurate so it still irked me.

Sorry that misleading information being imposed as fact pisses me off. Like I said, Idc if he can't read it. As long as the objective side is presented to eyes that care, it's cool. But yeah... changing the fps to emulate time dilation is something that early console games did on limited hardware, and it created a lot of problems in doing so. It's just not acceptable anymore. Players shouldn't have to mentally adapt to new input delays for a slowmo effect (assuming the verbs aren't instant).

If I'm really that much of a nuisance as your tone suggests, then ban me (nobody can see my posts anyways). I speak the truth, 80% of the time, the other 20% being when I blindly read the post and ashamedly misinterpret it. This kind of contempt your tone conveys is exactly why any innovation I have to offer BYOND will forever be locked away, and I focus purely on my own accomplishments.
EDIT:

...Just logged out and noticed that there are people on my ban list involved in this one.

Apparently we have some of the same people blocked.
Shatan wrote:
You could emulate time dilation without changing the fps, and if you DO, then the response times/interaction between UI elements will stay consistent.

There is literally no way to emulate time dilation properly with current technology for a couple reasons. As an aside, it's basically a jokey hack that is not used seriously.

[Edit]

To clarify, no way to emulate it property in a multiplayer environment. It can certainly be done in a single player one.

[Edit2]

And Jesus,

Let's not forget this guy hasn't made Space Station 13, he helps develop a server of it. He's the equivalent of a ripper on BYOND and the game itself awfully plays like one.

Are you really so pathetic as to try and argue guilt by association, and in a really flimsy manner? Why don't you just claim, "Oh, and he's a faggot* to boot." because that would be just as powerful a claim.

*I have no idea what MrStonedOne's sexual preferences are, this is just an example.
I have no idea what MrStonedOne's sexual preferences are

This went directions. Not good ones, but directions the same.
This is kinda off topic, but I also can't see his messages but I don't have anyone blocked. Even if I block him and unblock I still can't see his message.
In response to Ndangerman
Ndangerman wrote:
This is kinda off topic, but I also can't see his messages but I don't have anyone blocked. Even if I block him and unblock I still can't see his message.

Yep. This is not in error.
Could you explain why?
Could you explain why?

Short answer? Cunt.

Long answer?

Cuuuuuuuuuuuuuuuuuuuuuunt.
In response to Ter13
Ter13 wrote:
Could you explain why?

Short answer? Cunt.

Long answer?

Cuuuuuuuuuuuuuuuuuuuuuunt.

Could I have that in bold please?

on-topic: It would be nice to see some examples of le 'tricks' people o:
Neat "code trick" for single-player games only:

If you read a turf from a savefile, it will overwrite any turfs at the turf's stored location.

This is a neat trick for saving things in a single player game like which chests have been opened.

mob
player
var
list/saved_turfs = list()

turf
chest
var
list/rewards()
verb
open()
set src in oview(1)
var/mob/player/p = usr
if(!saved_turfs[src])
saved_turfs[src] = 1
usr.contents += rewards
new/turf/openchest(src)
openchest


Also, cool factoid: turfs are always indexed by location. Storing a reference to a turf and then initializing a new one in the same location will reference the new turf, as turfs are never created or destroyed. They are simply replaced.

So weird bugs can crop up when you have turf procs operating over time:

turf
runtimeturf
var
somevar
Entered()
new/turf(src)
spawn(10)
src.somevar = "herpderp" //this will generate a runtime error because src still exists but no longer has a somevar variable.


Undefined variable /turf/var/somevar
proc name: Entered (/turf/runtimeturf/Entered)
  source file: REDACTED.dm,1265
  usr: Ter13 (/mob/player)
  src: the turf (51,86,2) (/turf)
  usr.loc: the turf (51,86,2) (/turf)
  call stack:
the turf (51,86,2) (/turf): Entered(Ter13 (/mob/player), the grass (51,85,2) (/turf))


Cool right? Basically, your turfs should never do anything over time. If they do, you should hand that behavior over to a datum or the object involved with the interaction. It is safer. Also, there's only a few decent ways to predict when a turf has been re-initialized after a sleep or a spawn. One of those ways is to track the time the turf was created for all turfs using a variable. Obviously, this isn't foolproof, but it should work for most cases.
In response to Popisfizzy
Popisfizzy wrote:
There is literally no way to emulate time dilation properly with current technology for a couple reasons. As an aside, it's basically a jokey hack that is not used seriously.

[Edit]

To clarify, no way to emulate it property in a multiplayer environment. It can certainly be done in a single player one.

You can mimic it virtually, just as this game is doing. That's what I referred to in context.

MrStonedOne seems to take it seriously judging by his tone.

It can be done both in a multiplayer and single player environment, it doesn't matter which.

Are you really so pathetic as to try and argue guilt by association

That's how I view him. People that make SS13 servers are the equivalent of rippers.

Ter13 wrote:
Could you explain why?

Short answer? Cunt.

Long answer?

Cuuuuuuuuuuuuuuuuuuuuuunt.

I already knew Lummox has me globally muted or his shit is broken. Therefore my input is harmless.
Shatan wrote:
You can mimic it virtually, just as this game is doing. That's what I referred to in context.
It can be done both in a multiplayer and single player environment, it doesn't matter which.

If you pretend slowing down time except maybe for a small group of people is time dilation, but the only thing they share in common is that they involve time. Such a situation is impossible if you're only considering what can be done in the mechanics of relativity.
In response to Popisfizzy
Popisfizzy wrote:
Shatan wrote:
You can mimic it virtually, just as this game is doing. That's what I referred to in context.
It can be done both in a multiplayer and single player environment, it doesn't matter which.

If you pretend slowing down time except maybe for a small group of people is time dilation, but the only thing they share in common is that they involve time. Such a situation is impossible if you're only considering what can be done in the mechanics of relativity.

Yes so you'd have two internal clocks for each, and they'd both be independent from one another, just like how clocks tick slower while in space. c:

But in this exact case, time dilation isn't realistic and does refer to a perceived slowdown.
Shatan wrote:
just like how clocks tick slower while in space.

Unfortunately, there is no absolute time, so there is no way to decide that clocks tick slower in space. From the frame on the surface of the earth, clocks tick slower in space. From the frame of someone up in space, clocks tick slower on Earth.

And if you have an idea of how to have two different groups perceive the other as having a slower ticking clocks "at the same time" just using game mechanics, I'm all ears.
In response to Popisfizzy
Popisfizzy wrote:
And if you have an idea of how to have two different groups perceive the other as having a slower ticking clocks "at the same time" just using game mechanics, I'm all ears.

This isn't what Space Station 13 does, but sure... I'll give you an example. Record the events in areas that are going faster in time, and play them back slower in the areas that time is moving slower. Basically a recording.
Record the events in areas that are going faster in time, and play them back slower in the areas that time is moving slower.

There is no absolute reference frame. Relatedly, there is nowhere in the universe where once would perceive things going faster in time. Relative to your own frame, all other frames have clocks ticking more slowly.
If there are an infinite number of men knocking on an infinite number of doors, how many doors remain to be knocked on?
In response to Ter13
Ter13 wrote:
If there are an infinite number of men knocking on an infinite number of doors, how many doors remain to be knocked on?

Does each man knock on one door? Or does each man knock on each door?
In response to Ter13
Ter13 wrote:
If there are an infinite number of men knocking on an infinite number of doors, how many doors remain to be knocked on?

Oh, that's easy. Let D be the doors, and let M be the men. The knocking is a function K : M → D. If M and D have the same cardinality, then every door has a man knocking on it. If |M| < |D|, then there are infinitely many doors unknocked on If |M| > |D|, then there are too many men for how many doors there are (i.e., at least one door has two or more men knocking on it).

You may have said that as a joke, but this is stuff in set theory and is very important. The work of Cantor is not to be overlooked.
In response to Popisfizzy
Popisfizzy wrote:
Ter13 wrote:
If there are an infinite number of men knocking on an infinite number of doors, how many doors remain to be knocked on?

Oh, that's easy. Let D be the doors, and let M be the men. The knocking is a function K : M → D. If M and D have the same cardinality, then every door has a man knocking on it. If |M| < |D|, then there are infinitely many doors unknocked on If |M| > |D|, then there are too many men for how many doors there are (i.e., at least one door has two or more men knocking on it).

You may have said that as a joke, but this is stuff in set theory and is very important. The work of Cantor is not to be overlooked.

That's actually incorrect. Say the nth man knocks on door 2n.
Page: 1 2 3 4 5 6