xeno

Almost 4 weeks gone, nothing happened. Is this still planned for A3 and if so, what's the status? Xeno

Who will remove missions which were modified and then published to Workshop if the mission licence says that even derivates may not be put onto workshop? Edit: Or what about missions which use 3rd party scripts which may not be published via Workshop? Xeno

_idx = addMissionEventHandler ["Draw3D", { drawLine3D... drawIcon3D... }]; Xeno

So when will people be able to test MP content with more than 1 local client (HC or normal Client) on a local dedicated server again (local = on the same machine)? Or will it stay the way it is now, second client gets always kicked? Xeno

Only if one creates the steam_appid.txt file (with 107410 as text) in the A3 folder... otherwise Steam will not allow more than one A3 instance even if the exe gets started directly from the A3 folder (so basically like it is since A3 release). Not even close. Xeno

No, it isn't. And no matter how cool you find it, it doesn't solve any problem the engine has for years. It just helps to hide some of the performance problems and other (especially MP) issues the engine has currently (and nothing has changed compared to OA). Edit: The game is still a Singleplayer game with MP and MPwise it is still the same as OA. Xeno

Please do all the people here in that forum a favour and keep yourself out of threads when you have no idea what you are talking about, Thank you. Xeno

You don't even need BIS_fnc_MP to execute any code you want remotely. Add for example a MP killed EH to the player object on a client and press ESC->Respawn, the MPKilled code gets now executed on all connected instances, means all clients and the server. As long as BIS_fnc_MP isn't changed (clients should never be able to execute any available function/script file or code remotely) and as long as the MP eventhandlers transfer code over the net instead of using preregistered code nothing will really change. I also wonder why clients can use any setPos command or setDamage on other clients player objects. Scripting commands like these should be limited to the local player object. Xeno

The database handling is completely done on the server, nothing client-side and not in the intro script, the intro script just displays some additional info if the stats are available :) Add something like this to the onPlayerConnected script (x_serverOPC): { if (getPlayerUID _x == _uid) then { _nscore = _res select whatever_idx_in_the_array_the_score_is_stored; // I can't remember which one it was if (_nscore > 0) then { _x addScore _nscore; // be aware that the arma server itself stores the player score so if a player reconnects it may add this to the previous player score }; }; } forEach playableUnits; It should find the correct player object (at least if playableUnits works as expected and the new connected player object is already in the playableUnits array) and add the score from the sqlite database to the player object. You can also iterate over all Dom player entities to find the correct unit and read the player object from missionNamespace (check the onPlayerDisconnected script, it's using it). If a player clicks the button to check his stats a query is send to the server and the server will send the current player data just to this specific client. Once the client has received the data from the server the player stats dialog opens or, if a timeout is reached because something went wrong it won't open (the data of each client is cached in an ingame object on the server while the mission runs, better for performance because it reduces the callExtension calls accessing the sqlite database; the only times the sqlite database gets actually accessed is when a player connects and disconnects). Xeno

Oh, I haven't seen anti domina posts for some time (or I didn't notice them, not following this forum closely anymore) :D Don't worry, I won't get SteA3m (domina is abandoned anyway) and I won't hand out permissions to port it to A3. You just have to fire up the editor and build the MP mission/mode of your dreams, very easy. Just takes lots of time. Xeno

Of course, because A2/OA MP/server handling has nothing to do with Steam. If you play a game which makes use of the Steam services and Steam has one of its (many) server problems that's a game over and you are removed from the game. (I personally also suffer from the problem that either my Teamspeak or in the worst case my router disconnects when I try to use the server browser of a Steamworks game, nothing I can do about). Xeno

+1 Carl Xeno

Terox, your behaviour is in no way better by taking this to the public. The next time you have an issue with someone from ACE use PM or contact him by other means. If you need to wash dirty laundry than that is the way to go. rocko, or billion here, has made most of the ACE features and has spend crazy amounts of time doing that. Xeno

What if an addon uses handleDamage too ? You can't make sure that your handleDamage EH runs first or last. And then there could also be the chance that one script uses different setHit values than the other. And so on. The worst thing one can do is using spawn or execVM to run event code (why would anybody give up execution in the same frame ?) :) handleDamage, as nice as it is, is not that easy to master (I've played around with it for months when I made ACE wounds). For example, it still triggers even when the object is not alive anymore. Shooting somebody in the leg can and will also trigger damage to other selections, and so on. Anyway, recommended way for using handleDamage is using it once for an object. Xeno

That's not completely true anymore... one of the beta patches introduced profileNamespace from Take On Helicopters (it will therefore be available in 1.63). profileNamespace saves data persistent to a file in the current profile folder. Xeno

It's not so much about the handleDamage scripts it's about what gets returned to the engine as last value in the scripts. For example, an object with two handleDamage EHs attached to it. One handleDamage EH recalculates _this select 2 and returns the recalculated value back to the engine, a second one just returns 0 so no damage is applied. You can't say for sure which result the engine is using, you might want to make the object indestructable but the engine uses the recalculated damage value thus the object is not indestructable. And don't forget that the handleDamage EH does not trigger once per damage but multiple times, means, overall damage plus number of selections. The EH scripts are executed 5 times for units, 7 times for tanks (afair), each time the object receives damage, no matter which damage. Xeno

Yes. You should use handleDamage only once for an object. Reason is, handleDamage returns a value for each selection/overall damage back to the engine when it triggers. So if you have more than one handleDamage EH attached to an object one handleDamage EH script overwrites the results for the other one leading to unknown behaviour as you don't know which result the engine is using. Xeno

That's exactly what it means. And as already stated in one of the files included in the last versions, porting to A3 is not allowed. Xeno

And before you even contact Dwarden you have to ask the creator of Wasteland if he allows it (and he has to ask the guys who made some of the scripts which are used in the mission). Oh boy... Since the dayz invasion it seems the most important thing for many people is to make money of other peoples (free) work. Xeno

Err, no. I'm not interested in MP mission making anymore (and it was just a few minutes on my harddrive before it went into /dev/null again) :) Xeno

Open i_common.sqf and search for GVAR(illum_tower) or just illum_tower and replace the class name with another one. (I had to download Domina again and search for it, haven't touched Domina for quite some time, lol) Xeno

Without seeing the rest of your script(s) we can only guess what you are doing. You are most likely sending a second playerclientid pv with a string somewhere (but that is just guessing too). And what's the "str(_this select 1)" error ? Xeno

The error message tells us that you are still transfering or are using a string somewhere instead of the object reference... Error owner: Type String, expected Object Xeno

The owner command works only on the server and not on clients. Replace owner player with just player and execute the owner command on the server once it is broadcasted. Xeno

Sadly the images are missing. If I ever find my manuscript again I'll upload it somewhere else... (zomg, that thing is already 3+ years old :p) Xeno