KaRRiLLioN

Here's something else that doesn't seem to be working. I'm trying to define the buttons so that the text appears either at the top of the button or in the top left corner, but regardless of which style I use, I can't seem to get anything except left align, right align or center to show up. Here's the definitions in my description.ext: // Static styles #define ST_HPOS 0x0F #define ST_LEFT 0 #define ST_RIGHT 1 #define ST_CENTER 2 #define ST_UP 3 #define ST_DOWN 4 #define ST_VCENTER 5 I tried them all, but all the text does is simply go to the left side of the button. Neither ST_UP nor ST_DOWN seem to work, and I've tried them all. Is there something special I need to do? Here's my button class--I just left ST_CENTER in there for now. I'd like to be able to specify more exactly where I want the text to go. class RscButton { type = CT_BUTTON; idc = 1; style = ST_CENTER; colorText[] = {0.8, 0.1, 0.1, 1}; font = FontHTML; sizeEx = 0.025; soundPush[] = {, 0.2, 1}; soundClick[] = {"ui\ui_ok", 0.2, 1}; soundEscape[] = {"ui\ui_cc", 0.2, 1}; default = false; };

Do you want the teams as a whole to earn money, or do you want individual players to earn money at a different rate? There's a lot of different ways to go about it. Insofar as a permanently displayed credit amount, there isn't a great way to do it, since using titleltext will take up the middle/bottom portion of the screen, and using Hint will cause the "BLING BLING!" noise for those who have music turned on.

1.87 seems much better to me than 1.85, but the desynchs are definitely back and more extreme than 1.75. I have: Athlon XP 1900+ 1.5GB DDR RAM SCSI Hard Drives on a T-1 I really like the custom file size limiter, but I wish it would relay the message to the client. As it is, they only get a message that they were kicked...not why they were kicked. I'm looking forward to the netcode improving some more. Maybe Opflash should be optimized for a 6-way CPU server.

Correct. I kind of like the looks of the buttons over the Listbox though. I guess it depends on the application though.

I just figured a way around it and place the picture under the text of the button, so it looks like the button has text and a picture. If I could create columns and rows of buttons via a script like you can with a listbox, then that'd be great. The other issue is how to send specific variables to the Dialog that can be passed along to whatever script the buttons execute, and I haven't figured that out yet. It would be pretty vital to any multiplayer mission that uses dialogs I would think.

Nice tutorial, bigpoppa, here's a couple of questions regarding some of the info: I see from studying the BIS sample mission that you can create the listboxes and then using a script and the lbadd, etc. commands you can create a listbox from scratch and only define the basic shell of it. Is this possible at all with buttons? I'm creating a button menu with pictures, but from what I can tell I'm unable to place pictures on buttons with text. Also, there seems to be no command to create buttons from scratch so in description.ext I'm manually defining each button with a CT_STATIC as the picture next to it. I'm assuming i can place a picture on a CT_BUTTON but then I couldn't put text on it..correct? Also, In the MP mission I am attaching actions to buildings and players will come to building, select the action from their action menu, and the dialog will appear. I wish to use that building as the position to SetPos anything they click on in the menu, i.e. they click on the "Take Jeep" button. Then the button does this: "[Player] exec ""TakeJeep.sqs""; closeDialog 0" The problem is, in multiplayer, Player can be any of the non-AI players. With an AddAction script, you have the unit the action was attached to, the unit that exec'd the action, and the actionid. Does any such thing exist with the Dialogs? I know that since the Actions with addaction exec on a local client, then the dialog will only be open on the client, but I need to pass the information about which building the action was associated with and the actual unit that exec'd the action. Does anyone have any ideas? Thanks!

Where is the information on how to define dialogs like this? Is there a tutorial or some more info on it somewhere? If there is, it'd be a lot faster than me sifting thru this and the one Maruk made in order to figure it out. BTW great work!

Well you still can, even if you use the CreateVehicle method, but you'd have to create a new eventhandler for each vcl, I think since it'd be a new object.

It's another side-effect of the Setdammage respawn method. I used to respawn choppers like this and they'd come up looking like hell, but they'd fly. The CreateVehicle method starts it off fresh, but of course there are other issues that arise from that. You can get around the limitations though using Global vars that you declare as Public Vars and then have them used by another script to re-localize them if you're trying to use the Global var name of a vcl.

I use this for a timer script...dunno if it will help: TimeRemain=(Timeremain+.05)-((TimeRemain+.05) mod 1) Actually I think it's the same modulus, just written differently.

Setpos and SetDir, when called locally will have their data transmitted to the other clients. I know this because I had several clients test a VTOL script of mine that used to use Setpos and Setdir when they exec'd their actions on the action menu. Actions on an action menu are exec'd locally on the client and the Setpos and SetDir stuff is updated by each client. Also, when using my vrs.sqs script that respawns vcls using CreateVehicle, it is done only on the server, but the Setpos and Setdir info are updated by all clients after the server does it.

OK, here it is, the new updated RTS2.zip package. Â EDIT: I forgot to mention that I also added the Kamov, the Bicycle, and the Mini to buildable vehicles at the Tank Factory of all places. =) I've fixed and updated the new Nogova version to include two new features that are not present in the old island versions. HALO - High Altitude, Low Open -- if you get your aircraft over 200 meters in altitude, then you'll have this option. Â Basically you'll free-fall from the craft until you manually deploy your chute. VTOL - This is a very rudimentary script that I was working on in 1.75 using Setpos commands. Â Now that the SetVelocity command exists, I was able to create a dynamic method of allocating it in RTS2. Â That basically means that once you've researched VTOL at the Command HQ, you can have Vertical Takeoffs/Landings in any plane, even the Cessna (this ability will probably be removed for the Cessna eventually) I've noticed some other ppl are also working on VTOL systems. Â If they come out with something that works a lot better than what I have, I'll ask their permission to include it in RTS2. Get it at the usual place: http://www.aggression.org/karr/rts2.zip I'm getting back into working on the RTS2 versions with territory control. Â I'll probably concentrate on Nogova first. Â I don't know how long it will take me on this since I've gotten the basic templates done, all I need to do is decide how many and how large I want to make the capturable territories, and also what kind of rewards, etc. will be available. I'm also going to upgrade the economy so that workers won't earn much money anymore. Rather, you'll earn money by building industrial buildings in certain locations that you've captured, for example.

OK, here it is, the new updated RTS2.zip package. Â EDIT: I forgot to mention that I also added the Kamov, the Bicycle, and the Mini to buildable vehicles at the Tank Factory of all places. =) I've fixed and updated the new Nogova version to include two new features that are not present in the old island versions. HALO - High Altitude, Low Open -- if you get your aircraft over 200 meters in altitude, then you'll have this option. Â Basically you'll free-fall from the craft until you manually deploy your chute. VTOL - This is a very rudimentary script that I was working on in 1.75 using Setpos commands. Â Now that the SetVelocity command exists, I was able to create a dynamic method of allocating it in RTS2. Â That basically means that once you've researched VTOL at the Command HQ, you can have Vertical Takeoffs/Landings in any plane, even the Cessna (this ability will probably be removed for the Cessna eventually) I've noticed some other ppl are also working on VTOL systems. Â If they come out with something that works a lot better than what I have, I'll ask their permission to include it in RTS2. Get it at the usual place: http://www.aggression.org/karr/rts2.zip I'm getting back into working on the RTS2 versions with territory control. Â I'll probably concentrate on Nogova first. Â I don't know how long it will take me on this since I've gotten the basic templates done, all I need to do is decide how many and how large I want to make the capturable territories, and also what kind of rewards, etc. will be available. I'm also going to upgrade the economy so that workers won't earn much money anymore. Rather, you'll earn money by building industrial buildings in certain locations that you've captured, for example.

Well the best way is to test it out on a dedicated server with several players. I've had it where it worked fairly well in some regards, and other times it just kept looping over and over again as the vcl died over and over again on each client's machine.

The reason I asked about server-side is that i'm pretty sure, unless BIS put something in to make it run only server-side, that when an obj's eventhandler execs the script, then it will run on all computers. You can prevent this by placing a GameLogic named Server in the mission editor and then in your script place: ?(Local Server): before each line. Now the only catch to that is, I don't think the SetDammage portion will work properly if only done server-side. I seem to recall trying that and for some reason the info wasn't passed on to clients. The Setpos and SetDir info are passed correctly. Weapons info is passed correctly if done server-side. I haven't tested the SetDammage portion since 1.46 to see if it works server-side now, but it might be a good experiment. CreateVehicle I know works well, but the issue with that is you're going to have to pass the vehicle type information along to the script so that it will know it. This can be done easily, BUT the problem is that you must keep a maintained list of vehicle types in the script. I wish there was a way to extract type without doing it this way, i.e. like this: _type=Type _vcl since CountType seems to require more info. Anyway, here's a simple loop script that can detect the types for you: _WTrucks=["Truck5tOpen","Truck5tRepair","Truck5tReammo","Truck5t Refuel","Truck5t"] _ETrucks=["UralRepair","UralReammo","UralReFuel","Ural"] _CivTrucks=["TruckV3SGCivil","TruckV3SGRefuel","TruckV3SGRepair"," TruckV3SGReammo","TruckV3SG"] _Jeeps=["JeepMG","GJeep","HMMWV","UAZ","SGUAZG" ,"UAZG","Jeep"] _Cars=["Tractor","Rapid","RapidY","Skoda","SkodaBlu e","SkodaRed","SkodaGreen","Trabant"] _Helos=["Cobra","AH64","CH47D","OH58","UH60MG", "UH60","Mi24","Mi17"] _Planes=["Cessna","A10LGB","A10","SU25"] _WArmor=["M1Abrams","M60","Bradley","M113Ambul","Vulc an","M2StaticMGE","M2StaticMG","M113","BoatW" ] _EArmor=["T80","T72","BMP2","BMPAmbul","BMP",&qu ot;BRDM","BoatE","ZSU","T55G"] _Other=["Mash"] _Vehicles=_WTrucks+_ETrucks+_CivTrucks+_Jeeps+_Cars+_Helos+_Planes+_WArmor+_EArmor+_Other _i = 0 #Loop ? (_i > (Count _Vehicles)) : Goto "Skip" _VehicleType = _Vehicles Select _i _VehicleTypeDoesMatch = ((_VehicleType CountType _this) == 1) ? _VehicleTypeDoesMatch : _type = _VehicleType ? _VehicleTypeDoesMatch : Goto "Next" _i = _i + 1 Goto "Loop" This can extract the vcl type if you use CreateVehicle. I'd love to have a better way of doing this without having to loop through all of the types in an array because whenever a new vehicle is added, you have to add the type to the array. If you want an easy way to have all vehicles exec a script, then I think there's an easy way you can do that using NearestObject. I haven't tried this myself, since it's one of those experiments that I never got around to, but create an object somewhere on the map, maybe a GameLogic or a Invisible H and give it a name, like Detector or something. Using the same arrays that are in the loop above, you can have it loop through the array and do something like this: #Init _x=0 #StartLoop ? (_x > (Count _Vehicles)) : Goto "EndLoop" _type = _Vehicles Select _x _vcl=NearestObject [Detector, _type] !(IsNull _vcl):Goto "Exec" Goto "Skip" #Exec [_vcl] exec "respawn.sqs" #Skip Goto "StartLoop" #EndLoop I just whipped that up so it's probably bug-ridden, and probably wouldn't work right anyway. It's just a thought. What it might do it only detect one vehicle of each type that is nearest that object and exec the script for it and not detect any of the other vehicles of the same type, but like I said, just a thought. It really isn't too bad to have to put [this]exec "script.sqs" into the init of each vehicle. You can copy and paste and change vcl types pretty easily and each one you've copied from the original will still have the exec in it. Otherwise, I'm not sure if it's possible to detect empty vehicles using a East or West Present trigger type script. If so, then that might be useful. Hope this at least helps spark the creative juices a bit, even if it's not really workable.

Does this work ok for multiplayer by using the Setdammage command? In the past I tried the same routine where I would remove fuel and weapons and then setdammage gradually back to 0, then add fuel and weapons back. This seemed to result in multiple explosions, etc. for the vehicle since all clients don't process the same information at the same time. Also, this is executed client-side? I haven't had a chance to experiment with event-handlers yet. Currently I use one that detects the vehicle type, dir, pos, etc. and uses CreateVehicle server-side and then can also custom arm vehicles. Rather than wait on a vehicle to be completely "dead" I use @!Canmove _vcl in order to trigger the respawn. There are advantages to using the Setdammage method, such as being able to assign and keep global variable names without having to declare and assign them using the respawn script, so this interests me if it doesn't have the same issues that previous versions of respawn scripts using SetDammage had. It also means that I don't have to detect the vehicle type and several other things as well. Also, another dumb Q I have, in the respawn script where you have Count _this>1:goto "Alive". Tell me if I understand this correctly. The init of the vehicle execs the script the first time and grabs the info, adds the eventhandler, and then exits the script. Then when the vehicle is destroyed, it execs the same script again, and since this is the second time it's exec'd it, then the count is greater than 1? _this is one of those commands that I still don't understand thoroughly even though I've done a lot of scripting. Somehow it seems to represent an array? Like when it's used in CountType, for example. CountType looks for a count of a string, i.e. "M1Abrams" in an array, so if you have a vehicle exec a script like this: [this] exec "script.sqs" and then in the script _vcl=_this Select 0, then for some reason _this is like an array because you can then use the CountType command like so: (("M1Abrams" CountType _this) == 1) I've never really understood why it works like this, because I've tried variations on it, i.e. _vehicles=[]; _vehicles=_vehicles+[_vc] and then tried the CountType on _vehicles. Ah well, sorry to get far afield, but I was just trying to understand how Count _this could be >1.

I'm going to leave my 1.85 server up for at least one more night before I decide whether to revert back to 1.75. Currently I'm running it on the following config: Athlon XP 1900+ 1.5 GB DDR RAM Windows 2000 Server SP 3 On 1.75 the main issues revolved around losing players whenever a new mission started. Almost every time, depending on the number of players, at least 2 players would immediately drop off. Sometimes they might not drop off, but would be ghosted ( 0 ping) when new mission started. Sometimes when I did a #reassign, some players would also be ghosted. 1.85 doesn't seem to suffer from that, but rather is very jerky, i.e. some players are playing several seconds behind or several seconds ahead of me, thus causing mass confusion. It seems very chaotic and hard to accomplish anything. We played with 13 players, and we played with 7 players and it seemed pretty much the same each time. Desynch went from 0 to 10000 at random intervals. Perhaps there is a new setting we should try in our server cfg file? I hope it's that simple. I'm sure that BIS wouldn't have released this if it weren't working well for their testing.

I haven't had a chance to test it. The Nogova version was hacked and modified by me to try and work around the bugged NearestObject command, but now that 1.85 is out, I'm going to test the regular RTS2 that I didn't modify. It should be plug-n-play with 1.85. You can test this by playing one of the other island RTS2's in 1.85. I'll start checking on it myself once I have a chance.

I haven't had a chance to test it. The Nogova version was hacked and modified by me to try and work around the bugged NearestObject command, but now that 1.85 is out, I'm going to test the regular RTS2 that I didn't modify. It should be plug-n-play with 1.85. You can test this by playing one of the other island RTS2's in 1.85. I'll start checking on it myself once I have a chance.

On my Win dedicated server 1.85 here's what I do: I login as admin, enter #missions If no missions show up, then I #logout and then log back in. Almost every time the missions show back up again. I think this is because the Whatchamacallit isn't whizbanging the whatzit, or something to that regard. Sorry about the technical jargon.

OK, I'm just making sure that maybe my T-1 wasn't having a bad night or something. In 1.75 other players have said that they notice lag, although I'd say for the most part I have almost never had issues with it unless I'm in a vehicle with someone who has a higher ping, and even then, it's bearable. Last night the desynchs would be 0 for one minute, then shoot up to 10000 so the next. While I can say it seemed that nobody dropped as from the server (a regular occurence in 1.75) it was barely playable. Also, I don't think anyone was "ghosted" last night, i.e. getting a 0 ping and thinking you're connected, but you're sort of not...strange stuff. Welp, hopefully this can be sorted out soon. Right now I'm in the middle of playing Hitman 2: Silent Assassin, and I plan to go back to playing more opflash once I'm done with it, so I need this fixed by then.

How has the lag been for ppl? After I updated the dedicated server and several of us got on, it seemed a lot more jumpy, i.e. ppl disappearing and then reappearing several meters away. The desynch seems to be going higher. I almost never had any lag issues with 1.75. I tried rebooting the server and such, but it didn't seem to help. I'm just curious what other ppl's observations are on this.

Nekkekami, That can be solved with scripting. In my CTF scripts, if the flag carrier is killed, then the script can wait for x number of seconds and then return the flag. That way you don't also run the risk of someone dying in the water or something, making the flag impossible to retrieve. If someone takes the flag from the body before the timer expires, then the new flag carrier can still capture it. Many more new options will be available now with 1.85. If I'm reading the new script commands correctly, then the new eventhandlers portions would seem to make available Kill detection, which is a very nice thing to have. Imagine a CTF where you can award points based not just on taking the flag and capturing it, but also killing/defending the flag carrier, etc. I'm also thinking of assassination missions where knowing who killed what is important to scoring. This will open up several new avenues of mission making. An aircraft carrier is my big wish to one day see. =) Also, the SetVelocity command will be great. I have some scripts that allow a person to drive the LST around, but SetVelocity sounds like it would be much better. It would also seem to add the possibility of having "turbo" options on cars. Imagine this: you drive your car until you get over 60KPH or so and then an action appears allowing you to use turbo. The turbo script could then set your car speed to something really fast, allowing you to catch major air as you fly off the church cliff (near the bridge on Nogova) and fly across the river! =) It might even be more funny with bicycles!

</span><table border="0" align="center" width="95%" cellpadding="3" cellspacing="1"><tr><td>Quote </td></tr><tr><td id="QUOTE">a Mi-17 without rockets but a PK instead<span id='postcolor'> Actually things like this are already easily done via script. I have a vehicle respawn script that can take most vehicles and add/subtract weapons from them. Typically I have my script remove all rockets from the Mi17 since it's such a spam-machine and replace it with a 30mm cannon. I also sometimes remove the large rocket magazines from other aircraft and replace it with the OH58 14-round version just to make things more interesting, and I also added a Browning MG to the OH. All of this can be done without addons using scripts. It is also possible using script to respawn with an entire squad at your disposal. There currently isn't a good way to make you respawn as a member of that squad in a normal CTF mission, for example and then be able to start over after your squad is all dead, but it might be possible. But using normal "base" respawn techniques, whenever the leader of the group dies, i.e. the player, then you could delete all members of the group and create a new group at the respawn, and the player becomes the leader for them. There's a great flexible script for this that allows you to even use vehicles, etc. to respawn with any combination of soldiers and crew so there's a ton of stuff that can be done via script already.

In the briefing for this mission it says to use the radio code 0-0-1, but nobody seems to have the radio available. the support vehicles will then just sit at base and you have to go all the way back. After defeating all of the enemies at a base, the objective still is not met for some reason. Is this a bug, or must you do something more at each base?