read the original update here: https://cityoftitans.com/content/spring-release-mac-milestone-and-more
—
Wait until you see the... nope, that would ruin the surprise.
Wed, 03/31/2021 - 22:01
#1
Discuss: Spring Release Mac Milestone and More
The Windows patch is now live. Hopefully there are no residual issues from a slightly variant server update process; my own release copy patched and tested fine, so I’m crossing my fingers there are no subtle problems.
Please post any patching-related or weird corruption issues here in this thread, or on Discord, and I will try address them later Friday.
Regular bugs should go in the appropriate forums or Discord channels, or can be posted here.
Thank you all for your patience!
[color=#ff0000]Tech Team [/color]
Well that was an exercise in delayed gratification... :-)
First, started the patching process. In the past this has taken hours for me, so I started my daily Duolingo lesson. But in less than 5 minutes the game was fully patched! I dutifully finished my lesson, then started the game...
Uh oh, now the UE s/w needs to patch. OK back to Duolingo....
Finally, UE is updated and... oh, now I have to reboot the whole PC...
Anyway, once it was all done, I was able to fire up the game. For some reason the first few times I ran it (had to kill the game a couple times as you'll see below) I didn't get any sound. But now I have the music again.
Like the new load screens. Nice use of the AT symbols to get us used to those. :-)
Do I understand correctly from reading the update that we won't see anything different on our characters when selecting powers, and that it's just showing off the menus of power selection? That's still good to see as evidence that we're moving towards an actual game.
Had some difficulty with mapping the movement keys. Previously MWM was kind enough to hardcode in the arrow keys for movement, but for some reason now only Up and Right are mapped. And if I try to map Down or Left, a pop-up appears asking if I want to overwrite other bindings, even though I don't see those keys mapped to anything. Worse, that pop-up is hidden behind the display of the keyboard, so I can't respond to it. Pressing ESC displays the main menu, but behind the current menu and unclickable, so I have to go to Task Manager and kill the game to get out. (Hence the multiple restarts that finally got the music working again.) Down and Left are definitely not mapped, as I confirmed when running around the island.
I have to admit I still find the AB overwhelmingly tedious to work with. There must be a quicker way to change the colours of a costume. For example, I loaded the StealthArmorSuit costume and wanted to simply change the colour scheme from brown & green to purple & blue. This involved locating about 7 different costume pieces in the submenus and then changing 4 colours for each piece. Even making use of the shelf, that's still 3 clicks per colour x 4 colours per piece. Are there plans for a toggle in the future to replicate colours across all parts? What would also be useful would be a single click that applies the entire shelf to a costume piece.
Finally, is there supposed to be a clone of my current character standing on top of one of the buildings? :-o
Thanks again to MWM for all your hard work. Happy to see things are still moving along with this game!
Spurn all ye kindle.
There are plans, and even a complete 2D mockup for, a revision to the color and materials UI to make the process much smoother. This will also come with some overall color sync options.
[center]--------------------------[/center]
[center][color=#ff0000]Interior Map Lead and UI Designer[/color][/center]
Darn it, the clone generator is out of control again... :)
Wait until you see the... nope, that would ruin the surprise.
Very encouraging to hear.
I was just thinking: what would be really helpful would be a checkbox on each costume piece called Linked. All items with this box checked could have their colours/materials changed when any of the others is changed. Might be a way to opt out certain items, so that hair, for example, doesn't get changed to match a costume. Just a thought. You could even have two of these (Linked1 and Linked2) so that you could have two running themes.
Ha! So that's not an intentional easter egg?
Spurn all ye kindle.
Well, if we were going to put in an Easter Egg, this would be the right time for it...
Wait until you see the... nope, that would ruin the surprise.
Boo! :-D
Spurn all ye kindle.
There isn't normally a UE patch when the game updates, since the version of UE we use is installed internally to the game. Are you talking about the little prerequisites patcher that sometimes pops up after the game starts the first time? Not sure why that showed up if you had the game installed before, but I believe it just installs some extra Windows libraries that aren't always present in a standard Windows installation.
ShadowElusive did a terrific job on the UI designs for all the new menu stuff, the powers screens and that loading screen.
It's a *bit* more than that, but the actual implementation of powers affecting the game world still has a ways to go. I could have stuck in the new main UI with all the combat trays and displays, but that would have just been showing off the UI design; everything that it needs to be hooked to, to be useful, is still being worked on in the combat project.
Basically what you get with powers, in this release, is the ability to set up the initial level 1 character's powers and save (and edit) it. And you can actually see all the primary and secondary power sets, and which archetypes and specifications they are attached to. So you can start planning your long term power builds. However, Mastery and Tertiary sets, along with travel and other special power types, do not show up here. Mastery and Tertiary sets aren't unlocked at level 1, so can't be picked at character start time. The special powers like travel aren't yet baked enough to include, I think.
But yes, we're getting there. Getting combat hooked up is one of the major things getting attention behind the curtains right now, and allowing characters to select initial powers is one of the steps on that road.
Mea culpa, sorry. That's an issue with the old menu package changing the Unreal input mappings in your personal init file; the setup for input mappings is slightly different in the new menu system, and I'm pretty sure the leftover data from the old one is what's causing this. I should have caught that, but that file works differently in development than in the actual production build, and I missed it in testing.
There should be a simple fix, by deleting the Unreal init file with the input preferences. That should force Unreal to make a new one from the default settings, which should have the arrow keys mapped. Right now your local settings are overriding the defaults, which do have all the arrow keys enabled.
I'm pretty sure this is stored in GameUserSettings.ini, which, on Windows, should be in (username)\AppData\local\PlayerCharacters, I think. Unfortunately AppData is a hidden folder inside your normal top-level user folder; you have to either turn on the hidden folders in the file explorer, or use %appdata% in the search bar to open it. (I hope I got all that right; I'm on the MacOS side of my machine, so I can't verify those instructions right now.)
Note that removing this file will remove *any* game settings changes you've made, including display settings, sound, etc. Everything should revert to the default values.
Hmmm... I'll put that on the bug list. I've seen at least one other report of that menu popping up unreachably; I'll have to try to reproduce that. I strongly suspect this is a side effect of a fix I put in very late to a focus problem the menus were causing with the main game windows - you had to click on the main window every time the character zoned before you could use it. I suspect fixing that broke the menu's own focus code in some cases, which makes it unclickable.
As Shadow noted, we have plans... (rubs hands and cackles)
However, redoing the character editor isn't as crucial right now as advancing other major pieces we need to get the basics of a working MMO. But it's definitely in our plans, and Shadow and I had a major conversation about trying to figure out some kind of mechanism for color linking across pieces, or apply colors across multiple pieces easily. The exact details of that will likely depend on trying out various ideas to see how they work in practice.
Uh, yes and no. I actually put SuperJoe up there when I was experimenting with character placement (you'll see an NPC character nearby), and I decided to leave him in for local color. For reasons I don't understand, and haven't tracked down, he mutates to your current character appearance in productions builds of the game; in the development system test mode, he's always SuperJoe. I currently have no clue why this is happening, but it needs to be tracked down; we don't want all the other PCs in the game to look like your PC. That said, it wasn't happening in the MMO test build, so ... shrug.
I do plan to chase it down since it shows I'm not understanding something about how the character object dressing system works in practice.
[color=#ff0000]Tech Team [/color]
This is the first time it's done this. I assumed it was because we're on a new version of UE, no?
Ah I see. As someone who doesn't like to plan builds ahead of time (I don't even look at powers till they become available) I didn't look into it in detail. I actually avoided looking at the power descriptions so as not to spoil the surprise when I eventually get to those power sets on Live. I assume we won't have to select all powers at character creation, will we?
No worries -- that's what we're here for! You can't catch everything.
Good memory! You were close. :-) It's in \Users\(username)\AppData\Local\PlayerCharacters\Saved\Config\WindowsNoEditor. Unfortunately, deleting the file didn't fix the problem. Game created a new one, but Down and Left are still not mapped. Weird, because when I look in that config file I can see the mappings for Down and Left, and they look to be of the same format as the ones for Up and Right, so it's not a syntax error, but in the game itself the keys don't work anymore and if I look in mappings backwards and left appear to have no mappings. Hope this testing is helpful. :-)
Fair enough. Glad to hear there are evil plans. Oh sorry, I didn't mean to say 'evil'... I think the vast array of choices compared to that of the old game means the UI needs to be much more advanced. And we'll need a lot more presets. I know some players put a lot of work into making a variety of faces etc when the AB first came out. Can they be contracted to add those sweet configurations into the preset menus?
Malkovich Malkovich Malkovich!
Spurn all ye kindle.
That's quite likely. Unfortunately as a dev, all that Unreal updating has been done by the editor installs, and I don't see those library updaters run when I test my builds, unless I go find a completely pristine machine to test on.
These screens are the character choices for level 1, so no, you don't need to select everything. Since you can edit choices at any time up to the point where, eventually, the character gets uploaded to the server to enter the game, you can just pick anything now so you can get to the point where you can run around on the island. I probably should put an option in the startup menu to allow doing that directly with an existing character.
Helpful, and slightly weird. It's pretty clear one of the Unreal init files is overriding the correct key mappings, which should be the ones in your now-replaced GameUserSettings file.
The relevant section of the settings file should look like:
[code]
AxisMappings=(AxisName="MoveForward",Scale=1.000000,Key=W)
AxisMappings=(AxisName="MoveForward",Scale=-1.000000,Key=S)
AxisMappings=(AxisName="MoveForward",Scale=1.000000,Key=Gamepad_LeftY)
AxisMappings=(AxisName="MoveForwardKey2",Scale=1.000000,Key=Up)
AxisMappings=(AxisName="MoveForwardKey2",Scale=-1.000000,Key=Down)
AxisMappings=(AxisName="MoveRight",Scale=1.000000,Key=D)
AxisMappings=(AxisName="MoveRight",Scale=1.000000,Key=Gamepad_LeftX)
AxisMappings=(AxisName="MoveRight",Scale=-1.000000,Key=A)
AxisMappings=(AxisName="MoveRightKey2",Scale=1.000000,Key=Right)
AxisMappings=(AxisName="MoveRightKey2",Scale=-1.000000,Key=Left)
[/code]
If it does, then one of the other init files must have overriding mappings. Most of the .ini files in that directory should be empty, and the others should be small. I suggest looking through them to see if there are any AxisMappings entries in them. That isn't where they belong, but they can be in there. Unreal reads an insane number of config files at startup, and they can all modify pretty much everything; it's very arcane. The final config files read are the ones in the directory you're looking at, so they should be controlling things. All of them will be recreated from default config files in the application if removed, so it's pretty safe to remove any of them.
In my user config area, only Engine.ini and GameUserSettings.ini are at all big, and there's a little bit of stuff in Input.ini. All the other config files are empty in my version.
The prior menu system did the right and back key binds using a separate AxisMapping name (MoveBackKey2 and MoveLeftKey2, I think), and if those bindings are still lurking somewhere in your init files, they'd cause exactly the symptoms you're seeing, since the MoveBackKey2 and MoveLeftKey2 actions are no longer used in the code, which instead depends on the negative scale value in the new bindings to move in the opposite direction of the action name. And the new menu keybinding system would see those arrow keys are bound to the old actions, which it can't tell are obsolete. The old bindings don't show up in the key binds settings list because it doesn't show every keybind, just the ones I configured it to show.
I just double-checked my Windows install (I'm normally running my machine on MacOS), and everything there looks correct in the install I did yesterday while testing, and I verified that the correct default values are copied into the GameUserSettings file if it's missing.
Once we get body, face, and other presets into the character loading system, it's pretty trivial to add new entries, from any source. I know there's interest in soliciting stuff from players; I don't know what the legal implications of that are, but I suspect it has to be done properly. Intellectual property spats are to be avoided whenever possible....
[color=#ff0000]Tech Team [/color]
IIRC back when ToG was still "officially live" anything that a player created inside the game was automatically legally owned by Paragon Studios. This included anything created in the character creator and even the mission architect. I'd have to assume that MWM will structure the EULA of CoT to work the same way.
Based on that if a CoT player creates a specific repeatable face/body in the Avatar Builder (based on a unique combination of sliders) they wouldn't technically "own" it and thus it ought to be directly reusable by any other player or even "borrowed" by MWM as a preset.
CoH player from April 25, 2004 to November 30, 2012
[IMG=400x225]https://i.imgur.com/NHUthWM.jpeg[/IMG]
Makes sense. No biggie anyway.
That might be useful, but given that the current state of the game remembers the power choices from last time when you load an existing character, it's not all that onerous. Kinda seems like a button you'll have to remove later when it will no longer make sense to enter the game without selecting powers, so I'd say put that verrrry low on your priority list. :-)
On the key input issue, I did some more investigation based on the info you provided. For some reason there were FwdBackLeftRight mappings in the Input.ini file as well as in GameUserSettings, so deleted Input, let the game create a new one, and now all four arrow keys are mapped and working again!
One minor thing: it seems the secondary bind for Jump is no longer working. I can map it in Options, but it doesn't do anything when I press the key. I noticed this when trying to use RCtrl. I can change the primary mapping for Jump to RCtrl and it works fine, but any key I assign to the secondary Jump mapping doesn't do anything. Deleted both GameUserSettings and Input one more time, just to be sure I was starting with a fresh copy of each, and the problem persists.
Spurn all ye kindle.
Glad the arrow keys are working now. I’m not sure how the key bindings got into Input.ini, but there’s a lot I don’t understand about how Unreal handles its settings. Certainly that’s a plausible file to find input bindings in, at least.
I’ll look into the alternate jump binding, I suspect I simply forgot to add it to the code that handles inputs, or a connection got broken that I didn’t notice. This is one of the problems with not having real QA folks cross-checking things. Froggy catches a lot of stuff when he works on the release notes, but it’s not the same as methodical testing. And programmers testing their own code, which is mostly what we do, is not the best approach.
[color=#ff0000]Tech Team [/color]
Yeah, I forgot to put the second jump action key into the movement code. Will be fixed in the next release. Thanks for the catch!
[color=#ff0000]Tech Team [/color]
Best I can determine, GameUserSettings holds the default key mappings, while Input contains any player-assigned mappings. Kinda clever to keep the defaults separate from the bespoke mappings, for situations just like this. There's also a config file called Niagara; I assume that's for when your character falls. Hahahaha...
As someone who worked as a s/w tester waaaay back in his career, I hear ya on that. Like trying to edit one's own writing.
Glad to be able to help, and that it was an easy fix!
Spurn all ye kindle.
I would definitely like to be able to remap the movement keys to the NumPad. Also Targeting and default attack. I like the number-row keys for 'Powers'. I learned that layout in EverQuest and never managed to train my fingers to do it the other way. I'm Right-hand dominant and Movement is critical. I usually program the arrow keys for secondary movement, but then I can't strafe, or side-step.
In other games, I've become accustomed to Mouse-move. Good for navigating and running around, but Combat needs a little more precision.
Just tested this and the game does allow you to map NumPad keys for movement.
Spurn all ye kindle.
Yes, you should be able to map any reasonably standard key; the only ones that might cause problems would be mouse buttons beyond the usual right-center-left trio, and I think Unreal also recognizes two thumb buttons. Beyond that, they’d need to be remapped to keyboard keys by the mouse driver, I believe.
Note that the movement actions only support single keys, not combos using the modifier keys. Other actions do allow modifier combos, however. This is an Unreal Engine limitation; movement and camera actions are treated slightly differently in their input scheme.
[color=#ff0000]Tech Team [/color]