[Official] We Need Your Help - Launcher Ideas
- Thread starter unv_annihilator
- Start date
-
The FTB Forum is now read-only, and is here as an archive. To participate in our community discussions, please join our Discord! https://ftb.team/discord
You're allowed to mention the launcher, no problems there.
Do you mean it shows a preview of the players skin when that player is selected?
I believe Shevron is talking about the Technic launcher, where it displayed the front view of the character, and the ATLauncher:
At the bottom, where you select your profile, it also shows the face of your character.
And obviously in the corner, same deal, face of the skin in the corner. Also, on the old Technic launcher, before FTB, they displayed the full skin.
You guys n' gals do an absolutely AWESOME job at keeping the Item and Block ID's sorted out with very few glitches in your modpacks... and I've read thru this entire thread and nowhere have i seen this suggested:
Optimizing the KEYBINDS!!!
whenever i download ANY FTB Modpack i have to spend quite a bit of time trying to fix the keyboard layout to minimize keybind conflicts with just the mods that show up on the options>>controls tab and that is even BEFORE i change the pack in anyway at all!. and sometime you guys change it from version to version without telling us and we have to flounder around trying to find the new keys... (eg: the DW20 minimap, if i remember correctly, and we only found out about the new keybinds from watching one of his Let's Plays where he talked about it)
what i would like for you to start doing is to either go thru the list of mods in the modpack that have added keys and sort them out, just like you do for the block/item ID's, and/or at the least have all the (default) keys from ALL the mods in the pack listed in a config file or something similar that we can edit to our liking with the ability to to use multi-key combos, or keyboards with more than the standard 104 keys . the only other mod I've seen that can do that kind of stuff for keybind configuration, isn't completely compatible with Forge, so i don't use it because of the hoops I'd have to go thru to just load the bloody thing in order to actually use it... And, granted i may not use the same key to do the same thing as you and one of us would have to change (i change the button and continue as normal, or i keep your button and relearn what one to press to do xyz function), but i think it would help to establish a baseline for keys so that they don't get overridden by multiple mods at the same time (the M and N keys are VERY popular) and we have no idea what mod they are from in order to reset them to something we DO use... While the recently added mod WAILA has been a TREMENDOUS help to me when trying to figure out what key goes to what mod but it's not really good for DE-conflicting the actual keybind conflicts themselves, ya' know? so it's of limited use in this manner.
Optimizing the KEYBINDS!!!
whenever i download ANY FTB Modpack i have to spend quite a bit of time trying to fix the keyboard layout to minimize keybind conflicts with just the mods that show up on the options>>controls tab and that is even BEFORE i change the pack in anyway at all!. and sometime you guys change it from version to version without telling us and we have to flounder around trying to find the new keys... (eg: the DW20 minimap, if i remember correctly, and we only found out about the new keybinds from watching one of his Let's Plays where he talked about it)
what i would like for you to start doing is to either go thru the list of mods in the modpack that have added keys and sort them out, just like you do for the block/item ID's, and/or at the least have all the (default) keys from ALL the mods in the pack listed in a config file or something similar that we can edit to our liking with the ability to to use multi-key combos, or keyboards with more than the standard 104 keys . the only other mod I've seen that can do that kind of stuff for keybind configuration, isn't completely compatible with Forge, so i don't use it because of the hoops I'd have to go thru to just load the bloody thing in order to actually use it... And, granted i may not use the same key to do the same thing as you and one of us would have to change (i change the button and continue as normal, or i keep your button and relearn what one to press to do xyz function), but i think it would help to establish a baseline for keys so that they don't get overridden by multiple mods at the same time (the M and N keys are VERY popular) and we have no idea what mod they are from in order to reset them to something we DO use... While the recently added mod WAILA has been a TREMENDOUS help to me when trying to figure out what key goes to what mod but it's not really good for DE-conflicting the actual keybind conflicts themselves, ya' know? so it's of limited use in this manner.
Last edited:
Random idea that rates as "nice to have" (but also might be bloatware, I admit): a "beta" flag for first initialization, linked to the modpack's version. When this flag is YES, rather than immediately launching, the following dialogue box pops up:
"This is a BETA modpack release. BETA modpack releases are for testing and evaluation purposes. As such this pack does contain bugs, imbalances, and other issues up to and potentially including the summoning of Cthulhu from R'lyeh to devour your system and/or soul entirely. The FTB Team accepts no liability for any or all of this happening. BY INSTALLING THIS PACK VERSION YOU AGREE THAT YOU ARE OKAY WITH THIS."
And then you have the choice of buttons:
(Additional capability to modify the message on a per-pack basis might also be nice to communicate particular between-pack issues like the recent TE duct update requirement. I'm just particularly weary of people running around screaming about "poor testing" when they are in fact opting in to be the testers when they download certain packs.)
"This is a BETA modpack release. BETA modpack releases are for testing and evaluation purposes. As such this pack does contain bugs, imbalances, and other issues up to and potentially including the summoning of Cthulhu from R'lyeh to devour your system and/or soul entirely. The FTB Team accepts no liability for any or all of this happening. BY INSTALLING THIS PACK VERSION YOU AGREE THAT YOU ARE OKAY WITH THIS."
And then you have the choice of buttons:
- "Yes, I understand and accept the risks." - Initializes downloads and makes the dialogue window go away for this specific pack & version in the future.
- "No, I'd rather not take the chance." - Cancels initializing and the window still appears for this pack & version in the future.
(Additional capability to modify the message on a per-pack basis might also be nice to communicate particular between-pack issues like the recent TE duct update requirement. I'm just particularly weary of people running around screaming about "poor testing" when they are in fact opting in to be the testers when they download certain packs.)
What I would really appreciate, and perhaps the support team might possibly too, is an option to switch the LWJGL version for the new modpacks. At the moment the version is hardcoded to 2.9.0 and due to the /very/ changed way of launching the 1.6.4 modpacks (See here: http://pastebin.com/AG9SJXL5 in case you're a curious reader and not a dev who already knows 
), changing to a different LWJGL version becomes /extremely/ tedious. This is relevant because 2.9.1 fixes a bunch of stupid bugs in LWJGL. One might also wish to extend this to the other libraries used.
If that's not an option: Maaaaaybe switch the hardcoding to 2.9.1?
), changing to a different LWJGL version becomes /extremely/ tedious. This is relevant because 2.9.1 fixes a bunch of stupid bugs in LWJGL. One might also wish to extend this to the other libraries used.If that's not an option: Maaaaaybe switch the hardcoding to 2.9.1?
Generally FTB doesn't change what Mojang's set up, and it's Mojang that chooses the LWJGL version. It's possible, but adding a different version with FTB would mean FTB has to deal with any problems that version might have with the vanilla part of Minecraft. At the moment, if there's a bug between Minecraft's code and LWJGL, it's Mojang that handles that.What I would really appreciate, and perhaps the support team might possibly too, is an option to switch the LWJGL version for the new modpacks. At the moment the version is hardcoded to 2.9.0 and due to the /very/ changed way of launching the 1.6.4 modpacks (See here: http://pastebin.com/AG9SJXL5 in case you're a curious reader and not a dev who already knows
If that's not an option: Maaaaaybe switch the hardcoding to 2.9.1?
Thing is, Mojang won't magically come around and make e.g. a 1.6.4b release to update LWJGL. Which is also what lead to the creation of this article from support:
http://desk.feed-the-beast.com/inde...lack-screen-does-not-load-after-splash-screen
Granted, this involves MC 1.5.2 and LWJGL 2.9, but people have still had issues after updating to 2.9, especially on Mac OS X. LWJGL 2.9.1 fixes those. Furthermore, the new Mojang launcher has the ability to independently update LWJGL, which means Mojang /has/ already fixed it, kind of. That's why I've suggested this feature - and you could of course preclude the feature with a big fat warning text.
http://desk.feed-the-beast.com/inde...lack-screen-does-not-load-after-splash-screen
Granted, this involves MC 1.5.2 and LWJGL 2.9, but people have still had issues after updating to 2.9, especially on Mac OS X. LWJGL 2.9.1 fixes those. Furthermore, the new Mojang launcher has the ability to independently update LWJGL, which means Mojang /has/ already fixed it, kind of. That's why I've suggested this feature - and you could of course preclude the feature with a big fat warning text.
I wasn't aware the new launcher could update LWJGL, interesting.Thing is, Mojang won't magically come around and make e.g. a 1.6.4b release to update LWJGL. Which is also what lead to the creation of this article from support:
http://desk.feed-the-beast.com/inde...lack-screen-does-not-load-after-splash-screen
Granted, this involves MC 1.5.2 and LWJGL 2.9, but people have still had issues after updating to 2.9, especially on Mac OS X. LWJGL 2.9.1 fixes those. Furthermore, the new Mojang launcher has the ability to independently update LWJGL, which means Mojang /has/ already fixed it, kind of. That's why I've suggested this feature - and you could of course preclude the feature with a big fat warning text.
Don't take me as an authority on this by any means, I was just putting forward a possible reason why the launcher team wouldn't want to do this. I'm not on the launcher team, nor am I involved in any of their discussions.
Considering the amount of work going into the new launcher, I wouldn't be surprised if an option to update LWJGL wasn't built into that. I wouldn't hold my breath for that feature in the current version of the launcher though.
Negative. That article was written when updating LWJGL to 2.9 OR downgrading to Java 6 were the only ways to get macs to play.Thing is, Mojang won't magically come around and make e.g. a 1.6.4b release to update LWJGL. Which is also what lead to the creation of this article from support:
http://desk.feed-the-beast.com/inde...lack-screen-does-not-load-after-splash-screen
Granted, this involves MC 1.5.2 and LWJGL 2.9, but people have still had issues after updating to 2.9, especially on Mac OS X. LWJGL 2.9.1 fixes those. Furthermore, the new Mojang launcher has the ability to independently update LWJGL, which means Mojang /has/ already fixed it, kind of. That's why I've suggested this feature - and you could of course preclude the feature with a big fat warning text.
It was edited to reflect the changes Mojang pushed with vanilla.
ok, after some meddling with the launcher lately, I have a couple of recommendations, may have been mentioned in some way already but I guess this would only reinforce them;
- add custom mc profile support, in some way, or at least allow the ability for liteloader to be injected to an existing pack, used to be done via instMods but as of mc1.6 its profile-based and modifying the base 1.6 profile in the launcher doesn't really work at all, probably add a profiles section in the options tab, (1.6.4 + forge would be default), ability to add custom profiles, and in the "edit modpack" window you can add a second tab that allows you to change the profile it uses from the default.
- shift mods/common mods to a database, would be very simple to set up, packs could still use their own mods and config files but also define info for what common mods it uses in the database, of which the launcher when downloading just grabs these mods alongside the pack file, it would at least be a start for a full-dynamic system.
mod data could be like so;
--list;
>>--modname;
>> >>-- version/s, ones that are commonly in use (or just add them in when a pack needs a different version), these link to the actual files
an extra advantage to this, you could add permission info to the mod alongside its list of versions, for if it has public or private permission, if additional requirements are needed, etc.
I know a lot about servers and databases, so if you want more you could try asking me if I'm not too busy with other things or otherwise trying to make my own mc mod/s, otherwise keep up the good work.
- add custom mc profile support, in some way, or at least allow the ability for liteloader to be injected to an existing pack, used to be done via instMods but as of mc1.6 its profile-based and modifying the base 1.6 profile in the launcher doesn't really work at all, probably add a profiles section in the options tab, (1.6.4 + forge would be default), ability to add custom profiles, and in the "edit modpack" window you can add a second tab that allows you to change the profile it uses from the default.
- shift mods/common mods to a database, would be very simple to set up, packs could still use their own mods and config files but also define info for what common mods it uses in the database, of which the launcher when downloading just grabs these mods alongside the pack file, it would at least be a start for a full-dynamic system.
mod data could be like so;
--list;
>>--modname;
>> >>-- version/s, ones that are commonly in use (or just add them in when a pack needs a different version), these link to the actual files
an extra advantage to this, you could add permission info to the mod alongside its list of versions, for if it has public or private permission, if additional requirements are needed, etc.
I know a lot about servers and databases, so if you want more you could try asking me if I'm not too busy with other things or otherwise trying to make my own mc mod/s, otherwise keep up the good work.
on Mac's we use version 2.9.1-nightly-20130708-debug3 of LWJGL
edit: on windows we use version 2.9.0
edit: on windows we use version 2.9.0
Could there be a higher-definition icon for the console and launcher? I have a dock that loads 48x icons, and it appears blurry.
(the glitched crafting table is a vanilla problem that's been there since 1.6 vanilla came out, I'm guessing it's outside the control of ftb?)
(the glitched crafting table is a vanilla problem that's been there since 1.6 vanilla came out, I'm guessing it's outside the control of ftb?)
The crafting table is there in vanilla too, so I'm guessing it's part of Minecraft and can't be changed by FTB launcher, only Mojang or a mod.
Well, in /minecraft/assets/virtual/legacy/icons there are files of icon_16x16.png, icon_32x32.png, and minecraft.icns, you could change the image to change the icon quite easily.
I thought the vanilla launcher (which, correct me if I'm wrong, the FTB launcher integrates somehow?) overwrites changes like that whenever it runs? Or does it ignore certain folders?
Though whatever icon size it's loading, it's getting corrupted to oblivion on the way over regardless
I've basically given up hope for that icon at this point - that being fixed depends on Mojang actually looking into and fixing the bug. And considering how long it took them to fix the linux launching problem (a game-breaking one at that) for 1.7, I'm not holding my breath.
I was more focusing on the FTB icon for that post anyway.. I know I can modify the FTB jar locally but at the end of the day it's just a band-aid solution that'll have to be re-done every time it updates. :/
It's not like it's as bad as having the default java icon showing up or whatever, but it's enough to be pretty conspicuous and a bit annoying.