hoot

No no, on the other hand it shows me that i am not that wrong with my opinion

Folks i've got it, i know it, i just answered to maddmatts statement that signing so called clientside addons is just dumb.

Again, you load a soundmod addon, whereby it is insignificant whether or not you call it clientside or mp addon, it is de facto an addon you have loaded with you when you go online and should be considered as being dangerous. The server will get notified what you are about to bring with you and then it looks in his own key directory whether or not an appropriate key can be found. If not it kicks you. So the server will need the addon's key to let you in. When i want to go and play online i simply want to play with my 'clientside' soundmod addon. I fear i simply don't understand the definition of clientside or mp addon. I have it loaded, it is active in memory whatsoever it is. Maybe we are talking at cross purposes

Well and when i want to play on a server with my soundmod then the server needs a porper signature for this clientside addon, right? Edit: Your statements are somehow strange. At first you say: and then So what is it then? Pointless to sign such addons or not? Btw, i've not asked for equalmod, that was entirely an example

You connect to a server with an addon, let's say with a soundmod what is imho a clientside addon, the server has no proper signature for it so it kicks you, as it would do with 'equalmod enabled'. Maybe it is not that dumb or i simply didn't have understand it. edit: I can't see a difference in handling of what is a clientside addon and an mp one, as you load them whatever they are. So if you go online any loaded addon should be considered as dangerous, because anything is possible a threat and only the own instance, the server here, is trustable. So i would say the server will kick anyone who's having whatever addon loaded and from what he misses a proper signature locally. That's why i say: sign anything. However, as told, i'm maybe wrong with this.

Hehe shit happens...retesting... 1st result: Connecting with XML lasts longer than connecting without ...tbc

Thanks a lot, testing... But what i also recognised yesterday in a short test was (2 Players little coop), that the ammocrate needs horribly long to give you the GUI for handling your loadout. Interaction with it also takes a bit. I tried 10 seconds to drop a AT4 but nothing happened. Strangly it was faster to get other ammo during that i-get-no-feedback-phase. On windows server its going way faster, as i feel. Apart from that, pings looked fine, also the bandwidth. Anyone else have such an effect? Aftermath: It seems the problem is still there. We were playing a 3 men DM all with XMLs. Two were playing and the third was connecting when the game stood still for some seconds. No chain symbol, just the old 'freezing-prob'. Edit: wget ftp://www.flashpoint1985.com/ArmA/DediServer/server-1.08.tar.bz2 gives a file in which the newest file is the server binary what is from 19.09.2007 Last download was just now...

Yep i read about it in the wiki and came to somehow the same conclusion. I second the wish to have such a functionality as i fear that if the player don't know why he was kicked he probably won't return because it might be his last point to check his 20K addons for what is working and what not on a specific server. But on the other hand, if he has loaded 20K addons and a serverside script is telling him what addons or mods are not allowed, the list of notification may blasting the users screen. On a System with 5 or whatever chatlines, that message could be a little hard to follow Maybe putting it in an element of the BI GUI might help. A screen-wide infobox with scrollbars in case the list is getting really long. However, any notification is appreciated.

There is already an thread online here. Edit: @Victor i saw it - no problem

@rundll.exe: But why? I don't get it. It is up to you as an server admin whether or not you use the key to allow that addon? So i don't care what the addon or mod is actually doing or whether or not it is sp or mp only, i decide what is allowed and what not.

Well we are running it on a P4 @ 2.8GHz single core with 1GB RAM. It's our good old Flashpoint server We configured it for 40 pp at first, but the server is currently having a little quirk in handling the squad.xmls, but BI is after it so proper testing may begin a little later. However, i cannot speak for others. Maybe someone already have it tested fullhouse-like.

Thanks a lot Q for that hefty explanation! Referring to your thoughts: 1st and 2nd: I do absolutely agree here, enclosure is always good practise. 3rd: ...but sounds fine for some squad related stuff. 4th. You mean a combined black- and whitelisting? I would second that. But i fear that's a part of ArmA2 because of the calculation of effort and benefits for BI and ArmA Edit: I am a noob in scripting the BI scripting engine, but went recently to the wiki and landed on the page that is describing serverside scripting. Although i know what eventhandlers are and stuff i asked myself whether or not it is possible to not only kick or ban a fellow soldier, but also to send him the message why he has been kicked, or, to carry it to the extremes, to send a more detailed one like this or that addon is not allowed here. I am asking it because the wiki says: What would mean to me: - same syntax - +-/* and equivalence mul, pow, add whatever - if, switch, while-do, do-while, for and whatever plus some specific commands for serverside scripting. Does it actually mean, that sending messages through the chatlines is possible to give customised feedback to a player, as the 'specific' implies? I.E the counterpart to sprintf(); in the BI scripting language Edit: Well i know its possible to send such texts, i mean relating to server side scripting. But maybe there is a stanard errorbox showing such an error message, like 'session lost' or so.

Roger, you mean QA. But that of course should happen before the mod or addon is released in a final state, what requires proper testing beforehand Concerning the mass of betas around you're right.

Why not signing it immediately? I mean just generate the keys and release it with the mods. The admins of the server would then however put the keys to the server or not, so if anyone is connecting with let's say the XAM mod and there is no key present on the server, a kick will follow. I guess it behaves like the 'equalmod' setting already known from Flashpoint and still available in ArmA and can be used a similar way, but is based on a more reliable principle -> signatures. Or am i completly wrong here?

But what is meant by saying strictly SP? I mean is anyone remembering the good old DynamicRange soundmod for Flashpoint what was considered to be a cheat the first months due to the fact, that the player who has it loaded could and can hear tanks ten kilometres away, while in standard Flashpoint you would normally hear the tank when it stands next to you or you put the volume to a max. It was definitively a clientside addon, whereas the anim mods like the one from Locke are not. If a player joined a server that has not installed such a anim mod, and is let's say leaning around a corner, the whole server crashes because it cannot handle such movements without having the same addon installed. So how to identify which addons are clientside only and which are not? XAM i.e is imho clientside as well, but we don't want to have someone playing with it, cause it behaves on slow machines like the graphical enhancements for Flashpoint with columns of smoke that reach the sky and therefore slow down the overall performance of a weak client, what then often results in desyncs and lagparties. Can anyone explain me the difference? Currently i would ask all modders to better sign their addons.

Good news, really. The sooner the better - no no. Take the time you need

True, we have three servers running and the testbox has neither web services nor dns services running, so it's doubtful. @Red: Chain. I was trying to say that there was not even a chain symbol. The red chain symbol is already known for windows servers to appear once the load on the server is high and a new player connects - yep, but you can go on with playing, even if a red chain symbol appears. But here: the already connected client didn't get data from the server during the connection process, the other client has performed. Again: The internet itself already holds a lot of intel on a discussion like 'Mommy, my Win beats that damn mutated penguin' or 'Daddy, Bill is a suck0r' - a discussion that is being held for decades now... and men, it is really pointless and depends on philosophy and likes and dislikes, that's all. The rest of the discussion should be held by at least graduated ones who can judge that topic more impartial

We have tried a little coop recently and it seems that the connection time takes a bit. A member was already gaming and i was joining the session, when he got not even the chain symbol (red or yellow), but experienced the same effect, as if the ofpserver (comparable) has crashed: having all the playerobjects running on the same position without really moving. My connection process on the other hand went fine as usual. When i was in the game and connected, his session was also continuing. Has anyone experienced similar effects? Cheers. Edit: I read Hitman's last post. Well we both used our XMLs, maybe that's why the server was a little incertain in handling already connected players. Maybe one connection managing thread is blocking the rest, because the whole pipeline to the other clients seems blocked for a period. Don't take it seriously, i have really no idea...

Testing the new binary...thanks alot team. The support for the linux dedi is damn fast Edit: No problems so far, but as C already mentioned and implied, better to check it when we have full house.

Yep, finally we got it: @Hitman: Yep pal. Thanx a lot Edit: [deleted due to: problems solved]

But the param -cfg= is meant to be used for a serverconfig and not the arma.cfg?! The server is creating an arma.cfg like it is creating the user directory, but it is somewhere down the street and not actually inside the ArmA directory. But this is maybe an outcome of the fact, that the admin is currently running as root The one and only userconfigfile one can use is the whatever/player/player.armaprofile/ ?? Edit: No seems not. We put an additional subdir into it, a user big_bad_admin at first but it seems not to work. The server then creates a directory called big_bad_admin in the ArmA root directory when it was started with the param -name= ...

Hm. I can see a difference in quality of displaying the grass, the flora, according to the userprofile i forced the server to start with. So maybe one cannot disable it complety via a serverconfig, but one has influence to the quality settings of the grass respectively the shading quality. Ok then that was my point You mean the linux server binary is creating it? Hm, its missing here. For the clanserver we need to upgrade the distribution first to see an effect. Okay but where is the arma.cfg located then? Where to put it as it is on Windows located in the \Documents blablabla\... directory as well. Guess we should simply put it into the ArmA server directory...mhmhmhmh... Edit: Okay for testing purposes we put all needed libs from a distri at home to the SuSE in a chroot-env and the server is actually running fine now. It also creates a 'player' directory in which the profiles are located. But one question remains: where is the third configfile, the arma.cfg?

Hi Astra Yep in Windows not a problem, as told. Okay you mean, the user directory is located in let's say: hda(or whatever mountpoint one may choose)/arma/users/[profilename]/ I wonder because it is undocumented, and if it would handle it the same way like it does on Windows, then it would look in the /home directory to locate it. The armaserver script is also trying per default to use $HOME, that's why i am a bit confused. It is not a must-have though, as i guess. I want to to know from where the linuxsever loads a userconfig and the arma.cfg. I believe one has three cfgs at least on Windows: The userconfig, the armaconfig and finally the serverconfig. Maybe it's better to hopp to the good old ALSR forums, maybe Hitman and others are still around to give a helping hand on this. If you have further intel, Astra, then pls let us know. Btw, i should have C somewhere in my ICQ. Anyway, a standard SuSE 9.3 seems to be just too old, but today we are going to perform the longed for upgrade to a proper Debian. The current SuSE is running since 2004 iirc - we now have a reason :P Feisty, not Edgy as told yesterday, on the other hand is not bitching Would be nice to have a word from a dev to this topic.

We are damn funny folks here in B