SicSemperTyrannis

Haven't been here in a while, kind of impressed the topic didn't go to crap.

make the last parameter true, as opposed to false.

If it can be converted to a string, number or array it can be saved and loaded. I don't know if that answers your question.

Well, again, the engine would just send that data explicitly (although I guess you are trying to avoid that?) because I'm pretty sure addWeapon/addBackpack/addItem/etc works on the server. If you're trying to avoid it purposefully, maybe it's better you add me to skype (will put in my profile in a moment).

I'm still not entirely understanding your need for it, if it's to store inventory only, the server has that information and you don't really need to specifically send your loadout from the client to the server. The server has that data explicitly, meaning, it'd be there whether you specifically sent it or not. That being the case, I could look into making a gzip extension, but it might not work well with the ini format.

Why would you need string compression if you don't mind my asking? I can try to make a separate extension to meet your needs if I know what it is for. EDIT: @Bad Benson: No, it doesn't belong in the client init. If the server isn't running the code, it will not work. You have to execute the code on the server-side and I explain how to do that in this topic in detail.

I hope so, that was the plan I guess. I also hope there's some C/++ coders (or other languages) that can learn a bit about the plugin format and how to send/return data to/from the extension DLLs. There's a lot more you can make. I plan on making a couple more extension modules myself.

In the player init (on the client) I do: player setVariable["profileName", profileName, true]; //3rd var "true" reports it to the server It's explained why I do that in the comments (if a player uses a different profile it will make a new db file), I guess I should have been more clear. https://community.bistudio.com/wiki/profileName

Couple of things... first, you can't call iniDB_read on the client. Once again guys, the server. The server. The server. Also as far as I'm aware, addWeapon does not accept arrays. Try using the script I mentioned early on to get/set loadout. Um, question. How would "player" be a valid variable on the server... ? I feel like a lot of you guys should read up on code locality in ARMA. I'm not trying to make fun of any of you guys it's just... that has to be broken. If you're running it on a test server, it might save YOUR stats since isServer == true and player is valid on a local, non-dedicated server. If you try running it with actual players i have a strong feeling it will break. Protip: If iniDB_read/iniDB_write and "player" are used nearby one another, it's likely going to be broken.

It's stored in /@inidb/db/ The first parameter of the write/read function is the file name, just not the entire file name (since it's not needed and can cause exploits). So, _fileName = format["PlayerID_%1", getPlayerUID _unit]; Would be like: /@inidb/db/PlayerID_123456.ini

There's no loops or anything that would cause yellow chain. There's nothing especially intensive about the code. If there's problems, it's with the script. Perhaps you'd have better luck asking in script help topics.

It should work on ARMA2 just fine, the callExtension API is in ARMA2 as well.

Fixed it, then.

I said earlier that I'd post one eventually, but right now I simply do not have the time. I'm working on my own mode.

You're coding that completely incorrectly. if(!isServer) exitWith {}; _unit = _this; _profile = format["%1", getPlayerUID _unit]; _position = [_profile, "playerdata", "position", "ARRAY"] call iniDB_read; _score = [_profile, "playerdata", "score", "NUMBER"] call iniDB_read; _unit setPos _position; _unit setScore _score; Then in the init: 0=this execVM "playerinit.sqf"; What you're doing extremely wrong is you did not read up on the scripting language. I know it's inconsistent, hard to understand and well... no apologies for the language itself, but you should learn the fundamentals before tackling something like this.