Patch 3680 Beta Preview

[IceDreamer]

If you're here from the What's New post or DevBlog, welcome. If not, please head over to one of those to read about what's going on.

This thread is for people to report things that are bugged, broken, or just general feedback about the upcoming patch 3680. Please keep it cordial, I do NOT want to have to get someone to delete posts if a flamewar breaks out.

You can find the changelog for the patch here. Please note, as I get feedback, this list might well change. The link will keep working.


Why does the changelog skip out 3677/78/79?
When this patch was coming together, it seemed likely that JaggedAppliance would launch a balance patch taking the /78 slot (We work in even numbers to keep room for hotfixes). There's still time before this ships, so it's possible he will still decide to do that. Even if not, this is a big enough patch it deserves a round patch number

Have fun testing guys!

[IceDreamer]

Mention Hydro in the "Fixed adjacency visual effect being placed on the water surface when dealing with underwater mexes" line of changelog -- DONE
Possible game freeze when crashing bombers into joint of shields -- DONE

Just reminding myself for later

[keyser]

"conflict" with EM
when you use upgrade on "click", and the feature "Assist-Mex-To-Cap".
the commander will upgrade the T2 mexx to T3 before building mass storage.
Consider making 1st assist build mass storage, and a 2nd assist order would allow to assist to T3.

[PhilipJFry]

not sure if that would be a good idea keyser since that would mean that you will build storages upon supporting a t2 mex that is upgrading to t3 even if you want to rush it to t3 first

[CookieNoob]

general feedback:

"making modding easier in the future" is the worst possible motivation for moving these files (modding doesnt get easier by this at all, its just putting some files at some other spots). Especially when you consider that it breaks over 300 mods (counting old versions it is in total 337) including notify, nomads, equilibrium, UI party, 4th dimension, additional camera stuff, ally overflow, blackops, ecomanager...

Since the real motivation is "improve code quality by separating UI and SIM modifying files", I highly suggest that you consider that the player in general doesnt care about having UI and sim files in the same folder, breaking all their UI and some sim mods however is a different story... This is a similar situation as it was when the server was transfered. The official perspective was "everything is better now" when in reality it introduced a lot of problems (which are still not fixed, i.e. map/mod upload in the python client...). The problem with this is that you do a (totally unnecessary) change and then dont care about cleaning up afterwards.

My point about that is: IF you really want to move these files, make sure ALL of these mods will get the necessary adjustments. I fixed nomads already for that (will require a simultaneous update), but I really dislike this change considering how much it breaks. I suggest to take this change back and not move these files around.

[keyser]

not sure if that would be a good idea keyser since that would mean that you will build storages upon supporting a t2 mex that is upgrading to t3 even if you want to rush it to t3 first

i consider that you wanna build mass storage 1st more often than T3 mexx.
atm you can't use the feature if you do upgrade on click and want mass storage most of the time.

maybe we can thing of a way to upgrade also T3 mexx in some case like "ctrl + assist" = upgrade straight up to T3. Idk, we can try to be creative. But first point still stand.

[IceDreamer]

It's a valid concern, but that's exactly why I launched this preview period. Looking at the list of mods affected, I estimate that fewer than 20 will need to actually be adjusted. This is because a huge slew of them are very, very old beta test mods, proof of concepts, and other such things used by devs over the years.

To this end, I'm going to be getting server data on download totals, recent downloads and where possible use statistics. It's also an easy fix, so I'm hopeful 90%+ of the mods can be corrected prior to release, which is still a few weeks out.

A final decision will be made on whether or not to proceed after a week or so of feedback. and once I have more of the necessary data to make a real judgement on how much disruption this might cause.

[IceDreamer]

Regarding EM conflict: I think it's probably most important to preserve UI Mod behaviour (Which is a choice to turn on) ahead of game behaviour. That is, it needs to be easy to have a simple upgrade route for those with the mod on. There are two ways to do this:

1 - Make the mod's version always take priority. This is the current state, and has generated concern, since the mod's version isn't always the best option. Normally I'd say "Turn off the mod then" but this is one small part of a much larger mod.
2 - Change the way the mod works, so that default game behaviour is preserved AND mod actions are slightly shifted. Keyser's example of using ctrl-click is a good one. Interestingly, as EM is one of the mods that will need modifying for /modules, this could be done at the same time.

[Ithilis_Quo]

reading changelog it looks like lot and lot of equilibrium code was moving into this patch. what is particulary good, but it should be mention somewhere .)

- shield bouncing
- transported unit wreack
- harms
- auto oc stop working
- shield stop button
- mass storage
- sacu incorect tooltips

its all was in eq for more as year,
and another code is still w8ing for integrating

[PhilipJFry]

the thing about sacu tooltips was a pr from me that i told exotic about iirc

Spoiler: show

also by far the most challenging and most important change in that list