jbenda / inkcpp Goto Github PK

When running the following ink, "This displays first" is not displayed:

 Here is some test text
 
 - (opts)
 
 + [Continue]
 
 {opts == 1: This displays first}
 
 {opts < 2:  -> opts}
 
 - This is the continuation.
 
 * [OK]
 
 -> DONE

However, if you remove the space in the line {opts < 2: -> opts} between the colon and the divert arrow, then it displays correctly.

EDIT: I've been debugging this and I think it has to do with the order of the enum values in ink::runtime::internal::value_type. value_type::value_pointer and value_type::marker have the same value. Unfortunately, I'm not well versed enough in C++ to tell what the real solution should be. If I can get a little guidance I could probably submit a PR.

1: Scenario: compare concatenated values
1:       Given: string and numbers
1:        When: concatenated string representation match (many fields)
1:        Then: == results true
1: -------------------------------------------------------------------------------
1: /home/runner/work/inkcpp/inkcpp/inkcpp_test/Value.cpp:82
1: ...............................................................................
1: 
1: /home/runner/work/inkcpp/inkcpp/inkcpp_test/Value.cpp:85: FAILED:
1:   REQUIRE( res.get<int32_t>() == 1 )
1: with expansion:
1:   0 == 1

Full Log: https://github.com/brwarner/inkcpp/runs/1881136054?check_suite_focus=true

Not a big deal, but heads-up: there's currently a false positive on win64-cl.zip/inkcpp_cl.exe. Slightly annoying and may put off new users... I've reported a false positive here.

I'll close this issue once it goes through, but this might be an issue in the future!

When running cmake --install . --prefix Path/To/Desired/Library/Directory, it creates a structure intended to be used without Unreal. However, this has some issues:

• This command fails if the project was built with --config Debug instead of Release
• The inkcpp directory still includes an Unreal-style directory structure, plugin files, and headers
• To use the project, it's necessary to include two directories: include and inkcpp/Source/inkcpp/Public. Ideally these should all be in the include directory.
• As it only builds for Release, the copied .lib files are only for Release configurations and will error if used in a project set to Debug.
  • The user must currently manually copy over the debug .lib and .pdb files from the generated Debug build, and link them separately in their project config, if they wish to use them in a Debug configuration. I've added that to the README in a PR for now.
  • A standard pattern I've seen is to have a lib structure like lib/Debug/x64/*.lib and similar for /Release.
• May want to consider a separate --install component for the C++ package files and the cl binary -- most projects, when using the former, won't need the generated bin folder, and anything using the cl application won't need the library files.

There are workarounds that I've added to the README, so it's not urgent, but it would probably be a good idea to set up this as a separate config at some point!

Looks like code was tested only under Win environment (MSVS)

Compiling with AppleClang 9.1.0 shows multiple compile-time errors.

Please, build target under *NIX environment

warning: ignoring file 'inkcpp/macos-clib/lib/ink/libinkcpp_c.a32': found architecture 'x86_64', required architecture 'arm64'
etc

A manual Cmake build of the source seems to work fine

While attempting to use this project with inkcpp-python, I followed the instructions listed in the README to build the project. Each of the subprojects builds successfully with the exception of inkcpp_test, which reports an invalid opcode in inline assembly:

[ 77%] Building CXX object inkcpp_test/CMakeFiles/inkcpp_test.dir/Main.cpp.o
In file included from /Users/username/Git/inkcpp/inkcpp_test/Main.cpp:2:
/Users/username/Git/inkcpp/inkcpp_test/catch.hpp:7937:13: error: unrecognized instruction mnemonic, did you mean: bit, cnt, hint, ins, not?
            CATCH_BREAK_INTO_DEBUGGER();
            ^
/Users/username/Git/inkcpp/inkcpp_test/catch.hpp:7651:79: note: expanded from macro 'CATCH_BREAK_INTO_DEBUGGER'
    #define CATCH_BREAK_INTO_DEBUGGER() []{ if( Catch::isDebuggerActive() ) { CATCH_TRAP(); } }()
                                                                              ^
/Users/username/Git/inkcpp/inkcpp_test/catch.hpp:7630:34: note: expanded from macro 'CATCH_TRAP'
    #define CATCH_TRAP() __asm__("int $3\n" : : ) /* NOLINT */
                                 ^
<inline asm>:1:2: note: instantiated into assembly here
        int $3
        ^
1 error generated.
make[2]: *** [inkcpp_test/CMakeFiles/inkcpp_test.dir/Main.cpp.o] Error 1
make[1]: *** [inkcpp_test/CMakeFiles/inkcpp_test.dir/all] Error 2
make: *** [all] Error 2

This is an issue with Catch, and was fixed in this commit: catchorg/Catch2@a25c1a2 (released as v3.0.0-preview3.)

I'm interested in creating a static graph out of an Ink story that can be e.g. printed or displayed. I see that inkcpp does not support this by default so I'm wondering what's a good way to go about it.

I'm setting the RNG seed to 0 just in case.

What I've tried so far is to explore every choice in the story (taking & reverting to snapshots before making a choice), and assume that if I encounter a situation where the current text and choices are all the same as some time before, I have ran into a cycle and stop further iteration. However obviously this is not correct as the story can have internal logic where the outcome depends on some variable.

Another approach I tried (which didn't work at all) is comparing the memory contents of serialized snapshots to decide if the current choice has already been taken before.

Without some heuristic to find cycles / repeated choices, extraction goes on seemingly forever (using the Intercept as test data).

Can you give some advice on how to deal with this situation? Ideally you could point me to some internal of inkcpp I can surface through an interface that helps me decide if I'm seeing a choice that I have seen before in the exact same state of the story.

Thanks!

When using the function std::string runner::getline(), it should only go line-by-line. But currently, running the following ink:

Line 1

Line 2

-> line_3

== line_3

Line 3

-> line_4

= line_4

Line 4

-> DONE

... produces this output:

> Line 1\n
> Line 2\nLine 3\nLine 4\n

It seems knots and stitches don't properly cause the runner to break, even if they correctly generate a newline.

To confirm, I tested this Ink on the latest Inklecate and C# Runtime API, and using Continue() produced the correct behavior of:

> Line 1\n
> Line 2\n
> Line 3\n
> Line 4\n

I tried to fix this myself, but I'm not familiar enough with the internals of inkcpp or Ink to understand where the issue is. But, in the process, I made a test that could be helpful to anyone wanting to tackle this:

LinesTest.zip

• Polishing Unreal facing Code

• Create Demo project

• formulating long and short descriptions

• images for the Shop Page

• update README for new UE tutorial

• update wiki around UE

  

Hey guys,
I am seeing a crash with tags that happen when I add a bunch of them. Any ideas why this is happening ?

Ink FIle

->test_knot
===test_knot
line 110#loc:loc-line-1#in#op:1#cl:1
line 2#loc:loc-line-2#en#op:1#cl:1
line 3#loc:loc-line-3#in#op:1#cl:1
->DONE

Test case

SCENARIO("tags")
{
	inklecate("ink/AHF.ink", "AHF.tmp");
	ink::compiler::run("AHF.tmp", "AHF.bin");
	auto ink = story::from_file("AHF.bin");
	runner thread = ink->new_runner();

	thread->move_to(ink::hash_string("test_knot"));
	do
	{
		auto line = thread->getline();
		std::cout << line << std::endl;
	} while (thread->can_continue());
	
	REQUIRE(thread->can_continue() == false);

}

The test crashes with this ink file:

'inkcpp_test.exe' (Win32): Loaded 'D:\Projects\inkcpp\out\build\x64-Debug\inkcpp_test\inkcpp_test.exe'. Symbols loaded.
'inkcpp_test.exe' (Win32): Loaded 'C:\Windows\System32\ntdll.dll'. 
'inkcpp_test.exe' (Win32): Loaded 'C:\Windows\System32\kernel32.dll'. 
'inkcpp_test.exe' (Win32): Loaded 'C:\Windows\System32\KernelBase.dll'. 
'inkcpp_test.exe' (Win32): Loaded 'C:\Windows\System32\msvcp140d.dll'. 
'inkcpp_test.exe' (Win32): Loaded 'C:\Windows\System32\vcruntime140d.dll'. 
'inkcpp_test.exe' (Win32): Loaded 'C:\Windows\System32\vcruntime140_1d.dll'. 
'inkcpp_test.exe' (Win32): Loaded 'C:\Windows\System32\ucrtbased.dll'. 
The thread 0xb184 has exited with code 0 (0x0).
'inkcpp_test.exe' (Win32): Loaded 'C:\Windows\System32\sechost.dll'. 
'inkcpp_test.exe' (Win32): Loaded 'C:\Windows\System32\rpcrt4.dll'. 
Exception thrown at 0x00007FFD33A64FD9 in inkcpp_test.exe: Microsoft C++ exception: std::runtime_error at memory location 0x000000E566B0D570.
Exception thrown at 0x00007FFD33A64FD9 in inkcpp_test.exe: Microsoft C++ exception: [rethrow] at memory location 0x0000000000000000.
Exception thrown at 0x00007FFD33A64FD9 in inkcpp_test.exe: Microsoft C++ exception: std::runtime_error at memory location 0x000000E566B0D570.
Exception thrown at 0x00007FFD33A64FD9 in inkcpp_test.exe: Microsoft C++ exception: std::runtime_error at memory location 0x000000E566B08C10.
'inkcpp_test.exe' (Win32): Loaded 'C:\Windows\System32\kernel.appcore.dll'. 
'inkcpp_test.exe' (Win32): Loaded 'C:\Windows\System32\msvcrt.dll'. 
The thread 0xafa4 has exited with code 1 (0x1).
The thread 0x871c has exited with code 1 (0x1).
The program '[42160] inkcpp_test.exe' has exited with code 1 (0x1).

Note: removing any single tag from line110 fixes the issue, so it could be an issue with memory size ?

Let me know if you guys can repro this on your end.

Many thanks!

This one's SUPER specific, but:

-> content
== content

*	Some choice
	blah blah 
	blah blah blah
*	*	[This is the killer!] Text can be here though, just not on the left.
		Blah blah
		Something something
*	*	*	Encountering this choice causes an error.
-	Weave...
-> DONE

The error is "Stack is empty! No top()!" from _container.top() on line 1176 of runner_impl.cpp:

			case Command::END_CONTAINER_MARKER:
			{
				container_t index = read<container_t>();
				inkAssert(_container.top().id == index, "Leaving container we are not in!");

				// Move up out of the current container
				_container.pop();

Unit test here. This occurs on MSVC regardless of configuration (Release or Debug).

I tried it on #65, but it's still broken there, so this is unrelated to #63.

Note that it is required to be in a knot; it doesn't occur at the top level.

Here's a test that demonstrates the issue. If someone manages to fix this, I recommend including it as part of the commit:

inkcpp choice bracket bug.zip

But in summary:

// This is valid:
*    [A choice!]
// This is invalid:
*    [A choice!] 

Got another one!

It seems variables might not be re-evaluated properly after a lookahead. For example:

EXTERNAL GET_LINE_COUNT()

Line count: {GET_LINE_COUNT()}

Line count: {GET_LINE_COUNT()}

~ temp should_execute_before = GET_LINE_COUNT()

Line count: {should_execute_before}

-> DONE

Given a GET_LINE_COUNT which prints however many lines have been consumed, inkcpp prints:

Line count: 0
Line count: 1
Line count: 1

Where the C# package prints:

Line count: 0
Line count: 1
Line count: 2

(even with the function bound as lookahead-safe). This can cause issues in games which have a state change after a line is printed.

Here's a unit test.. I've replicated the unit test in C# and confirmed that it produces the second output.

Many thanks for your hard work on this package, by the way!

This valid ink file crashes the interpreter when compiled with inklecate 0.9.0. All other test cases in the repo work.
It crashes as soon as it reaches the choice.

Hello there
General Kenobi
-> Main

=== Main ===
Nice
Now what?
What are we doing now?
* [Make the game]
    Lets make the game then
    -> Make_Game
* [Give up]
    Giving up already pah
    -> END
* [No idea]
    Idiot
    -> Main
* [Lol fuck this.]
    Lol ik right? 
    -> END



=== Make_Game ===
Frantic Keyboard Noises
-> END


=== END ===
The END
-> DONE

inkcpp was compiled using Visual Studio 2019 Community Version 16.5.4 and cmake 3.16.0

I noticed that there is an "inklecate" tool mentioned on the Wiki, which is used for converting .ink files to .json files. However, I couldn't find inklecate in this particular project, and it took me some time to figure it out. Inklecate is actually part of the Inky project, and you can download the released version from this link: https://github.com/inkle/inky/releases. In my case, I found it located in the inky/resources/app.asar.unpacked/main-process/ink directory. I believe there may be others who encounter the same issue, so I decided to share my solution.

Based on multiple requests, it would, may be possible to create C bindings for inkcpp.

It would be a new subdirectory (inkcpp_clib or so) and would do inkcpp stuff but with c functions and external, the bindings should not take too much code, probably a handling the classes implicit as void* pointer passed back to the C code.

A new installation target for CMake is also required (like clib) to install only the c files.
Attention: not mixing up C and C++ header when exporting libs, also a different findInkcpp.cmake is needed for that.

Allow the usage of the C++ classes directly in UE for a non Blueprint usage.
Depending on the implementation, a new installation component sounds reasonable (unreal-cpp)

When ctest -c Debug is run after the project is built with cmake --build . --config Debug , I get the following error:

Program: inkcpp_test.exe
File: include\xstring
Line: 1942
Expression: cannot dereference string iterator because it is out of range (e.g. an end iterator).

I'd look further into it, but I can't seem to figure out how to run tests from Visual Studio and step through the code.

Note that the tests work fine under the Release configuration.

To reproduce:

1. download the intercept ink file https://github.com/inkle/the-intercept/blob/master/Assets/Ink/TheIntercept.ink
2. export the intercept to json
3. play the json in the inkcpp CL
4. select the choices 1 3 3 3 2 3
5. observe the invalid newline before the period in the printed text:

"I don't see why," I reply
.

I was just testing with the crime scene story that comes with inky. (with the command line executable)
Unfortunately the first advance line call directly throws Operation for value not supported!
The evaluation stack is at the Compare the prints on the knife and the window line of the story when the exception is thrown.

Looks like a not supported ink syntax?