Forum Replies Created
-
I got the 64 GB model as the OS itself takes up ~23 GB, which wouldn’t have left a whole lot for the cache and other stuff.
The size of the display is a nice fit for me: not too large and not too big. I do have trouble with the onscreen keyboard but I have trouble with that feature everywhere. I just never got the hang of typing on a screen, is all.
No Bixby on this one. The A7 Lite is actually a pretty bare-bones unit, just has Knox. No bloatware, either. The 23 GB is for the operating system alone. They never should have made a 32 GB model of the A7 Lite due to the storage limitations.
Looks like the CPU is much weaker and includes a much weaker GPU, which would probably explain why it’s a tad slow on images. 😛
Also, browsing images tends to drain the battery life faster. Battery life isn’t bad but it does tend to have to be recharged more often when I’m using it for actual work as opposed to browsing, which is probably the result of an inefficient chipset.
That said, it’s not a bad unit at all. The issues are minor annoyances, really. It’s also really durable: I’ve dropped it a few times and the screen still shows not a scratch! Still a bit early to look for a replacement, though. Maybe in another year or two 🙂
Doesn’t look like there’s a community resource for the file formats for Fallout and Starfield. May add the resource to the to-do list at some point as it’s something that the community is sorely lacking. We need a place to describe the processes and such so that we know what all is going on and don’t rely on a singly tool as gatekeeper. We went through this when Skyrim launched initially and it was a disaster.
In any case, it was suggested that we poke through the xEdit source code for file format information. Not ideal but it seems to be what’s available. I’ll poke the Edit devs at some point and ask them for more details. Still haven’t decided how to handle the multiple game support in what I’m currently calling ESEdit, though. There are several ways of doing it so we’ll want to discuss it as we get closer to having things ready for that (we’re still a long ways off) 🙂
Edit:
CAboutDlgneeds to be split out into its own header and source as it’s currently buried inui/mwedit.h. Will do that at some point.The
scrfiles are related to the script compiler. Like I said, poorly documented. 😛At some point, I may look into replacing the parser with something like flex or bison. Not sure if it’s possible, though, as I’ve never used them before
Good catch on the text file reference. Will need to add the link somewhere for reference
0.6.3 should be usable for playing with. As we know, 0.7.0 is currently broken due to Windows API changes but the last version before the overhaul started should work.
Edit:
I’ve updated some information in a couple tracker items and closed the item for the directory structure. I forgot to do the latter when I finished it a month ago. I still haven’t gotten the hang of using an issue tracker. 😛
Figured it out, to some degree. The journal dialog is supposed to set up the quest sub-records (
QSTN,QSTF, andQSTR) with theINFOrecord. It’s possible the script stuff is meant to link it up but those are only in the parentINFOso I’m not entirely sure. We’ll definitely need to review the community documentation on the file format (and I’ll need re-learn a lot of stuff). A good starting place is the UESP’s page on it but it’s pretty short on details so we’ll want to hunt down some of the other community documentation. There are similar pages for the other games and we’ll want to hunt down reference sheets for Fallout and Starfield at some point.Also, we’ll want to add a lot of explanation to the file comments to help folks understand what each file, class, function, etc are for. The code lacks good documentation so that’s something we’ll definitely want to work on. I’ll get an item on the tracker for it!
And on the tracker 🙂
Edit:
Turns out the documentation task was already there and I just didn’t see it. Closed the new one and marked it as a duplicate 😛
Edit 2:
Not a whole lot shows up in search results so I’ll ask the Morrowind community and OpenMW folks for links to references when I get the opportunity. It doesn’t hurt to start getting other puzzle pieces together even if they won’t be used for a while 🙂
The Windows API has most of its type-defs and macros in three main files:
windef.h,winnt.h, andwinuser.h. It’s mostly a matter of searching that list for those specific ones and adding the correct header(s). 🙂 The other symbols (the classes and structs) require more work to track down, partly because search engines have gotten so bad that they can’t understand what you’re looking for anymore.Edit:
I just attached the diff between 0.6.3 and 0.7.0 so that we don’t lose sight of the crash that was introduced as the code is overhauled and so that others can share insight.
Edit 2:
Just added an item to the tracker for the visual style support. Feel free to add to it! 🙂
Edit 3:
Went ahead and reached out regarding TES3Gecko. Now to get back to fixing up the includes.
Edit 4:
ui/journal_dlg.ccis missing:void GetFuncData(const int Index, int &FuncIndex); void SetFuncData(const int Index, CEsmSubSCVR *pFuncData, CEsmSubRecord *pValue);It’s unclear whether or not these were meant to be defined in the source or if they were included in the header by mistake. If the latter, they can be removed. If the former, we’ll want to implement them. The only comment for them is for the two functions above them that get and set the control data, which are implemented in the source.
-
This reply was modified 3 months, 1 week ago by
.
-
This reply was modified 3 months, 1 week ago by .
-
This reply was modified 3 months, 1 week ago by .
-
This reply was modified 3 months, 1 week ago by .
-
This reply was modified 3 months, 1 week ago by .
-
This reply was modified 3 months, 1 week ago by .
-
This reply was modified 3 months, 1 week ago by .
Messed up the include order for several files. I’ll fix it when I go back through to add the correct headers for the Windows macros.
All of this is necessary work even if it’s tedious and not at all exciting
Still need to get an issue open regarding visual styles. Shouldn’t be hard to implement and it’ll be a nice upgrade until we switch GUI toolkits. Just been buried under tracking down all of these symbols
Haven’t given much thought to TES3Gecko either for similar reasons (or even browsed the TES4Gecko code) but were still a long ways off from even having MWEdit ready for that sort of thing
Thanks! Will try that if adding just what we need doesn’t do the trick 🙂
There are also some comments suggesting that the
longtypes may in fact be intended asshortintegers so we’ll definitely want to do an investigation to determine what they should be. Yep,std::atolwould do the trick for 64-bit integers. There’s no corresponding function for 16-bit integers so we may want to see if we can set the control to a limiter if we do in fact need 16-bit integers after the investigation just to make sure we don’t get an integer overflow or out of range bug. The other option would be to first convert them to a 32-bit integer and then check to see if they are out of range for a 16-bit one. If so, we set it to the max or min allowed for the type. The limiter would be cleaner in that case, though.Edit:
snprintf()incommon/dl_str.his almost identical tostd::snprintf()incstdiosave for the fact that the former usesTCHAR *instead ofchar *. We may be able to swap it out forswprintf()incwcharwithout issue sinceTCHARis just a type-def forwchar_t. Other changes may be doable as well but that is a 1-for-1 swap down the road.Edit 2:
Also found this doc which could be useful: https://learn.microsoft.com/en-us/windows/win32/winprog/windows-data-types
Will start adding the headers for those types as I go and will go back through later and add it to the ones I missed at some point. It’s a shame a lot of this information is hard to track down.
Ugh…those includes in
commonmay be an issue. I’m trying to avoid using WinSock entirely as MWEdit doesn’t use any kind of network code and that would cause unneeded bloat. Can be added if needed, though, if things can’t be whittled down enough.Unless I’m mistaken, shouldn’t WinSock 2 be used after the basic Windows header so it overrides the old version? Of course, as we know, most OS-specific code is arcane to me as I rarely work on code that needs to interface directly with the underlying system.
Common will be rewritten eventually. The large integer union looks like an artifact from the days where 64-bit numbers were a novelty and can probably be replaced with
std::uint64_torstd::int64_t. As for the other stuff, that’ll need some additional investigation.Trying to get the Windows code working properly is beginning to get a little discouraging. 🙁
Edit:
Just opened a task item to fix the loss of precision in the UI code. We have stuff like this:
pEnchantData->MagMax = (short)(std::atoi(Buffer));
Here’s the struct for it:typedef struct { short EffectID; byte SkillID; byte AttributeID; long RangeType; long Area; long Duration; long MagMin; long MagMax; } enchanteffect_t;Essentially, it’s converting the string first to a 32-bit integer, then casting it as a 16-bit integer, and finally storing it in a 64-bit integer. This sort of thing occurs frequently in the code. That could cause some issues. Ideally, we’d convert the string directly to the correct type so that all data is properly preserved. We’ll want to investigate things to determine the correct integer types and change the code accordingly.
Yeah, I’m not sure what the XML parser is for at the moment. Even in the other projects, I didn’t see anything that used it. From what I could tell, CSV was the only file parser that was used in the extra file support but I haven’t finished going through all of the code in detail yet (I’m currently on the undo stack support).
What does OpenMW use XML for? I must have missed that
Made some compatibility changes:
I swapped out a non-portable standard library extension with functions in the standard library:if (!(/*__iscsym(pUndo->GetChar())*/std::isalnum(pUndo->GetChar()) || (pUndo->GetChar() == '_'))) { break; }The commented function is what was there before. It was an extension to
cctypeso I removed it in favor of the combination that exists on all platforms. Minor change but I figured, “Why the hell not? I’m adding the include anyways”. 🙂Thanks. Will make a note of adding the control style commands 🙂
I haven’t been including
windows.hso we’ll see what happens with the Windows integer types (MSDN didn’t specify that I had to include that file for their type-defs). Was never a fan of how Microsoft made things more complicated than needed but we’ll get it sorted out. 🙂Unfortunately, without that flag, it exposed a known bug in the Windows API where it tries to use WinSock 1 even though it’s unneeded where MFC needs version 2 and refused to build. Release had no issues so it’s something on Microsoft’s end with the
_DEBUGflag and disabling everything extra and manually adding only the stuff we use was the only way to fix it (I hope, we’ll find out once I finish adding the headers and try to build it). Here are the details. It’s a bit of a mess. If it gets too frustrating, I may fast track ripping out the Windows API but I hope to do that later once the code quality has improved more.Where do we need to call
InitCommonControlsEx?Thanks, I’ll work on getting together the control categories in use 🙂
Looks like MinGW supports them in resource files. Not sure about standalone ones but referencing them in the resource file with
#include "winuser.h" // required for RT_MANIFEST constant CREATEPROCESS_MANIFEST_RESOURCE_ID RT_MANIFEST "application.manifest"should be fine. Not sure which method I prefer but it looks like it’ll work regardless for cross-compiling. Not sure if we’ll want anything else in the manifest. Maybe the runtime version since we’re using the newest? On Linux, that’s handled by the package manager settings file
Still need to research
InitCommonControlsEx(const INITCOMMONCONTROLSEX *picce)and figure out how that works -
This reply was modified 3 months, 1 week ago by