Page 2 of 2 FirstFirst 12
Results 16 to 22 of 22

Thread: Current Development Status and Future Plans. Your Feedback Requested

  1. #16
    Administrator
    Join Date
    Sep 2005
    Posts
    353

    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!

  2. #17
    Administrator
    Join Date
    Oct 2019
    Posts
    497

    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.

  3. #18
    Did you SEQ today? BlueAdept's Avatar
    Join Date
    Dec 2001
    Posts
    2,005

    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.
    Filters for ShowEQ can now be found here. filters-5xx-06-20-05.tar.gz

    ShowEQ file section is here. https://sourceforge.net/project/show...roup_id=10131#

    Famous Quotes:

    Ratt: WTF you talkin' about BA? (Ok.. that sounds like a bad combo of Diffrent Strokes and A-Team)

    Razzle: I showeq my wife

  4. #19
    Administrator
    Join Date
    Oct 2019
    Posts
    497

    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.

  5. #20
    Did you SEQ today? BlueAdept's Avatar
    Join Date
    Dec 2001
    Posts
    2,005

    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.
    Filters for ShowEQ can now be found here. filters-5xx-06-20-05.tar.gz

    ShowEQ file section is here. https://sourceforge.net/project/show...roup_id=10131#

    Famous Quotes:

    Ratt: WTF you talkin' about BA? (Ok.. that sounds like a bad combo of Diffrent Strokes and A-Team)

    Razzle: I showeq my wife

  6. #21
    Administrator
    Join Date
    Oct 2019
    Posts
    497

    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).

  7. #22
    Administrator
    Join Date
    Oct 2019
    Posts
    497

    Re: Current Development Status and Future Plans. Your Feedback Requested

    Quote Originally Posted by cn187 View Post
    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.

Thread Information

Users Browsing this Thread

There are currently 2 users browsing this thread. (0 members and 2 guests)

Posting Permissions

You may post new threads
You may post replies
You may post attachments
You may edit your posts
HTML code is Off
vB code is On
Smilies are On
[IMG] code is On