|
|
20190509055914_1.jpg (168,368 bytes) |
|
|
Yep, that part is really borked still even after the current hotfix. I spent several hours chasing that down yesterday and will look into it more today. It's a very tricky one! In prior builds it wasn't throwing the error, but was just having it silently. Now you at least can see when it breaks, which is an improvement over silent badness. |
|
|
Are we sure we just aren't trying to seed more units than the seeding code will allow? |
|
|
Yes, it has to do with the state of the Setup object getting reset. Some of that is a race condition, and the rest of that is it taking erroneous commands from dropdowns that are cleared and then reset. Basically the data is heavily, HEAVILY tied into the gui at the moment, which is always bad juju. The behavior of dropdowns changed a bit, and possibly something else did as well (I thought I knew what but I don't), and so it kind of goes nuts and loses track of things. It winds up working with an earlier copy of the Setup object that was transmitted across the network loopback 2 seconds ago, etc. It's also firing off tons of map generation commands when you adjust the UI in general, versus having any sort of abstraction of that prior to doing a real population. I never have been a fan of that approach, because it makes everything feel laggy for no good reason. Anyway, I think it's actually managing to scramble those threads and have multiple at once, or they set their Setup data very late in the process, I'm not sure. Either way it's causing chaos. It's less that I don't understand what is broken now (I don't per se), but I don't understand how this was ever working at all. ;) I'm not trying to be overly harsh, but I have had this on my hitlist for a while now, as well as have been avoiding it, for a good reason. Even knowing exactly what will work best for multiplayer purposes is kind of hard at the moment, though, because Keith had some really good points with why he did it this way. So I've been learning as much as I can about the good side of things here, and then prepping for my coming redo. Overall my intent is to move to a sort of abstract data layer that exists independent of the game itself or the UI, and is just there for the setup phase. And that gets tweaked and the UI reacts to that. I'll still have some of the same problems with the dynamic UI causing extra messaging with that, but at least it won't be firing off a bunch of network events and long-running map processes to complicate it. And I can build in a "don't listen to my changes right now, because I'm just being set up" phase, or possibly move to a more polling-oriented approach rather than event-driven. I'd kind of like to do that, but we'll see. The reason is that sometimes during that thrashing-around setting up of dynamic fields, it's actually setting defaults from the player profile or some other data source (defaults from the xml that might not be the first item), and those things might not be properly reflected in the data if I'm not careful with how that syncs with the UI. Sooo... yeah. It's totally a casualty of the way the lobby is designed paired with changes to how the network, mapgen, and/or dropdowns work. The game itself is doing fine, but trying to make this multiplayer-compatible while also juggling the other things has been some mental exercise for sure. |
|
|
I'm glad it's your problem and not my problem ;-) |
|
|
Fixed in the next build, thanks! |
- Anonymous
