Dialogs...

[Millenium7 0]

I'm gonna be working on a rather large map on and off but I can't really do much without first creating some dialogs which are the basis of the whole thing. I never used them before and need some GOOD tutorials, i've found only one on www.ofpec.com but its not very good. I need something that explains everything clearly in detail, not just showing some examples. Google yields results for every game BUT ofp/arma

I've been playing around with the createAgent command but it doesn't seem to work? can anyone tell me how to make it work. I need to create solo troops not ones in a group, and using grpnull with createunit does not work either (nothing is created)

[Millenium7 0]

big fat nudge, still havn't been able to find a decent tutorial or guide

[MrZig 0]

Try taking apart missions that have dialogs (like RTS-3) and just experiment. That's how I learned dialogs. It's reallly reeeeally confusing at first, but it gets easier as you go along and make your own..

[hoz 0]

There is a dialog tutorial here by Vektorboson. Dialog Tutorial

[Guest]

Dont know if it would help or not, there is a 'dynamic dialog' function made by SOW, its for ofp, so I dont know if its instantly portable to Arma, or if it would need to be 'modified', but anyhow, I found it very easy to use, and a very nice function for player to ai interaction, basically all one has to do is put in text, voice files, and any animations desired in the designated areas in the function, and one can build entire conversations (like most rpg type games dialog builds)

http://www.flashpoint1985.com/cgi-bin....cial+ed

[Millenium7 0]

ah no not conversation dialog, dialogs that pop up with text and buttons like what you get in CTI when choosing weapons, infantry and vehicles. I only need 1 type of dialog something that has a scrollable list on the left, a picture on the top right for each selection, a description underneath that and OK and Cancel buttons which execute different scripts to set up unit positions, weapons, vehicles, triggers and so on

I have the tutorial on ofpec but its not very good I need something that goes in to detail on each subject, how it works, how to use it and so on so I can just learn what I need. That tutorial has too much showing and not enough explaining

[KaRRiLLioN 0]

Get Vektorbosen's dialog tutorial. That's what I used to learn them for RTS-3.

But another question is that some of the definitions for dialogs have changed. I tried porting some over from OFP and I'm getting errors. What we need is a new list of definitions, perhaps on the Wiki.

[brabax 0]

Any news on that ? Could not find anything about dialog definitions in the WIKI, just scripting commands.

[Jack Hammersmith 0]

one small hint.

look in your missions folder from arma.

there u will find a library mission.

extract it with unpbo etc. and there u will find some examples for the new GUI, description.ext. etc...

[Millenium7 0]

Went through Vektorbosens tutorial and like I said its FAR too sketchy it doesn't tell you jack. Doesn't say the font types (not that it matters with ArmA, managed to find that on the wiki), doesn't tell you what #define does or why you need it, doesn't tell you all the parameters for commands like style or type. Doesn't explain parent or class items. Nor does it tell you much relevant information such as defining things twice in ControlsBackground[] or Controls[] will crash the game. And it doesn't explain what such things do.

Its a very bad tutorial I taught myself I didn't learn much at all from it. Sure I copied some text but I could have done the same with any other dialog, it just doesn't explain anything. I need a tutorial not a presentation. Anyway I have figured out how to do what I want for the most part. But i'm in the dark as to how to do some things.

The most important thing I need to do right now is use a dialog to fill arrays. Its a multiplayer map and each player can bring up a dialog and select weapons and ammo. But they aren't equipped straight away the data is stored in an array and called later on to add the weapons and magazines to the player, different players have different selections so I need a dialog/script that works individually and doesn't give everyone the same equipment. So basically I have no idea how to get a dialog to store data in different arrays. I don't want to make 30+ identical dialogs and scripts for each player. Can I do this all with one and if so how do I get the dialog to pass its data on to individual players arrays set up on their machines.

This is likely to confuse the hell out of everyone so i'll just give an example

Fred, bob and joe are having a 3 player game and start with no weapons.

Fred and bob bring up their weapon/ammo selection dialogs. Fred selects M4 Aimpoint and 9 mags, bob chooses an m249, 3 belts and 4 grenades. They both click ok

Then later on when they set off a trigger they get assigned their previous weapon selections so fred gets the m4aim and his 9 mags, bob the m249 + 3 belts + 4 grenades and joe gets nothing cause he's stupid and forgot to get set up and so gets owned by an enemy soldier.

How do I do that? I have the dialog already set up, I just need to get it to pass data to fred, bob and joe's individual weapon and ammo arrays

[brabax 0]

one small hint.

look in your missions folder from arma.

there u will find a library mission.

extract it with unpbo etc. and there u will find some examples for the new GUI, description.ext. etc...

Thanks for the info, will give it a try when I'm back from work

[sickboy 13]

The dialogs run locally, so do the arrays and so do the weapon assigns etc. etc.

So you don't need multiple dialogs nor arrays etc.

If you want only certain weapons to be available to certain classes you can make a script that checks the type of the soldier and based on that makes a _weaponlist=[] and _maglist=[] array which gets accessed by the dialog.

Again...since this all runs locally (clientside)... choices, weapons, magazines etc do not interfeir between the clients

Hope this answers what you needed to know

[Millenium7 0]

Alright I thought that may have been the case but thats kinda screwed up another thing I was gonna implement later. I wanted individual weapons, ammo and other things with a couple of them only viewable through on a dialog page (player stats, money, etc) but they don't have to be changed. And I wanted 1 global pool for a few other things like vehicles. It doesn't HAVE to be global but i'd prefer it like that. Can you send local variables to other players and keep it in sync? I want to be able to view other players selected weapons, ammo and so on

[sickboy 13]

...

There are multiple ways how to do this... my first impression would be using dynamic variables based on playername or some sorts and sharing them over the network with publicVariable, but this doesn't support Arrays, altough since ArmA it does support strings, and with a little handy code you can probably transform arrays into strings and visa versa, but ur looking at quite some tricks then

I think you should wait with those features until CoC releases their NS (Network Services), as then it would be possible to send arrays over the network and synchronise many many things properly... In the mean time you can have "lite" version in your mission that just lacks the overview of their selections for the time being.

Another possibility is to broadcast their selections with player sidechat (etc) but this is ugly of coarse and not the way you wanted..

BTW... after the weapons are changed/added to the player, you can ofcoarse see their weapons etc in the gear menu on the map... you can aswell read the weapons/mags of the other players (weapons _unit), _unit = the unit you wish to see weapons from, into variables and display them in dialogs.

For displaying them in a dialog without creating multiple dialogs/arrays etc. you can of coarse use a listbox with the playernames and depending on the selection, load the variables used for the dialog, with the details of that player.

[Millenium7 0]

Well for the most part I don't have to send arrays. With weapons I only need the primary and secondary weapons really so everyone can see who's assault, recon, sniper, support etc etc. Money is important as are a few others but they are only strings. How reliable are the built in commands in staying in sync? Its not important to have all clients update at the same time but it is kind of important having the same values on each client. Anything under 5 seconds would be fine

[sickboy 13]

...

AFAIK In OFP there was no ensurance that the variables were received by all clients...

I'm not sure how this works in ArmA now...

The CoC ns has features that makes sure the variables are received and if not, they will be resent.

Having JIP even makes things harder, im not sure yet if we can use the "OnPlayerConnected", "FinishMissionInit" and "ProcessInitCommands" for getting these variables out... I also am not sure if the variables that the variables that were public variable'd... if they automaticly get sent by the server to the clients that join later... For now I played it on the safe side and put all needed variables in an SQF loop on the server, which publicvariable's every important variable every 20 seconds. Still have to do more tests though..

[feersum.endjinn 6]

For now I played it on the safe side and put all needed variables in an SQF loop on the server, which publicvariable's every important variable every 20 seconds. Still have to do more tests though..

Nah, every 20 seconds is bit excessive. Do it only when player joins via onPlayerConnected, it should work just fine (I'd test it myself but it's bit hard with only one PC capable of running ArmA at all )

[sickboy 13]

Nah, every 20 seconds is bit excessive. Do it only when player joins via onPlayerConnected, it should work just fine (I'd test it myself but it's bit hard with only one PC capable of running ArmA at all )

Thanks for the tip m8, still have so much to do, I'm possibly able to play ArmA daily and properly in about 6 months lol!

Not much info about onPlayerConnected in the wiki though... Will have a go with it soon and figure it out

[Millenium7 0]

Last thing at least for now. Can I get scripts to be executed on multiple computers? or more importantly if I use a script to set up an AI units position, waypoints, weapons, triggers and so on will it work or will this cause conflicts with the clients? I'll probably have to use scripts to set up scenarios or the map is gonna get VERY messy and will be a complete minefield for alterations. Can this be done or will it cause mayhem?. How do I do this? clients will trigger to run the setup scripts again through a dialog. Do I have to somehow get the script to be executed only on the server (if so how) or just run it as normal?

Basic example:

player 2 out of 3 players selects option 1 in the dialog and hits ok. A script spawns aiunit1 at a certain position, gives him 3 waypoints. Also creates a trigger if aiunit1 is killed then hint "unit dead"

Will the unit be on everyones screen or just client 2? will the other clients also execute the script resulting in 3 soldiers spawned? does the trigger work for everyone or just client 2? or does it just create a big mess.

The above has to be very reliable I can't have 1 client with 30 troops another only has 4. It must be identical for all clients

[feersum.endjinn 6]

You still need to get them executed at server, especially triggers though now with publicVariable accepting strings many things are a lot easier (you can for example transmit code as a string for server to execute through compile/spawn commands).

[sickboy 13]

...

Units run local on the machine where you spawn them, but they act global (e.g everyone can see them etc..).

In multiplayer games, all AI is running on the server computer, unless their groupleader is a player... in this case, the units run on the player's computer... at least.. believing the biki

I am uncertain if it generates problems, but as the dialog is local, the output is only executed on the machine where the dialog is ran, if it's running on 3 machines and 3 players all click on button 2 which will spawn 1 enemy, then there will spawn 3 enemies ...  if only 1 player presses button 2, then there will only be 1 spawn...

The proper way would be with a good client/server back-end... with the server being the only one who executes spawns and other data, while the clients functions as the front-end for this... but to get this working, it is again a better idea to wait for the CoC NS, as there are many functions and additions that pave the way and aid in these situations very well!

Hmm very nice addition from feersum... as you can now use strings and send them over the network and recompile them with the compile function, many things are a tad more easy to arrange now... you build up a piece of code, into a string on the clients and send that to the server, then you use a flag (false/true) which is put to true by a client if it wants the server to execute a command, you make the server loop and check if the mentioned flag becomes true, if it's true it executes the earlier mentioned variable (code in a string), you put the flag back to false and so it will keep waiting for the flag to become true again and run the next command that was put into a string by a client...

Altough this is not fault-proof at all, especially when there are multiple clients that are able to set the flag to true and update the command that needs to be processed...

I want to press once more... IF CoC is going to update their Network Services, then it would probably be foolish to invest massive amounts of time at this moment to get a system of the ground to make this work perfect, as their system will probably kick butt and got everything a man could ever need

As i'm working myself aswell on many server-client scripting for our servers, I will probably need to invest some time in getting a good communication going and central place of script executions etc... so I will update you guys along the way with my findings aswell

ps .. sorry if some parts sound a tad confusing, im having a bit difficulty in explaining all these things into text... in my head it's all clear though

[crashdome 3]

The proper way would be with a good client/server back-end... with the server being the only one who executes spawns and other data, while the clients functions as the front-end for this... but to get this working, it is again a better idea to wait for the CoC NS, as there are many functions and additions that pave the way and aid in these situations very well!

Isn't that how it works natively?

If a client calls a command to create a unit within a group other than his own, does the unit get created by the client or server(owner of non-player group)?

---------------------

One problem I notice is the tendancy for editing people to believe that all commands are assumed to run locally and that the engine is somehow more dumb than people give credit. It has it's weaknesses but I think we do not need a massive guaranteed packet delivery system for most purposes --- but it is nice for sending variable data that just HAS to make there to prevent having to sync multiple times, for example economy data for CTI, etc... --- However, by creating a proper script/function most needs of sending data manually via NS or PV can be eliminated.

Static Data: i.e. arrays of values that never change can be initialized on init or via the "OnPlayerConnected" event

Short-term Dynamic Data: i.e. the position of cargo being setPos'd beneath a chopper. - Send via PV and who cares if a packet is dropped? They live for a fraction of a second anyway.

Small Long-term Dynamic Data: i.e. a value which denotes a dynamic objective's location. Retrieve values only when needed. Populate the data via a server call. e.g. Player open dynamic mission dialog to get objective info. Send a PV asking for a request and have the client wait for a reply. If the server gets the PV then have it reply with the data and a confirmation. Then have the client respond back a reciept confirmation. If the server does not get the data use a timeout on the client and resend. If the client does not get the return data have the server timeout and resend.(This is a light weight semi-guaranteed system of delivery)

Large Dynamic Data: Store large arrays on client locally and send changed values individually. For example, someone buys a weapon and reduces quantity by 1. Send that command to all clients(dependant on upload bandwidth of client) or even better but at risk to server performance have client send to server which in turn updates all clients via a guaranteed message system (like CoC NS). Only in this situation do you really NEED a guaranteed delivery system.

As you can see only large amounts of dynamic data need to use an elaborate guaranteed delivery system like CoC_NS. Most other uses you can get away by building a small lightweight system or none at all.

Problem for me is most of my scripting revolves around these types of large and elaborate dynamic systems Which must be why I worship bn880 so much for his NS system.

[sickboy 13]

Agreed, and nice information Chrashdome.

Still, I prefer a general system/base that everyone/most will use. Manually creating scripts for little tasks here and there, big tasks here and there, yadi yadi, makes it not really compatible to other systems/scripts... as such I would prefer waiting for BN880 or any other CoC guy to complete CoC_NS for ARmA, as it will mean a good, versatile, universal system... which we all use to build upon, rather than every single mod or group of mods creating their own system

CoC_NS is not only capable of guaranteed delivery, but also not guaranteed delivery, exactly for the reasons you describe

BTW... I never really checked how CoC_NS sends/receives it's data over the network... I always assumed that they smartly formatted the strings/arrays etc. etc. and send that over by publicvariables....  but am I wrong? Can you make a real network system in SQF that is not based on public variable but works with sockets or whatsoever?

[crashdome 3]

I cannot verify for obvious reasons (no ArmA), but would believe that CoC_NS might work directly with Armed Assault as is.

Secondly, NS used to use PVs pre v2.0 iirc. Version 2.0 I *think* he converted everything (or atleast some commands) to use the init line of a created logic unit which allowed for strings to be passed more efficiently. I am not sure if BIS implemented a guarantee in sending the init over, but it was primarily guaranteed delivery just based on that concept alone IF BIS did in fact guarantee on some level that an init would be run on all clients.

However, in light of the change to PV to allow strings, it might be better to go back to using PV again? I dont know, you'll have to ask bn880.

Note: this is beginning to go OT. Perhaps we resurrect the old PV thread or start a new one?

btw, a light-weight system isn't that bad if you are developing a stand-alone package (such as an add-on) where you don't want to be dependant on CoC_NS. However, I think NS is such a good idea it should have been implemented by BIS to eliminate the headache for us. It's like BIS has their own idea of what should be sent over the network (positional updates and short-term data, etc..) and to hell with us who make elaborate systems of shared data (such as CTI, logistics, shared matrices, etc..). IMO it is the one obstacle that inhibits this engine above ALL others.... thats a strong statement which I believe to be true.

To tie it back to dialogs - to keep this on-topic, what is the point of using the dialog system if it is by nature of the engine limited to client only behavior? (e.g. death cams, cutscenes, etc..). CTI alone has proven that even the OFP engine is capable of far,far,FAR more.

[sickboy 13]

...

Ok m8, kicked off with a new thread, let's continue the parts about MP communication there:

http://www.flashpoint1985.com/cgi-bin....t=55778