Maps

[sparhawk]

I think it's a VERY difficult distinction to make. In fact I can't think of any good definition off the top of my head that makes it clear which is which.

 

That's what I meant, and this time it was really badly phrased by me.

 

I know I've been on the other side of the fence when it came to eliminating quicksaves, for example, and there's not a huge difference between that and this. On the other hand, I want to make sure that TDM provides good gameplay, which means we have to make some decisions about gameplay without providing multiple options. Tricky.

 

Yup! That's the problem.

[Domarius]

Yep, and that's why we discuss things. Or "nit-pick" if you please.

 

As for your last post, you lost me after "president", must be a language barrier thing...

[sparhawk]

.. or a reading disabillity.

[SneaksieDave]

...Eliminating quicksaves?

 

Tell me there was a decision to eliminate quicksaves. Please.

 

*readies bow*

[Gildoran]

My understanding of Sparhawk's post is that you only need to state "who's side you're on" if you're being voted on as a representative. Since we're voting on this directly rather than electing representatives to decide for us, there's no reason to state our opinion unless we're making an argument for a side.

 

@SneaksieDave: There was a decision to eliminate quicksaves! *quickly ducks behind Springheel*

[Ishtvan]

What would happen if we put a "timescale" console command in the readable script? This is an existing D3 console command that slows down time, not sure if I remembered the name right tho. Would this let us easily slow down time by some amount when reading readables without requiring much modification to the code? If so, maybe we should do this and include it in the options as something of a "disability" setting (so there, it's not a playstyle or a gameplay setting, it's a 'disability' setting ), like how Winblows has those disability settings for holding down multiple keys and stuff? Normally time keeps going in realtime, but if you read at a rate that's slower than normal, you can go into the options and set the "time slow down when reading" factor to allow for slower reading?

 

Maybe it only has to be done for fixed position readables, because it would be weird to walk around and see time going slowly if you were walking around with a holdable-readable, and you should be able to find a safe spot to look at holdable-readables and read them at your own pace in realtime.

[sparhawk]

1) What is the "normal" reading speed?

2) Why would it be a "disabillity" if somebody is a slower reader then others?

3) Shouldn't we have a gamepause function anyway for other purposes?

[Ishtvan]

We do have a game pause function, but it wouldn't allow interacting with the GUI. They'd have to pause, read, unpause, turn page/scroll down, pause, read, etc. Kind've a pain in the ass.

 

If you want to get all politically correct, we don't have to call it a disability, we can just call it "reading challenged" or "non-native english reader" or whatever. Point is, reading speed varies all over the place, so some people will find the time that the FM author allocates to read a fixed readable before an AI passes by too short for their reading speed.

[Springheel]

We do have a game pause function,

 

We do? Well heck, why are we even having this discussion then?

[SneaksieDave]

As long as the setting can go to zero (no time progression).

 

Either that or we can just freeze the game world like we were supposed to.

 

Tomato / Tomato

[sparhawk]

We do have a game pause function, but it wouldn't allow interacting with the GUI. They'd have to pause, read, unpause, turn page/scroll down, pause, read, etc. Kind've a pain in the ass.

 

Hmmm... That's not really helpfull. I thought it were paused with GUIs as well.

[Ishtvan]

We do? Well heck, why are we even having this discussion then?

 

I meant using g_stoptime 1. It pauses everything though, as in the frame loop does not run, GUIs do not update or animated or anything, AFAIK. Also I think the same thing would happen if the timescale were set to 0.

[Springheel]

Well, they'd have to unpause at the end of a page to turn the page, but is that really a big deal? Most static readables will only be a page anyway. Do we need to spend time coming up with alternative ways to freeze time when it's already doable?

[Domarius]

My understanding of Sparhawk's post is that you only need to state "who's side you're on" if you're being voted on as a representative. Since we're voting on this directly rather than electing representatives to decide for us, there's no reason to state our opinion unless we're making an argument for a side.

Not always true. Some things are personal preference, and can't be resolved in a discussion, so we go with the majority ruling.

 

 

 

Back on topic - how's this for a solution;

 

All un-movable readables pause time.

Since locked down readables don't allow the "take it to a safe place" game mechanic, so they're not part of it.

[Ishtvan]

Personally I like the fixed readable system as it is. That's also what pretty much everyone said when Gildoran presented that version, so I'm a little confused why there's all this uproar now. I think having them stop time should only be an option if anything, and then only if it's relatively easy to add to the existing code.

[sparhawk]

Well, they'd have to unpause at the end of a page to turn the page, but is that really a big deal? Most static readables will only be a page anyway. Do we need to spend time coming up with alternative ways to freeze time when it's already doable?

 

Yes, this is VERY annoying and not really a good interface design. I think one could use it a as a last ressort, but it shouldn't be done like this if better ways exist. In that case we don't even need to code anything though, because the suer can still map it to a key and toggle it.

[SneaksieDave]

Heh, sometimes you just think clearer in the morning. Has anything bothered to try it? I just did. On readables_test, I frobbed the letter on the desk, and set g_stoptime to 1. I still see the readable, I can still look around, I can still read. The only question which remains is, will it affect timed scripts/events (no idea, but erm, it is STOPtime, not "let time keep going") and page turning; and since I can still walk around, zoom in/out, etc., I would assume an impulse for page turning could still be used. (?)

 

To make it complete, lock the player's view angle, and feet to the ground. Then it will behave like the same readable, in the same readable design, but for all intents and purposes, the gameplay world will be frozen.

[Springheel]

I think one could use it a as a last ressort, but it shouldn't be done like this if better ways exist. In that case we don't even need to code anything though,

 

Exactly. Isn't that a good thing?

 

I know you like good code, Spar, but I see it like this:

 

Based on the vote, people prefer 2:1 a certain system. This system is already done. We want to give some consideration to the minority who want time to freeze. A working (even if not elegant) system already exists to do this and takes no extra work from us.

 

So why should we do extra work to make a -better- method for the minority that want it, when a perfectly workable solution is already done?

[sparhawk]

I did not say we should do it. If we have this already, then people can bind the key and use this one. Ugly but it works. BUT! *IF* we implement it, then it should be done properly.

[Ishtvan]

To make it complete, lock the player's view angle, and feet to the ground. Then it will behave like the same readable, in the same readable design, but for all intents and purposes, the gameplay world will be frozen.

 

There's a problem with this. The fixed readable code is written with the assumption that the player will be able to look around to place the readable in the center of their screen in order to read all of it. If they frobbed the edge of the readable when it was near the side of their screen, it might pop up off to one side and not entirely readable, until they move it to the center of their screen. If you lock the view angle, they won't be able to do this, so it would pop up in some readable position and then they'd be stuck with it there until they exited out, repositioned themselves and frobbed it again.

 

Also, I didn't remember this before, but I think sounds get fucked up when you use g_stoptime_1. If you had some kind of conversation controlled by a script, the currently playing line of dialogue would play to the end when you used g_stoptime_1, but there would be no advance in time registered from when it was stopped, so the conversation script would go out of sync.

 

Probably the only viable option is to set some option in the readables script where the GUI acts like a main menu GUI instead of being overlayed in your HUD, i.e., fills the whole screen, exits out of the game and pauses time like the main menu does. This will require Gildoran to go back and rewrite it tho, which in my experience is pretty demoralizing. Ideally you should let coders know if they have to change something right after they demo it. In this case too, the majority opinion still seems to be that it doesn't have to be rewritten, so it's pretty frustrating if you put yourself in the programmer's shoes.

[SneaksieDave]

Not to be argumentative, but the decision to make it optional preceeded the design. By all means keep the design, it's fantastic. But if it doesn't account for the original plan, then by the original plan it's not yet finished. I didn't think it would be complicated to simply do a readable the way id does the PDA, since it's already been done, and the code is there. As for the centering, c'mon. Exit the function which does the angle stuff, and center it instead, if the user has the disability option enabled.

 

Anyway, just more of this guy's opinion. I'm outnumbered anyhow.

[sparhawk]

But our readable IS like the PDA in Doom 3. Didnt you notice that time continues when you look at it? I think you can even see a bit through some alpah transparency on the PDA, when something moves.

[SneaksieDave]

Okay, I guess I mean the menu then. I didn't think time passed with the PDA... guess I'm lucky I was never attacked while reading slowly.

[Gildoran]

Heh, yeah, I've been attacked while reading the PDA before; I had thought I cleared out an area when I really hadn't. But you not noticing the passage of time while reading PDAs illustrates why time passing won't be a problem: People will tend to only read when they believe they're safe. (and that's the only time they should) You can take a portable readable to a nearby broom-closet and read it there. With fixed readables, the messages should either be short and sweet or in an area where guards rarely enter. And at least with our readables you can see around the edges, so it's far easier to tell if there's a guard nearby than the Doom 3 PDA.

[Darkness_Falls]

I like the real-time readables idea, and like Gildoran's implementation of it. The only problem I have with it is that if there is a readable stuck to a wall or desk (you can't take it), and it is in a lit area that you can't make darker, then you'll have to run back and forth -- between shadows and light; in-between guard patrols -- in order to fully read whatever document you're trying to read. Reading a one page doc in this manner would be annoying. Reading two+ full pages would be downright a problem.

 

For things you can take with you, I'm on the fence. I'd have to test it to decide, unfortunately.

 

Regardless, to satisfy both worlds (because you'll never please both), I suggest just implementing it whatever way we decide and then put a setting under options that people can choose. I know we don't want an option for everything on the options menu, but I really think this would be a good one to have there. Some people read English as a second language; or read slowly; etc. We should consider these factors and how shadows are not always readily available to hide in. But I'm not a programmer.