Jump to content
  • Announcements

    • AndalayBay

      SSL Installed   05/29/2018

      Second IP obtained. The issues with IPv6 have also been fixed, but we can't switch to HTTPS until we switch forum software. We can't switch to HTTPS without a current license with IPS.
Sign in to follow this  
Schtearn

[RELz] SKSEQuasiDebugLogTest

Recommended Posts

Version Two: Looks like more where we want to be.

The following is a guide on what settings vary in new default Win32 C++ Desktop Visual Studio 2017 Community projects...

  • Copy the SKSE common directory over to the Solution directory. A subset of the enclosed files may be used, so some header files might want to be modified. In this case, IPrefix.h had some #includes commented out.
  • Use Multi-Byte Character Set
  • Change to X64 build in Configuration Manager.
  • Additional Include Directories: $(SolutionDir)common\$(SolutionDir).
  • Precompiled Headers set to No.
  • Forced Include File: $(SolutionDir)common\IPrefix.h.

The next step is to bring the main X64 branch of SKSE into play.

Edited by Schtearn

Share this post


Link to post
Share on other sites

A job for the SKSE team (or someone else) is to convert it all to Unicode. Probably not as bad as the conversion to 64 bit, but still...

Xanderdunn's Plugin_Example3 has both extern function and export.defs. Thought only one of those was required- paranoia perhaps?

Edited by Schtearn

Share this post


Link to post
Share on other sites

For Unicode, they just need to use the wide string aware functions. Which areas are at issue there? It's a bit different for strings and input, strings being easier to handle than the IO streams (the standard library functions for IO support Unicode but it's a pain in the ass to use those facilities...).

Share this post


Link to post
Share on other sites

Yes, it looks as if after the howls of protest, MBCS is going to be around for some time to come- unless the text streams are fundamentally changed. But there seems to be very little emerging on that score.

...

To validate the testing, we will tabulate all the functions into a Listview. But not much about those in C++, so dug out an old German article- but the tables don't carry through to Markup

Share this post


Link to post
Share on other sites

The best way to handle Unicode right now is to use a sort of wrapper library, the native C/C++ facilities are so painful. They are slowly fixing it (they added support for Unicode constants in the last standard :P) but they're taking forever! I think Windows provides Unicode functions, doesn't it?

Share this post


Link to post
Share on other sites

Thanks, have a newish build, but not a lot extra in yet. Run into a snag with 

   WNDCLASSEXW wcex;

    wcex.cbSize = sizeof(WNDCLASSEXW);
.....
wcex.lpszClassName  = (LPCWSTR)szWindowClass;
.....

This is one of the drawbacks of MBCS. The lpszClassName is supposed to be in the Window Title, but all I'm seeing is the first letter "S". It's very similar to an issue experienced by this poor individual 8 years ago. Guess that WNDCLASSEXA would solve, but that has its own pitfalls as well. Or shooting for another way the window title can be set anyhow . Here's the log: SKSEView.log

 

Share this post


Link to post
Share on other sites

Thanks for looking. :)

I really should filter the log- it's full of winsock & winioctl crap that MS (or someone not me :P )should fix .

Yow, should have researched more- the DefWindProc was wrong. It's little things like that that may have caused issues with Bigger Directories. Will have to recheck that.

The issue with Peek Definition is acknowledged- but not holding any breath for a quick fix any time soon. There's a whole lot of other more important tickets in the queue, but they update quite often.

 

Share this post


Link to post
Share on other sites

It's okay now, thanks. But a question, in WindowsProject2 it was possible to easily call the SKSE (or was it Boost) function DebugLog only if a subset of the Common files were specifically included as source files.

  • IDataStream.cpp
  • IDebugLog.cpp
  • IErrors.cpp
  • IFileStream.cpp
  • IPrefix.cpp
  • ITypes.cpp

and corresponding header files.

But the rest of SKSE? Don't know if that can be done without breaking its entire structure- but thinking that invoking something like "Pathtofile\Some SKSE Function" would be great if possible. 

Humour me, just want to try a few things other than the standard method of importing.

...

Are you using VS2017? Here's the rulesets drop-down list- cool, but you can only pick one. Other than that it's a bit of a rigmarole defining your own- something for the VS team to improve?

Rulesets.jpg.b8e50abb40441da7b65a811cc3739a16.jpg

Edited by Schtearn

Share this post


Link to post
Share on other sites

Most of the rest of **SE isn't standalone but some of its file reading headers can be used alone. Which ones did you have in mind?

I did have VS 2017 but I haven't managed to sort out the account issues. I may wind up installing VS Code just to have another platform I can run tests on. :)

Share this post


Link to post
Share on other sites
35 minutes ago, Visceral Moonlight said:

Most of the rest of **SE isn't standalone but some of its file reading headers can be used alone. Which ones did you have in mind?

 

The lot.

Quote

I did have VS 2017 but I haven't managed to sort out the account issues. I may wind up installing VS Code just to have another platform I can run tests on. :)

Account problems. Is that the Microsoft Account? It's an MIT license- any specific problem there?

Share this post


Link to post
Share on other sites

Thanks. The proper way is with #include, but there's bizzaro behaviour when say with including common/iConsole.cpp, when that file has the statement: #include "common/IConsole.h". So it's actually looking for common/common/IConsole.h.

Can't see any way out of this without a mass string replace of "common/ & "SKSE64/ and attendant subdirectories. Doable, but extra work!

...

That's bad luck about the account- there's no problem if a single user though. MS have made it plain they definitely want the cash from anything organizational!

Share this post


Link to post
Share on other sites

Yeah, the includes are helpful. The way they're doing it is implicitly using VS's dependency resolution but that can cause issues in the end and they're also doing some weird stuff with the directory searching.

I don't want to step on their toes but I think I may try to clean up their codebase some and then see if they'd be interested in using the work. :)

Issue is that the VS license is tied to the account. :P

Share this post


Link to post
Share on other sites

 

2 hours ago, Visceral Moonlight said:

I don't want to step on their toes but I think I may try to clean up their codebase some and then see if they'd be interested in using the work. :)

Issue is that the VS license is tied to the account. :P

Didn't know about VS Code. Is that a pared down version of Visual Studio? It should be enough for what you want to get a fork underway, - perhaps start another thread or continue on this one?

Got a AHK regex replacer handy here- might look at a few things tomorrow. :)

Share this post


Link to post
Share on other sites

It's a mystery, because including the SKSE  directories thus:

$(SolutionDir);$(SolutionDir)skse64_common\;$(SolutionDir)skse64\;$(SolutionDir)skse64_steam_loader\;$(SolutionDir)common\;$(SolutionDir)skse64_loader\;$(SolutionDir)skse64_loader_common\;%(AdditionalIncludeDirectories)

None of them log as included in the build- except the forced iprefix common ones (see Windowsproject2 above). Does forcing break something I wonder?

Share this post


Link to post
Share on other sites

It could be that VS 2017 changed how the inclusion works due to people abusing the automatic inclusion. It'd be best if the files did a #include for each header they used, though. I'm still doing a preliminary analysis but I'm seeing lots of data types being used that aren't the base ones (int, long, etc) with the headers not being included. Including the headers would help the codebase a lot with maintenance and other things.

Share this post


Link to post
Share on other sites

Added the headers to iPrefix.h, plus suppressed an extra warning:

#pragma once

// 4018 - signed/unsigned mismatch
// 4200 - zero-sized array
// 4244 - loss of data by assignment
// 4267 - possible loss of data (truncation)
// 4305 - truncation by assignment
// 4288 - disable warning for crap microsoft extension screwing up the scope of variables defined in for loops
// 4311 - pointer truncation
// 4312 - pointer extension
// 4596	(level 4) identifier': illegal qualified name in member declaration
#pragma warning(disable: 4018 4200 4244 4267 4305 4288 4312 4311 4596)

// winxp and above
#define _WIN32_WINNT	0x0501

#include <winsock2.h>
#include <Windows.h>

// Common
#include <cstdlib>
#include <cstdio>
#include <cstring>
#include "ITypes.h"
#include "IErrors.h"
#include "IDynamicCreate.h"
#include "IDebugLog.h"
#include "ISingleton.h"
// skse64_common
#include "BranchTrampoline.h"
#include "Relocation.h"
#include "SafeWrite.h"
#include "skse_version.h"
#include "Utilities.h"
// skse64
#include "BSModelDB.h"
#include "Colors.h"
#include "CustomMenu.h"
#include "GameAPI.h"
#include "GameBSExtraData.h"
#include "GameCamera.h"
#include "GameData.h"
#include "GameEvents.h"
#include "GameExtraData.h"
#include "GameFormComponents.h"
#include "GameForms.h"
#include "GameHandlers.h"
#include "GameInput.h"
#include "GameMenus.h"
#include "GameObjects.h"
#include "GamePathing.h"
#include "GameReferences.h"
#include "GameResources.h"
#include "GameRTTI.h"
#include "GameSettings.h"
#include "GameStreams.h"
#include "gamethreads.h"
#include "GameTypes.h"
#include "GameUtilities.h"
#include "GlobalLocks.h"
#include "HashUtil.h"
#include "Hooks_Camera.h"
#include "Hooks_Data.h"
#include "Hooks_Debug.h"
#include "Hooks_Diagnostics.h"
#include "Hooks_DirectInput8Create.h"
#include "Hooks_Event.h"
#include "Hooks_Gameplay.h"
#include "Hooks_Handlers.h"
#include "Hooks_Memory.h"
#include "Hooks_NetImmerse.h"
#include "Hooks_ObScript.h"
#include "Hooks_Papyrus.h"
#include "Hooks_SaveLoad.h"
#include "Hooks_Scaleform.h"
#include "Hooks_Threads.h"
#include "Hooks_UI.h"
#include "InputMap.h"
#include "InternalSerialization.h"
#include "InternalTasks.h"
#include "NiAdditionalGeometryData.h"
#include "NiAllocator.h"
#include "NiControllers.h"
#include "NiExtraData.h"
#include "NiGeometry.h"
#include "NiInterpolators.h"
#include "NiLight.h"
#include "NiMaterial.h"
#include "NiNodes.h"
#include "NiObjects.h"
#include "NiProperties.h"
#include "NiRenderer.h"
#include "NiRTTI.h"
#include "NiSerialization.h"
#include "NiTextures.h"
#include "NiTypes.h"
#include "ObScript.h"
#include "PapyrusActiveMagicEffect.h"
#include "PapyrusActor.h"
#include "PapyrusActorBase.h"
#include "PapyrusActorValueInfo.h"
#include "PapyrusAlias.h"
#include "PapyrusAmmo.h"
#include "PapyrusArgs.h"
#include "PapyrusArmor.h"
#include "PapyrusArmorAddon.h"
#include "PapyrusArt.h"
#include "PapyrusBook.h"
#include "PapyrusCamera.h"
#include "PapyrusCell.h"
#include "PapyrusClass.h"
#include "PapyrusColorForm.h"
#include "PapyrusCombatStyle.h"
#include "PapyrusConstructibleObject.h"
#include "PapyrusDefaultObjectManager.h"
#include "PapyrusDelayFunctors.h"
#include "PapyrusEnchantment.h"
#include "PapyrusEquipSlot.h"
#include "PapyrusEventFunctor.h"
#include "PapyrusEvents.h"
#include "PapyrusFaction.h"
#include "PapyrusFlora.h"
#include "PapyrusForm.h"
#include "PapyrusFormList.h"
#include "PapyrusGame.h"
#include "PapyrusGameData.h"
#include "PapyrusHeadPart.h"
#include "PapyrusIngredient.h"
#include "PapyrusInput.h"
#include "PapyrusInterfaces.h"
#include "PapyrusKeyword.h"
#include "PapyrusLeveledActor.h"
#include "PapyrusLeveledItem.h"
#include "PapyrusLeveledSpell.h"
#include "PapyrusMagicEffect.h"
#include "PapyrusMath.h"
#include "PapyrusMisc.h"
#include "PapyrusModEvent.h"
#include "PapyrusNativeFunctions.h"
#include "PapyrusNetImmerse.h"
#include "PapyrusObjectReference.h"
#include "PapyrusObjects.h"
#include "PapyrusPerk.h"
#include "PapyrusPotion.h"
#include "PapyrusQuest.h"
#include "PapyrusRace.h"
#include "PapyrusReferenceAlias.h"
#include "PapyrusScroll.h"
#include "PapyrusShout.h"
#include "PapyrusSKSE.h"
#include "PapyrusSound.h"
#include "PapyrusSoundDescriptor.h"
#include "PapyrusSpawnerTask.h"
#include "PapyrusSpell.h"
#include "PapyrusStringUtil.h"
#include "PapyrusTextureSet.h"
#include "PapyrusTree.h"
#include "PapyrusUI.h"
#include "PapyrusUICallback.h"
#include "PapyrusUtility.h"
#include "PapyrusValue.h"
#include "PapyrusVM.h"
#include "PapyrusWeapon.h"
#include "PapyrusWeather.h"
#include "PapyrusWornObject.h"
#include "PluginAPI.h"
#include "PluginManager.h"
#include "ScaleformAPI.h"
#include "ScaleformCallbacks.h"
#include "ScaleformExtendedData.h"
#include "ScaleformLoader.h"
#include "ScaleformMovie.h"
#include "ScaleformState.h"
#include "ScaleformTypes.h"
#include "ScaleformValue.h"
#include "ScaleformVM.h"
#include "Serialization.h"
#include "Translation.h"
// skse64_loader
#include "Options.h"
// skse64_loader_common
#include "IdentifyEXE.h"
#include "Inject.h"
#include "LoaderError.h"
#include "Steam.h"
// 

Done with a handy little regex:

^(.+)$
replace with
#include "\1"

Placed all the skse directories in the SolutionDir thus:

$(SolutionDir);$(SolutionDir)skse64_common\;$(SolutionDir)skse64\;$(SolutionDir)skse64_steam_loader\;$(SolutionDir)common\;$(SolutionDir)skse64_loader\;$(SolutionDir)skse64_loader_common\;%(AdditionalIncludeDirectories)

This may not be ideal, but workable for the moment.

To keep our conformance mode as yes/permissive, we have to modify the files:

Error C2760 in PapyrusArgs.h:

Quote

for(std::vector<T>::iterator it = begin(); it != end(); ++it, i++)

becomes

Quote

 

for(typename std::vector<T>::iterator it = begin(); it != end(); ++it, i++)

 

and similar repairs in PapyrusEvents.h.

For C7510 in PapyrusEvents.h:

Quote

RegMap::iterator handles = m_data.find(key);

becomes

Quote

RegMap::iterator handles = typename m_data.find(key);

Same thing, really. :P
 

 

 

Share this post


Link to post
Share on other sites

Scratchpad time!

We're probably going to want to run the files through IWYU to help with the include task. :)

Edit:

What is IPrefix even for? It looks like it's supposed to be the standard API include? If so, convention usually names them <project>.h. For example, OBSE would be obse.h :)

Edit 2:

It may be better for ITypes.h to use the standard typedefs instead of defining its own. cstdint has the uint32_t etc so the typedefs at the top of the file are a bit redundant. This would aid in reducing duplication.

Edited by Visceral Moonlight

Share this post


Link to post
Share on other sites

Sounds good.  :)

Now a question:

class Foo
{
static std::vector<std::wstring> arr;
};
const wchar_t *arrInit[] = { L"one", L"two", L"three" };
std::vector<std::wstring> Foo::arr(arrInit, end(arrInit)); // definition};
std::wstring FormsInfo(wchar_t *arr = 0)
{
	return std::wstring(arr);
}

And then calling it here

const std::wstring  &myfoo = FormsInfo();

But it won't convert in the second from void to std:basic_string<wchart_t, std.....

Swapping arr and arrinit in FormsInfo doesn't make any difference, Is there a any way of populating newStr with the array?

Fun Fact: BBCcode of C languages is broken!
 

Edited by Schtearn

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  

×