Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - agris

Pages: [1]
1
Site Feedback & Suggestions / Re: possible to change time zone?
« on: April 20, 2022, 11:22:16 pm »
Ah thank you, I thought “Modify” in the navigation header was telling me where I was, not there was more options in a CSS drop down.

2
Site Feedback & Suggestions / possible to change time zone?
« on: April 20, 2022, 01:38:07 pm »
Is it possible to change the time zone that dates/times are displayed relative to? This is a pretty common feature in forum software, but I'm not seeing it as an option under account settings.

3
Suggestions / new keyboard bindings to improve kb-based play
« on: April 20, 2022, 01:18:22 pm »
I love how keyboard focused Underrail is. The way quick and combat items are arranged is great, and the native usage of shift/control to modify what those respective bars do is a great idea clearly driven by a person who enjoys interacting with games and UI in a keyboard-centric manner.

I have a few suggestions on how to improve keyboard driven gameplay even more (I know, 10 years late). I'm an old player of the Infinity Engine games - and those were another example of great keyboard-driven gameplay/UI navigation. Why do I mention the IE games? Well, they had a combat log just like Underrail. It was actually a combined dialogue/combat log, so more primitive than Underrail's implementation. But old Bioware anticipated the same thing that Styg and company did with Underrail: that periodically the player would want to change the log window size, or even hide it.

IE games (excepting IWD2, let's not talk about that one) let you raise or lower the height of the log through the use keyboard PGUP and PGDN keys. The increments that the log changed were fixed, and if you hit PGDN at the lowest increment of the log then the log was completely hidden.

I'd like to propose something similar for Underrail. The inclusion of new control binding options for:

  • Decrease log width (with the final "step" in decreasing the log width hiding it)
  • Increase log width (when log is hidden, the first "step" displays the log)
  • Change log type (i.e. toggle between combat or dialogue displayed, or hide the the log)

The log width would change in increments already available through the mouse-driven settings menu, i.e. 20% above 100%. Once the log is shrunk to only 100% width, hitting the key again would hide the log. Conversely, if the log is hidden, hitting the key to increase log width would show the previous log type at 100%.

Changing log type may not actually make sense to be a configurable hotkey, but rather work like SHIFT does for quick and combat items, so that shift+(increase/decrease) log width will cycle through displaying either the combat or dialogue logs, or hide the log entirely.

Since there are visual UI elements for all 3 types of logs (combat, dialogue, hidden) and they are arranged in a vertical order, the logic of which "direction" you change the log type in is dictated by whether you invoked changing the log type through shift+increase width (change type "UP", cycling to the bottom once you hit the top - combat) or decrease width (change type "DOWN", cycling to the top once you hit the bottom - hidden).

This also means there are effectively TWO ways to hide the log: through decreasing the width below 100%, and by cycling the displayed log type to hidden. I think power users would really appreciate the latter option. If they play with a log width of greater than 100%, cycling the log type to "hidden" through SHIFT+ would preserve the log width when it is eventually unhidden. Obviously if you hide the log through decreasing the width, increasing the width to show it again means the player starts at 100%.

Suggested key bindings would be HOME to decrease log width, END to increase it (because those are associated with the correct logical directions, <-- and -->). If you want changing log type to be user configurable and not use the SHIFT+ hardcoded logic, I suggest PGUP/DN, because those are associated with the correct logical directions of navigating log type arranged in a vertical order.


Some other grab-bag ideas to improve controls
  • Please recognize MOUSETHUMB as a valid binding option, it is not currently
  • We can currently bind combat items to the numpad keys, and they do not conflict with regular quick items bound to 1, 2, 3 etc. But this is buggy, and breaks SHIFT+combat invoking reload options for your guns.
  • When the mouse is hovering over the log, give the log focus so that the mouse wheel can scroll it. Currently the mouse wheel cannot scroll the log

Thanks for reading, hopefully I made it clear what I'm suggesting. I'm *hoping* the keybindings for the log are pretty trivial to implement, and have a real chance of consideration in a future patch.

4
Suggestions / can suggestions still impact Underrail?
« on: April 16, 2022, 08:07:15 pm »
Looking through this forum, I can't help but notice that there isn't much engagement with new suggestions. I recognize that this isn't that unusual; Underrail is at the end of it's post-release support in terms of updates and improvements, and when suggestions require significant code/area/design time, they are probably beyond the scope of whatever continued support is planned.

So my question is: do the developers have any appetite for considering implementing suggestions that are, for lack of a better description, trivial?

It's my own fault that I waited so long to play the full game (Alpha 0.1.X was the last time I played...) but now that I'm into the game and bumming around the Foundry, there are multiple keyboard-centric controls suggestions I'd like to provide. I guess what I'm asking is, is there any consideration for implementing simple stuff like "create dedicated keyboard binding option A for previously mouse-only click interaction Z"?

It would be nice to know before potentially wasting time tracking and writing up controls/input-related suggestions.

5
Bugs / Re: Lake Mushroom
« on: April 10, 2022, 09:11:41 pm »
Speaking of classification bugs, in the crafting menu:

Frag grenade case is sorted under the "Grenades" tab, whereas Thin grenade case is sorted under the "Intermediate" tab. The cases should *both* be under intermediates.

Further, frag mine cases are also sorted under "Grenades" while Thin mine cases are under "Intermediates". All mine cases should be under intermediates, it especially makes no sense for frag *mine* cases to be organized with grenades.

v1.1.5.9 steam, win10x64.

6
I'm guessing that it is either in ..\data\concept, ..\data\expansions or ..data\gui, but if one of the devs could just point me to the correct .XNB files I would appreciate not having to mass export these folders to find it.

I want to swap either the expansion or original main menu screen with this one: https://abload.de/img/underrailbyjasonseowo9kjb.jpg

7
Bugs / Re: Report spelling/grammar errors
« on: April 06, 2022, 08:03:32 pm »
Kimi's first dialogue sequence with the player in Junktown, the action text describing her replanting, says "Her stare is directed toward the plant, but is seems like her attention is not"

"is" should be "it".

8
Bugs / Controls bug: NUMKEY maps to Quick Button
« on: April 04, 2022, 04:03:51 pm »
This is latest Steam release w/ DLC (1.1.5.9?), QWERTY/EN OS and game.

I remapped WASD to move the camera, moving the Character Sheet to C, Combat Stats to /, and Take All to Q. In remapping the Quick Buttons, I was happy to see that NUMPAD 1 - 9 didn't conflict with Keyboard 1 - 9, which are mapped to the Action Buttons. The in-game settings menu doesn't actually say NUMPAD, it just says 1, but when you first map NUMPAD 1 it doesn't give a conflict message. Same with NUMPAD 2, 3, etc to 6, which means the engine is distinguishing numpad from kb.

Here's the bug: I have Quick Button 1 mapped to NUMPAD 1, so to reload my weapon I should hold SHIFT+NUMPAD1 right? Doesn't work. The SHIFT+Quickbuttons selection doesn't seem to work with NUMPAD Quick Button assignments.

Hope this can get fixed!

Also - any chance of a hotkey to show/hide the log? Similarly, it would be great if there were dedicated keys to lengthen/shorten the width of the dialogue window, kinda like how in the Infinity Engine games (Baldur's Gate), you can hit PGUP/PGDOWN to expand or contract the dialogue window in useful increments. Here you could map PGUP/PGDOWN to expand/contract the dialogue window in 20% increments, and once the window is at 100% hitting PGDOWN one more time would hide it.

Just a thought.

EDIT: the game doesn't recognize MOUSETHUMB? I was thinking about remapping inventory to the mouse's thumb button, so I could remap the action buttons to E,R,T,Y,U,I for a continuous segment of keyboard, but I can't remap to the thumb button.

9
Yea, that could work but I still prefer an introduction of randomness into the skill checking mechanics, even if toned down. It changes the binary nature of player skill challenges (lockpick, hacking,etc) to one involving random chance. Scenarios in which player skill is challenged will have a probability-weighted gradient between success and failure now, rather than a line. Think of it as flavor, increased replayability, whatever.

That is distinct from my desire to obfuscate the lockpick and hacking skill values, though I think a tiered response, including options to reveal the lock strength, is a good option.

10
Bugs / Re: Missing Area Junkyard
« on: November 16, 2013, 08:39:41 pm »
Ok, but I still think it looks a bit 'unnatural'. In most cases you can see the wall, even when its on the foreground (there is an example in the screen-shot, left under). So when you walk into a room where that is not the case, it looks a bit weird.

Agreed

11
Lockpicks used to work more like in Fallout. Styg added the skill requirement display when he made lockpicks consumable & haxxors require batteries. I agree displaying the lock difficulty is kind of too gamey (and rather useless, since lockpicks don't even break if you fail to pick a lock)

I wonder if he's open to a merged system like nackidno suggested?

Not seeing the lock level will probably make the player use a high level pick for an easy lock, which I don't have a problem with BUT! What if mechanics and electronics skills gave the player the ability to see the lock level up to the current skill level (20 mechanics can show locks with level 20)? Thoughts?

Also, what engine does the game use? I assumed Unity but couldn't find it stated anywhere. I've been trying to get borderless window mode to work (for psuedo full screen enabling seamless use of 2nd monitor) but Windowed Borderless Gaming isn't positioning the window correctly and -popupwindow doesn't work (Unity 3.4+ supports this).


12
Thanks. I disagree though, in that in fallout the lockpick item (which wasn't required for picking locks, but provided a bonus) did have a chance to break. I can't articulate it better than that original post, but just displaying the value feels game-y. Akin to posting skill requirements next to dialogue options ala skyrim, FO3 or FNV.

What do you think about the changes to crafting? I really think changing optional components (esp. weapon components) to right click to add would make the current system better.

13
Bugs / Re: Report spelling/grammar errors
« on: November 14, 2013, 12:26:54 am »
'treshold' -> 'threshold'


14
Hey Styg, I've been playing Underrail for ~20 hours now and have some suggestions based on my playtime. I'm really looking forward to see where the game progresses, and I want to give you some feedback while it's fresh on my mind. I've enjoyed my one character in Underrail a lot (a sneaksy, gun using, mechanics/electronics/lockpicking/hacking psychokinesis using character), and all my comments reflect on that character type. I can't speak towards balance of the game for tank-like characters.

First, generalities.

Things That Were Good
  • Level design: Specifically, as a sneaky-hacker-pistol-psi character, the vent system was very well done. The timing for popping out of vents to evade security bots / cameras is near perfect. Combat encounter design was well done too, though I would have liked to see a bit more environmental interaction (similar to exploding barrels; ignitable oil slicks, etc).
  • Plot: while the writing leaves more to be desired (it's not hackneyed, just dry), the overall plot and subplot structure was enjoyable.
  • Combat Balance: based on my background, I was a bit surprised at how challenging the combat was. That is to say, I loved it.

Things That Weren't So Good
  • Documentation: maybe I should have read the Wiki more thoroughly, but the useful values of skills is only apparent to me now having nearly finished the v0.1.9.1 game
  • Location Names: in the context of quest dialogue, the worst offender is the Find Blaine quest (I thought of everything outside the SGS Platform as tunnels). Through flavor text (on zone entry?), in-game signage, or some other mechanism, the naming of important areas could be more clear.
  • Quest Rewards: You have a rich itemization system through crafting, but we're getting credits for completion of quests. Same idea for containers that require a significant combat challenge to access. More in suggestions below.
  • Writing: Competent, but flat (except for the boat captain's story of the Silent Isle). I'm sure you're aware of this, but the further fleshing out (or even implementation of) character personalities would add to the world.
  • Item Valuation: I see that in the future you're going to change item's durability as it relates to value, and I think that's a smart move. As it stands, I fix almost all weapons for resale because I can net 500 to 5000 credits on top of the sunk cost of repair

Bugs
  • This section of vent is not passable, despite it looking as if you intended it to be. It is the 2nd underground portion of the Old Junkyard
  • The word 'threshold' appears as 'treshold' on items which provide multiplicative bonuses to DT based on attack type

General Suggestions
  • The way skill checks for hacking and lockpicking are currently handled needs improvement. First, we have the case of some skill checks being hidden (like when hacking computer terminals, unavailable options are just greyed out without stating what the required hacking level is), while others are known exactly to the player (lockpicking, hacking boxes). Since this is a hardcore RPG, and for consistency's sake, I think all values required for hacking / lockpicking should be obfuscated. Additionally, I think there should be a random element in hacking boxes / lockpicking similar to Fallout. Why? Printing the % values on everything locked feels too 'game-y', and I enjoyed Fallout's system more (I know, this is objective). So, I've come up with these revisions:

    • If you're above 'locked' value X, there is a small chance you'll fail but you'll likely succeed, and if you do fail, you can immediately try again. This also reveals the lock difficulty.
    • If you're below 'locked' value X (but within a predetermined margin), you'll likely fail (wasting energy / picks) but you have a % chance, based on the delta between your skill and the locked container's skill, to succeed. If you fail but are within the margin, you also have a CHANCE (1 - failure chance, %) to reveal the lock's difficulty.
    • If you're below 'locked' value X (and outside a predetermined margin), you do nothing but break picks and waste energy. There is no chance to reveal the lock's difficulty.

    Mechanically, this works similar to the existing system. If you open it, voila, you're done. If you've got a chance to open it, you'll know because eventually the lock's difficulty shows and you can either continue to waste resources trying to open it, or come back later. Finally, players will know a lock is just too difficult when the difficulty of it doesn't appear after multiple tries. Now you've got a unified way to present skill challenges (terminal hacking values are always obfuscated, but should also incorporate a random element for success / failure). For containers / doors / whatever that are permanently sealed, I believe the game already prints a message stating 'this is impossible to open', so that is covered.
  • I believe crafting should be significantly changed from the current model. Principally, any COMPONENT that is OPTIONAL in an item recipe and has the highest skill required in either mechanical, electrical or tailoring (but not chemical or biological) should be able to be right-clicked and added to a valid(i.e. the respective recipe currently supports it) item. Having to craft a gun just to add LS, or an extended clip, isn't fun and doesn't add anything. Keep the skill requirements for adding the item (just as if crafting), but let us use an Image Intensifier Tube, Retractable Barrel or Black Cloth on an existing, valid item. By only allowing components that are optional in the crafting process to be added this way, there is no way for a player to improve the base quality of the item. Thus, for the highest quality and fully modded items, you still need to craft them.
  • Related to the above, I think context appropriate NPCs offering skills for a cost (sure, I'll attach this laser sight for a fee..), repair services and even full item construction would help the world feel more fleshed out and remove what currently feels like a requirement to craft. Put a $$$ premium on the service, but offer it in some capacity
  • Quest rewards should be more varied, and occasionally provide optional/unique crafting components such as a high quality X item or high quality / unique weapon/armor. It would also be nice if the world contained unique and/or pristine items of value (crafting or finished) hand-placed behind hard challenges (whether skill checks or combat)
  • Some NPC text during quests provides invaluable information, and it would be nice to get some Notes updated reflecting the most crucial info (again, Find Blaine, with regards to Katherine's text on his location).
  • Add a map. Not a minimap, but a proper 'hit M for map' map. I think a map rendered similar to the Infinity Engine games would be easiest, since you'll reuse the area map. Maps would contain full fog of war, and only reveal what you've explored. Some NPCs could provide maps (revealing the map) in exchange for credits or a service. An optional motion detector providing hazy red shapes in some radius around the player would jive nicely with this.

Ok, that's it. I'm sure I've forgotten some things, but those are my big takeaways. When play Underrail I see a lot of potential, and I'm really looking forward to playing future builds. Thanks again Styg!

(Finally posted this after slogging my way through 500 INTERNAL SERVER ERROR messages...)

15
Site Feedback & Suggestions / Re: Been getting a lot of 500 errors lately.
« on: November 13, 2013, 05:36:09 pm »
Same here. Been getting them frequently for ~3 days. Both the Wiki and forums.

Pages: [1]