As far as I know - although I don't know too much about this topic - the MWLL actionmaps is a superset of the Crysis Wars actionmaps. This means that both Crysis Wars and MWLL should be able to operate with the same profile. Naturally, if the user changes anything in the actionmaps within Crysis Wars, the MWLL actionmaps settings will be lost (as actionmaps.xml is re-generated), and effectively the MWLL control settings (the ones that are not present in Crysis Wars) are reset to default. At least, that's my theory.
I tested your theory, as well as mine. It turns out the profile files (
actionmaps.xml,
attributes.xml,
profile.xml) are rewritten as soon as they are loaded. I think the game simply reads then dumps the XMLs in order to ensure their conformity. I would have thought Crysis would keep the unused sections intact (e.g. "aerospace" when under Wars, "seavehicle" when under MWLL) but it doesn't; they are mercilessly deleted. It's harder to figure out what happens exactly to the common sections, because oddly enough the same actions aren't always rewritten in the same order for Wars and MWLL. I think they're all reverted to default too.
I'm sure of that much: a new profile created with MWLL then loaded with Wars will be identical to a newly created Wars profile, and vice versa.
So the active profile is set globally, not per mod, and the actionmaps is reset as soon as it is loaded. That's basically the worst possible case. Launching Wars
will destroy your MWLL profile.
Add to this the fact that the linux dedicated server is unable to load mods, and mod support for Crysis now really looks like an afterthought.
Such users indeed wouldn't be detected as first-time players, which is not very good, but it isn't tragic either. I honestly have no idea at this point as to how to solve this issue.
Actually, there's a pretty simple way to tell a MWLL profile from a vanilla one: look in
actionmaps.xml for a line matching " <actionmap
name="mech" version="19">".
But it wouldn't help in the case of a user creating a profile in vanilla Wars first in order to join a server and avoid gamespy/key issues within MWLL. There would be no way for the launcher to tell that this profile is intended for MWLL use, at least not until some kind of DirectMind
® API is released... but that would leave out XP users anyway
.
So yeah, back to:
I honestly have no idea at this point as to how to solve this issue.I'm a lot more concerned with existing players unable to run the Auto Updater, for instance.
Of course, that's the priority. But there is nothing
I can do about that. Until I'm hit by such a bug, then I'd be able to report my issues... but I'm not specifically looking forward to this ^^.
What I can do is nitpick over UI details, and mull over trivial features. I think that's within my reach, I'm giving it my best! And if done right, it
might save you devs some time thinking about those petty things. Time you can then waste on implementing them. My plan is
almost perfect.
I don't really understand what you're suggesting here. The Actionmapper is distributed along with the other MWLL Tools, like the Launcher and the Auto Updater. It doesn't bring a new default_actionmaps.xml with it
Actually, it does, though it's named
actionmaps_default.xml. It's zipped inside Actionmapper.jar, and is the file used to create new actionmaps.
Quoting the previous changelog:
Actionmapper
- Cross-tab conflict detection added.
- Missing actions from older actionmaps no longer require a new actionmaps to be created, instead it will be added automatically once user tries to bind the new action.
- Added a label that shows up when modifications are made indicating the user must restart MWLL for changes to take effect.
- Default actionmaps missing actions added back in.
- Default actionmaps conflicts corrected (e.g. "c" key flushes coolant in Vehicle and no longer pitches up in Aero also).
- Spectator actions no longer show conflicts with non-spectator actions if bound to the same key.
- Added missing action for 'Target Nearest Friendly'.
That embedded default actionmaps received a bunch a small improvements, but you need to use the Actionmapper to benefit from them. A new player installing 0.5.1 would probably play right away, trusting the default controls. Then he'd try out ASF, fly at low altitude and flush coolant. Surprise!
The default controls work quite well
(*), so not everyone will feel the need to tweak them right away and generate a new actionmaps. But as they can and do get refined over time, new players are missing out on the improvements. In the past, the mod's
default_actionmaps.xml and Actionmapper's
actionmaps_default.xml weren't always synchronised. Now that the Actionmapper is updated separately it will happen more often, and since Tools updates are more easily released it would make sense for it to also keep
default_actionmaps.xml up-to-date. That was the reasoning behind my suggestion.
Now, I understand the reluctance about modifying the
default_actionmaps.xml as part of tools releases. Synchronising the two files for each "minor" mod update should be enough then, but I'll suggest a small change. When loading a "fresh" profile with the Actionmapper, a message box is shown saying "Since it appears to be the first time using Actionmapper for this profile the original actionmaps has been backed up and named 'original'.". That message could be expanded to recommend the creation of a new actionmaps, which would ensure the use of the latest defaults.
[On a completely unrelated subject, if any expert in orthotypography can tell me how I should have handled that
'.". sequence, I'm interested. I mean, WTH?]
* I tend to believe the eject key bound to F by default is actually a clever ploy to prompt players to use the Actionmapper. It works! It's also pretty effective at giving away newbies. Often a very dead giveaway.
More seriously, that's the only control I
have to change to play, I'm pretty sure it can be improved.
I think the
Eject functionality should split away from
Use / Get in. It is a destructive emergency measure that has little to do with picking up a weapon or hopping in a vehicle. A dev opposed this idea saying different keys to get in and out of an asset wouldn't make sense and confuse people. Both are valid opinions, there must be a way to reconcile them.
Let's define "ejecting" as getting out of a powered up vehicle, whether the ejection mechanism is active, blown up or non-existent (the league cvar might follow a slightly different definition). The current action would be renamed
Use / Get in / Get out and allow getting out of a powered down vehicle, thus partly (mostly?) solving the consistency problem. At this point, it would be possible to bind the two actions to the same key without conflicts, and emulate the current behaviour. Or bind them to different keys, and benefit from both an easily accessible key to enter assets (and leave them in non-combat situations) and a "hard to hit by mistake" one for ejection.
It would also make sense for the
Eject key to allow getting out – in a non-explosive manner – of a powered down asset. But this would potentially conflict with the
Use action, if bound to the same key. If the engine can gracefully handle that, then I can't find any downside to this suggestion. Which I realise isn't related to the Actionmapper – I'm getting a bit sidetracked here.
It doesn't appear to be a serious issue (for me, that is) at all. In my opinion it's always better to let the user exactly know what's going on and if possible, give them a choice. What I mean is: make user choices explicit. This may feel inconvenient for you sometimes, but I do believe that it also potentially helps a lot of users keeping up with what's the program is doing.
But it is not a
serious issue, I never stated or thought that. On the other hand, I don't think a proposed fix or feature has to be related to a serious issue to be worth looking at either. I noticed that potentially unnecessary step since the Actionmapper was first released with MWLL, but I only bothered to post about it now, and not really out of a sense of urgency.
I can't agree more with you on the subject of user choice and information; I'd rather have too much control than not enough. Too much information can be inconvenient at times, but it's not as frustrating and infuriating as some software doing as it goddamn pleases. Arguably a matter of temperament. I screwed up a Debian install once, it led to lots of fun – the Dwarf Fortress definition of "fun". I also learned quite a bit from that. My Windows partition is named F: and only Gates knows why. I guess I learned XP's installer is still stuck in the 80s.
So while I agree with you on the general principle, in this case it's a recurrent choice that isn't likely to change often and has no ill effect (as it is possible to switch profile right away without modifying anything). And that's exactly how Crysis itself handles profiles anyway: it picks one, displays its name at the top of the screen, and offers a menu to switch.
About the displayed name: I was about to suggest in my previous post that the Actionmapper should do the same... before realising it already does. It's legible, it's in the right place, but somehow it didn't register.
I think it's all the more important to give user feedback when implicit choices are made. Maybe it's the relatively low contrast with the grey background, maybe it's the alignment with the tabs, or maybe it's just me, but it couldn't hurt to make the selected profile name more obvious. By putting it in bold, adding it to the title bar...
The more I think about it, the more I believe it's just me though
.
