Re: Current Development Status and Future Plans. Your Feedback Requested
Committed a bunch of less important opcodes and fixed a few structs associated with those opcodes in the devel branch. Was bored and thinking I needed to get back into the swing of things re: opcodes and structs. You may see more spam in the console as a result. Enjoy!
Re: Current Development Status and Future Plans. Your Feedback Requested
The current batch of changes on the dev branch have been merged into trunk as of 6.1.0.0.
I'm not sure what next bits I'll be working on, but it will probably be a least a couple of weeks before I seriously start anything due to IRL workload.
Re: Current Development Status and Future Plans. Your Feedback Requested
No problem. SEQ has been around for 21+ years (Hey, it is of legal drinking age!), it can endure a couple weeks off.
Re: Current Development Status and Future Plans. Your Feedback Requested
I forgot to mention it when I did it (in late April) but I added some Qt5-related fixes to my dev branch. With those fixes, I'm able to compile against the Qt5 version that ships with Debian Buster.
If you have both Qt4 and Qt5 installed, it will prefer Qt4. You should be able to force Qt5 with configure flags, but I haven't tried it on a system with both installed.
I haven't done much testing (I haven't had time to play lately), so I can't vouch for how well anything works under Qt5, but if someone wants to poke at it and post bugs/issues, be my guest.
Aside from those Qt5 fixes, the dev branch is currently up to date with trunk. Hopefully I can dedicate some time to making more progress soon.
Re: Current Development Status and Future Plans. Your Feedback Requested
Cool. I appreciate the effort. Moving to qt4 was a huge deal! It is still widely available so the upgrade to qt5 will be when ever you get the time.
Re: Current Development Status and Future Plans. Your Feedback Requested
Notable recent updates to the cn187_devel branch:
Code:
Change fillSpawnStruct to loop through posData (based on struct size)
rather than hardcoding the fill of each element. This will allow the size
of posData to change without needing to adjust fillSpawnStruct.
Code:
Add safety check for formatted message arg sizes.
This works around a crash (due to possible packet changes) until a
proper fix can be found.
Code:
Check sessionId before processing disconnect packet
Random UDP traffic on the LAN can cause unexpectes session disconnects if
the packet payload happens to start with the SessionDisconnect net
opcode.
By checking the sessionId in the disconnect packet against the current
sessionId, we can ignore packets that look like disconnect packets but
really aren't.
This also means that users who have enabled "session tracking" for the
sole purpose of reducing random disconnects may be able to disable it if
they don't otherwise need it.
Code:
Add the ability to load multi-layer maps (e.g, SOE, Brewall's, Good's).
* On zoning, SEQ will automatically load the base zone map as well as maps 1-3
of the same name.
* The layer control on the map bottom control pane allows you to select
which layers you want to see/hide.
* Manual load/import of maps will now allow the selection of multiple files
* Saving maps will save all layers as their individual filenames
* The map edit menu now contains an "Edit Layer" setting, allowing you
choose which layer will be modified when doing map edits.
I expect the first two will go to trunk pretty quickly (along with some other minor things). Probably by the next patch to live.
The third, I'm debating whether or not we need a toggle to enable/disable this (right now the change is implemented globally). I don't think it will have any undesirable effects for single-boxers, multi-boxers that play on different PCs, or anyone that has "session tracking" enabled - it should just result in fewer random session disconnects.
However, I think it will be a behavior change that might affect multi-boxers that play multiple toons on the same PC and don't have "session tracking" enabled. But I have no clue how common this combination is.
I haven't tested how it behaves in that scenario, so it may all be moot, but in my head, I think that instead of any toon zoning causing SEQ to zone, the toon that SEQ is tracking (as Player) will have to zone in order to zone SEQ (but from there, it would be the usual race to see which toon SEQ latches onto). Part of me thinks no one will care. The other part of me remembers https://xkcd.com/1172/ so I'd be really interested to know if anyone would be bothered by this change.
The fourth, I binge-implemented this past weekend. I've done a fair amount of manual testing, but haven't put in any serious play time yet. I'd like this to sit in the dev branch for a while and have people play with it in case there are bugs/issues I missed. I think one gripe will be the map colors. I think the conversion script changed the map colors to work better with SEQ's color scheme, so trying to use the maps directly might mean the colors are hard to see. Maybe a short term solution is to rework the map conversion script to just do colors and not squash the map layers together. Longer term, it might be nice to have the map color replacement happen automatically inside SEQ (maybe as part of the color-handling changes that will be needed for supporting different color schemes/themes).
Re: Current Development Status and Future Plans. Your Feedback Requested
Quote:
Originally Posted by
cn187
it might be nice to have the map color replacement happen automatically inside SEQ
I added the color replacement for the SOE-formatted maps to the map load code. So pending any bug reports or other issues, the mapconvert script may no longer be necessary since SEQ is able to handle both multi-layer maps and color conversion. There are still color improvements that will likely need to be done as part of the theme support, but this is a first step, at least.