Home   Help Search Login Register  

Author Topic: Determine mission completed & creating a .pbo with scripts  (Read 2198 times)

0 Members and 2 Guests are viewing this topic.

Offline Nutty101

  • Members
  • *
So I am positive there is something i am doing wrong because i cannot for the life of me get addons to show up with the isclass (configfile >> "xxx" >> "xxx") command. Always false results. I need this to allow people to use my software and determine if the server has it installed. I want to put all the scripts into a single pbo for easy installations.

I have a config.cpp in the pbo in addons. Am i putting it in the wrong location?

Also how the heck can i determine if a mission is completed/over? Been trying to figure it out but it's beyond me.

Offline Nutty101

  • Members
  • *
Re: Determine mission completed & creating a .pbo with scripts
« Reply #1 on: 25 Aug 2007, 23:32:41 »
Also another quicky, are there any methods to block a publicvariable from changing a variable's values?

Offline h-

  • OFPEC Site
  • Administrator
  • *****
  • Formerly HateR_Kint
    • OFPEC
Re: Determine mission completed & creating a .pbo with scripts
« Reply #2 on: 26 Aug 2007, 14:47:35 »
Don't double post.
If you have something to add to your post after a short period of time modify it instead of replying to yourself.
Project MCAR   ---   Northern Fronts   ---   Emitter 3Ditor
INFORMATIVE THREAD TITLES PLEASE. "PLEASE HELP" IS NOT ONE..
Chuck Norris can divide by zero.

Offline Mr.Peanut

  • Former Staff
  • ****
  • urp!
Re: Determine mission completed & creating a .pbo with scripts
« Reply #3 on: 26 Aug 2007, 17:47:29 »
I can answer your quicky first ... You can not block publicVariable. However, there are ways to send data to selected clients or the server. For OFP this was done with the Chain of Commands much underused Network Services2. sickboy has an updated version he has made for 6th sense called Network Services Lite. Search for it on the BI forums.

In OFP the hack was made using the init field of a createVehicle'd game logic to broadcast code. Now we have the setVehicleInit, processInitCommands, and clearVehicleInit. I have not taken a look at the Network Services Lite, but it probably uses these commands using a single static game logic

Problem is the sixth sense wiki is down...

Your question about the mission over.  You mean detect on all clients and server if misison is over? You set that yourself by choosing a trigger of type End1,End2,End3 etc.  Most robust way to do this in MP is to have 2 triggers. The first detects the conditions you have specified to end the mission and uses publicVariable to send a boolean flag value e.g.
Code: [Select]
bMissionEnd1 = true; publicVariable "bMissionEnd1";The second trigger is set to the end type you want and uses the boolean value as it's condition.


Please ask questions with different topics on serparate threads. Your first first is an addon question. Your second question is an MP editing question, and your last question is advanced. Best way to get them all answered is to post each on the correct board.
« Last Edit: 26 Aug 2007, 18:41:45 by Mr.Peanut »
urp!

Offline Nutty101

  • Members
  • *
Re: Determine mission completed & creating a .pbo with scripts
« Reply #4 on: 26 Aug 2007, 20:07:33 »
Sorry for not editing, didn't think a first poster would be allowed to modify their post right away.

 For the mission I can't place a trigger in the missions as i will never touch them. What I need to do is figure out when a mission end's to signal external plugin's that the mission completed. I have been trying to figure it out in the memory space but I have not had any true luck outside the console text and i am trying to avoid using that. The reason is that I am trying to ensure the new DSTS version will be usable by VBS 1/2 and Arma/OFP as well since people have begged me to keep it working on all versions. So i was hoping that there is something in the scripts to determine if a mission completed.

  As for the public variable I am trying to keep any from changing the values that are stored internal. The configuration I am trying to put inside a PBO but there are values that people could public variable to change around. It wouldn't be a show stopper but I am trying work around a client's attempt to break the internal scripting for it.

Offline Mr.Peanut

  • Former Staff
  • ****
  • urp!
Re: Determine mission completed & creating a .pbo with scripts
« Reply #5 on: 27 Aug 2007, 02:45:19 »
Quote
What I need to do is figure out when a mission end's to signal external plugin's that the mission completed.
So you need a script in your addon that will detect that the mission has ended? For that to be possible you would need to know how ArmA behaves when a mission ends, specifically, how does it terminate all scripts. Because if the mission ends and all scripts get terminated, your detect end script gets terminated too. You need to ask someone who worked on ECP, like Zaphod. He is still around on the BI forums.

Quote
... I am trying to keep any from changing the values that are stored internal. The configuration I am trying to put inside a PBO but there are values that people could public variable to change around.

You better ask this one on the addon boards. Isn't there a way to pack a signature(based on md5sum or the like?) in an addon such that the server can tell if not all clients have the same addon? Or at least to detect a modified config? Like I said, better ask this one in the addon boards.
urp!

Offline Nutty101

  • Members
  • *
Re: Determine mission completed & creating a .pbo with scripts
« Reply #6 on: 27 Aug 2007, 03:11:54 »
So you need a script in your addon that will detect that the mission has ended? For that to be possible you would need to know how ArmA behaves when a mission ends, specifically, how does it terminate all scripts. Because if the mission ends and all scripts get terminated, your detect end script gets terminated too. You need to ask someone who worked on ECP, like Zaphod. He is still around on the BI forums.
Ahh, you gave me the answer right there. I just check for a lost ping to the application and it can tell in a few seconds. Not perfect but it works to let plugins know that the mission ended. :)
 
You better ask this one on the addon boards. Isn't there a way to pack a signature(based on md5sum or the like?) in an addon such that the server can tell if not all clients have the same addon? Or at least to detect a modified config? Like I said, better ask this one in the addon boards.
Ill ask around, the clients will never need the addon so we should be cool on that portion. Just need it so scripts can tell if the program is installed to fire off the init scripts to connect to the external application and plugins.

Offline Mr.Peanut

  • Former Staff
  • ****
  • urp!
Re: Determine mission completed & creating a .pbo with scripts
« Reply #7 on: 27 Aug 2007, 15:17:22 »
Quote
I just check for a lost ping to the application and it can tell in a few seconds. Not perfect but it works to let plugins know that the mission ended

Could you humour me and elaborate on this? Are you saying your scripts will temporarily abort and then your app will pick up on this(no new data to file or memory)? I am interested in DSTS(tried getting it to work once writing position info to a file, unsuccessfully  :shhh:) and found the original thread leading up to kwatch pretty interesting. Are you using the same method for DSTS i.e. detection of loadFile command on non-existant file? And how on earth do you map the memory of a application like ArmA?

My own interest in DSTS was related to something you removed in your last version, a DSTS for clients. Awhile back Mandoble was asking about whether ArmA could do overlays i.e. like a dialogue but only for information display and without hanging the game controls. Mandoble wanted a transparent overlay for his MandoMissile that could be used for ancillary data display. I suggested it could be done using DSTS, a small visual basic(or c++) program, and a commercial screen overlay application. I know it could be also coded pure vb/c++ but I lack the directx skills to do this. A DSTS dll would also be needed and FPS would  be an issue with a directx overlay.

I think you should continue to make a client version. People will always cheat, so why punish everyone else? DSTS offers a wealth of opportunites to enhance SP gameplay in ArmA and provide new features that will never come from BI.
« Last Edit: 27 Aug 2007, 15:22:49 by Mr.Peanut »
urp!

Offline Nutty101

  • Members
  • *
Re: Determine mission completed & creating a .pbo with scripts
« Reply #8 on: 28 Aug 2007, 01:11:14 »
Could you humour me and elaborate on this? Are you saying your scripts will temporarily abort and then your app will pick ..

The 2.0 app uses just the memory space to pull information so no more loadfile with strange formats. It's not as fast to initialize as catching the loadfile but once running there is no comparison to it for speed and it does not lock the game up. I am running into cpu usage issues at the moment but i have some ideas on how to tame it somewhat. Main issue is that each island is loaded differently along with objects. My first try worked only on the intro island, however now it works on anything you put into the game though takes a bit to get online and working with each map. I am also allowing people to design MFC, Com and Dot.Net dll's to plug into the main application. With that they will be able to implement anything they could really dream of to the server. Be it thru DSTS or whatever, their choice.

The new version could be used on anything that you can stuff data into really (Sorta). However I made the decision to make it a nice tool for the whole dedicated server. Recent changes to the project are allowing it to work with the clients (Even the wrapped versions i could not touch before without obtaining a copy and they were changing with each patch). So this new one will make quite a few people happy. The exe will run as a commandline, windows service or windows forms so you can do whatever you want with it.

As for an overlay, i think we could do it thru the plugin system to be honest. If i revert to a single channel into DSTS then you can refresh at 25ms and maintain 0-2% cpu on a 2.0ghz machine. The first idea i had was able to update the location to almost 400 vehicles every second to an external application to see if it would work. It did, but that was a single variable in the game moving that data. Now i'm trying to get it so we can communicate directly to the system via some simple scripts i wrote. It works but the cpu usage is more while processing the memory space. Though you have direct access to the system outside and inside. You can push values into the game from a plugin as well as push info to the DSTS from scripts inside. I have been meaning to finish up a demo that shows arma and an external map that lets you drop units into the game while its running. Works thru the dedicated so you don't need to have the Arma client up at all. I just wrote a plugin that the panel system loads and it communicates thru the dsts plugin.

Example:
player sidechat format["%1",["HeLLo"] Call DSTS_STRING_TOUPPER];
Would return HELLO not HeLLo. All you need to do is call the init script and give the system about 5 seconds to setup coms to the external app. Once that is done everything is linked until the mission is done.


Current plugins: (Not all are working 100%)
 Logging - Central logging plugin
 TCPServer - Simple ip interface to talk to plugins.
 Telnet - telnet app to control the server remotely
 DSTS.V2  - Really the main thing behind all this but not required.
 DedicatedRemote - Ability to change passwords, modify the config (To a degree), monitor chats, see client commands sent to the server, with the sockwall you can autodrop connections from users with bad id's.
 SockWall - Firewall application that will let you ban users from arma via IP, this is a kernal level ban however.


I have a position demo with the old version that uses SQLite for a database. Nothing major but gives ideas on saving data and restoring it to the game. If anything i would wait until i get 2.0 into a beta stage. Will be much better then.