There is a small bug with this mod causing a compatibility problem with Draggable Pip. In live_game/init.js, you have this; Code: $(function () { ... }); but it should be this; Code: (function () { ... })();
The way you suggest seems to work so I've changed it, v1.5.2 on pamm. For my own knowledge, how did the old way cause a conflict?
Mods are already wrapped inside a jQuery closure, as far as I know. You can get some unexpected behavior by doubling up on them. In this case, it was causing some of the code in my own mod to not execute. I'm not really sure of much more than that.
I'd have to read the respective mods, but mostly likely $() is causing deferred execution, which may change the relative ordering of mods. I'd also have to read into the jQuery source to verify that though.
Can we get an option to have this mod on by default? I really never want it off, I see no reason for it to be off.
I'll add that, and some options for showing/hiding bits of the live_game ui in the next update. And rename the t1 tank to 't1 tank', screw updating every time there's a rename Hopefully out in the next few days, just need to find an hour or two to implement.
Feature request: The autobuild doesn't show up when in spectator mode. Really annoying to try and remember to activate and deactivate it depending on whether I'm building or casting.
I see what you mean, I'll find out how to determine spectator-ness and put it in the next build if it's ready by then.
After you figure it out, please write a post/thread about how to detect it and hide the mod when spectating. (I'm feeling so too lazy to read the source of the mods that do it already. )
And here I was hoping you posted telling me how to do it edit: this line from PA Stats Live Charts seems to use a ko variable to determine spectator-ness:
Oh well. I did it anyways. I see you did too. You can also wrap it the same way as live_game.html does for div_player_list_panel: Code: <!-- ko ifnot: model.isSpectator --> your mod's html is here <!-- /ko -->
Updated to v1.6. New in this version: New option in settings menu to have auto-build enabled by default New option in settings menu to turn live_game UI on/off Hide live_game UI when in spectator mode Instead of saying 'Enable Automated Build', the button now says 'Enable Auto-Build', to take up less space I noticed a few rare pa.exe crashes when changing settings constantly to test, occurring more often when noblackscreens is disabled. Hopefully this is a global problem that gets fixed instead of something to do with this mod (I've checked the code, doesn't seem like I've done anything wrong). noblackscreens seems to help a lot, strongly recommend.
Not the ui button, but I do switch between using auto-build and the hotkey depending on my mood and the situation. The hotkey can be viewed as a 'limited conditional build' button, a counterpart to auto-build which can be viewed as 'infinite limited conditional build'. Which brings the next obvious mod idea to mind, proper conditional build buttons. Maybe find a modifier key not in use (if there is one, ctrl and shift are used, what about alt?), to add functionality to the existing buildbar ('build if some condition user has set in the settings menu has been met').
sorry to be a wet blanket.... but am I the only one that thinks this mod gives an unfair advantage? i certainly wouldn't want to play vs. someone with this mod, if I don't have it. I think it's circumventing a key element to the game - that being managing your resources and factories. (if i'm keeping you on the defensive enough to forget about queuing up build order for your factories, why should you have a safety net?) I'm surprised that this discussion hasn't been had yet - I was totally expecting to find it, and didn't. I think it's a discussion that needs to be fleshed out. no doubt this is going to be an unpopular viewpoint (especially in this thread!) but tell me; why am I wrong? please feel free to flame away, I've got thick skin.
I so far don't use this mod because I think I have more control about what happens if I do it myself. I might be naive and actually forget it all the time dunno. But in general I'd say every player who wants to be competitive should read up on UI mods that can improve the way he controls the game. It's part of being a good player to select the best UI features to win. The only issue is if a mod fundamentally changes the way how the game is being played. So i.e. a mod that perfectly automates something in a way that no human could possibly achieve by hand and thus drastically changes the gameplay. In those cases however usually the gameplay should be looked at first: How can we change it so the mod does not break it anymore? I am thinking i.e. of a mod that perfectly manages pause/unpause on individual units to allow a much better usage of energy in case of metal stalls. So far it's only very hard to do API-wise, so nobody has written it. But once it has been written (I am confident it could be written with the current API, but it would be a bit of work to do and would be likely to break with patches, so it's not worth it do to it now to me) Uber will probably have to rethink the concept of prorating energy usage in case of metal stalls, because the mod would basically be able to simulate just that.
wholeheartedly agree. yes. It's your funeral not to use it. the same could be said for hotbuild, area controls.... in my perspective they are on the exact same level. I recommend you check the list of UI mods that became stock on FAF.
