A Var that doesn't contain a value, but a pointer is for example needed if you want to add a digits element to a panel. There you need to give a Var pointer to the engine - to ensure that the value is displayed in the panel that the Var object in C# has. Without a pointer in the Var it also wouldn't be able to display the current time in a panel - you would have to update the time every frame, with pointers you don't have to worry about this.

The scheduler i wrote created a thread for every function that was called by the engine (for example a function one gives as parameter if you create a ENTITY object). After an engine_frame it started to stop the current thread and started a thread in the list, after that thread ended or reached a wait, the current thread was stopped and the next thread in a list was started ...
But in the end it was just too slow to be usefull ^^

The difference between calling functions every frame and a scheduler is afaik, that if you have a scheduler you can use wait, and thus, when the function's turn has come, it doesn't need to go through the whole function, but may start after the wait command.

Thx very much.
Was playing with a previous wrapper posted here
adding more acknex stuff but will try
this one as ALL acknex is already added.
//
My level will not load, either from the level folder
in the project folder

or directly from the project folder

So i am off to check why.
//
Everything else is fine though
and thanks again for your work.

hmmm afaik this error may be thrown if the paths aren't correct. You didn't write the commands under quotation marks or (this would be wrong) ?

P.S.: you should really update Acknex to 7.77 because the wrapper is built towards 7.77

the second version should work, did you put the wmb file into the Debug/bin folder of your project ?

thanks for working on this! having a c# wrapper for a7 is very nice. i also would try to reduce the amount of unnecessary verbosity though. i am no c# expert but i am sure it's possible to make it much more convenient to use.



def_debug_pan.setdigits(0, 0, 12, "fps%5.0f", ackfont, lambda: def_dfps * 16)

in python using pointers isn't possible at all so i use lambda expressions for panel elements. internally i have a big var array for panels which gets updated each frame by calling the lambdas that got registered for panel elements. it works great and even is much more powerful than simply passing a pointer. for example it supports local variables and arbitrary expressions.

lambdas are available in c# too.



i wouldn't use threads for the scheduler. the lite-c scheduler doesn't use threads either. it uses coroutines. coroutines can be simulated by generators in python and c#. you could look into the source of my scheduler. it's really simple.



just some ideas.

Thank you ventilator for your input !
I will look into coroutines - they could be the key ^^

your approach to simulating pointers is also quite interesting ! the c# wrapper is able to get a pointer of a local variable but not of arbitrary expressions - lambda may be worth a look ^^.

Use a legal version, then it works.

@Stromausfall
Tried in all the places
project folder
debug/release folder
(my) gsdefaults folder

but they load in my original c# project
so i know i' just need to look a little closer
at the problem.
No worries, will definately solve this when i get time
to concentrate

OK- fine now
should be in debug folder, but settings were to release folder
(knew it was something simple).

I hate being negative about something, but I see a few issues with your wrapper that would stop me (personally) from using it:

1. your code doesn't follow the C# coding conventions at all and this is a really big issue as far as I am concerned because, especially in larger projects, continuity of style is important to ensure maintainability
2. there is no validation whatsoever anywhere in your wrapper
3. nested classes should not be used in the way you used them
4. the statement in your first post "withouth the use of unsafe code !" is obviously wrong since most of your code is unsafe and when the methods in your wrapper are called, unsafe code is executed - it's just less obvious.

Michael

about points 1-3 i will look into them, i have to admit that i don't have yet any knowledge about these mentioned points, but i will try to learn about these points and integrate them in the next rewrite of the wrapper!
about point 4, actually i wanted to say the user of the wrapper doesn't need to use unsafe statements, that didn't imply that the wrapper doesn't use unsafe code ^^

Thanks for your input, these seem to be points that i should learn about!