[GordonFreeman (RU)]

How to copy treemap on windows server ? I can't select anythings in server console and condebug only logs okapi promts.

In server console (can't select anything):


In qconsole.log:

######### OKAPI ######### #########################

[Arkshine]

Treemap, while it's a nice idea and attempt from joaquim, is not working properly. As it is, this is actually not better than signatures. He did his best but at the end it's still a broken feature which can't be really fixed. I will remove treemap in next version. So, you can forget about this.

[HamletEagle]

Please don't remove it. All the plugins that are using a treemap will need to be re-written to be compatible with the new module. Just let it there, as another way of hooking the function. I mean if the signature fail, the treemap may not, or the reverse.

[Arkshine]

"All" plugins, you are most likely the only one who use treemap for now. Treemap will be removed, there is no point to keep a feature which is working worse than signature (your last affirmation is wrong), but I could keep the native registered (with empty content though) to keep compatibility and to avoid to traumatize you. Module is recent, and no one are using it, so if something needs to be removed, it should be now.

[HamletEagle]

Hmm, if I'm the only one you can fully remove the native and I'll update the only plugin which is using the treemap.

[Destro-]

@Arkshine
On future you will give more support to Okapi or Orpheu ?.

[KORD_12.7]

Yep, i agreed with treemap removing.

PS
And i asking to add natives about geting "ptr" to other libs (metamod for example), not only engine and gamedll.

[Arkshine]

Now I've removed Boost/STL dependencies in Orpheu, unless there are bugs to fix or some people requesting something, I don't think I will do more. Okapi is somehow better designed/flexible internally, so this would make sense to work on it as it can do more or less what Orpheu does, but it lacks few important things, like doing stuff on others libs than mod/engine, basic configuration file support, and maybe more friendly natives for known structures. At the end if we could support one module, this is probably for the best.

But I'm unsure how to design that properly.

About libraries, you don't have much choices. I'm thinking to reorganize like that:

• Each set of natives named with "mod_" or "engine", would be replaced with a new set named the same without including library name and accepting a new param.
  This new param would be an address, more precisely, an address which is contained in the library you target.
  And because "mod" and "engine" is the most used, having a bunch of stock to do some alias.
  
  Exemple:
  

  native okapi_engine_get_symbol_ptr(const symbol[])
  native okapi_mod_get_symbol_ptr(const symbol[])

  Would be replaced by
  

  native okapi_get_symbol_ptr(address, const symbol[])
  
  stock okapi_mod_get_symbol_ptr(const symbol[])
  {
      return okapi_get_symbol_ptr(okapi_mod_get_base_ptr(), symbol);
  }
  
  stock okapi_engine_get_symbol_ptr(const symbol[])
  {
      return okapi_get_symbol_ptr(okapi_engine_get_base_ptr(), symbol);
  }

• To cover 99,9% of situations where you want libraries addresses other then mod and engine, Okapi will register any libraries which are loaded from /addons directory. This means any metamod or amxmodx modules for examples. Actually like does Orpheu. And to get such addresses, adding a new native based on library name.
  
  Example:
  

  native okapi_library_get_base_ptr(const name[])

  So you could use it like that:
  

  new address = okapi_library_get_base_ptr("metamod");
  
  okapi_get_symbol_ptr(address, "_SomeSymbol");

About configuration file, I've no idea.
Main purpose would be to share more easily functions signature/symbols. Well not only functions, structure offsets too for example.
Ideally providing a full references of all functions, but while it could be easy with linux, it won't with windows.
From that, if we provide such reference config files which would grow progressively over the time, this will be probably horrible to maintain.
I guess no choice to do something similar as Orpheu. Content would be simplified though.
Damn no fucking idea for now what would be the smartest and convenient for user and to maintain.


Any thoughts are welcomed.

[HamletEagle]

I would like to continue with orpheu and not okapi, but you know better. Okapi natives are quite ugly and confusing, if you can rename them or do something like orpheu style it would be good.

[Arkshine]

What do you mean? CamelCase? Factorized natives?

The only issue I see is more all is put together in one file, and since it's not factorized, and use _mod/_engine, it can be indeed confusing when you read the file. But if it's well separated (one file for memmory stuff, functions, etc.), you would see that's not really an issue. That's said, I might factorize the one with the type (_int, _float,etc.) since if I add more type, probably more handy to have one native and a list of constants.