Jump to content

baddo

Member
  • Content Count

    1295
  • Joined

  • Last visited

  • Medals

Posts posted by baddo


  1. Just to add, this could be modified to something like this (no UnitName variable at all):

    <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">_Vloop = 1

    #ALoop

    call format ["%1 =""Jeep"" createVehicle getpos _thespot",format ["V%1",_Vloop]]

    _Vloop = _Vloop + 1

    ~1

    ?(_Vloop < 4):goto "ALoop"

    Note the added delay which can be a good thing to do when creating lot of objects. If no delay is in the loop and there are lot of objects created, the player is very likely to experience a heavy lag peak when all the objects are created.

    Also if you really don't want a delay between your createVehicle commands, you could shorten this to one line:

    <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">{call format ["%1 =""Jeep"" createVehicle getpos _thespot", _x ]} forEach ["v1","v2","v3"]

    This is suitable for relatively small number of objects to create so you won't need to type too much into the array plus the lag peak will not be that big. Also a situation where you know in advance how many objects you will create will be better for this than a dynamically changing situation.


  2. An event handler would be much better for the job because it would not consume nowhere near as much processing power than a looping script checking a trigger's list. Here is an example how to use killed event handlers to punish players if they go and kill civilians.

    Put this to initialization field of all civilians which you want to have the penalty attached:

    <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">this addEventHandler ["killed",{_this select 1 setpos getpos jail}]

    Then put an invisible helipad/whatever to a far away island in the map, name it jail and then go and kill the civilian having the event handler.

    Of course you can start whatever punishment from the event handler, it's your choice. Maybe a small delay before the punishment happens would be nice, with a text saying that the player went too far and must be punished and sent to jail/whatever.


  3. I propose that you don't restrict your tutorial to only "Grouping", but you could instead make a tutorial about how to use the mission editor in general. Once upon the time I was trying to figure out how to use the editor, I didn't have access to Internet and thus I had a hard time figuring it all out by myself.

    Shame on you BIS, why didn't you give a manual with the game! The one you pretended to be a manual, was rubbish and you know it. Hire people who know how to write documentation if you can't do it by yourself.

    So back to you, Nightjay0044. Make a tutorial which explains all the keys etc. you can use in the editor, and provide a lot of visual material to show for example how to synchronize triggers and how to group units. You could make for example GIF image animations of how to do these things.

    Regards,

    Baddo

    P.S. Just a friendly suggestion: do not ask people to give you an intro to making tutorials. Now think about it for at least 2 times, who would do that for you?


  4. hardrock, doesn't that line I posted do the same thing a bit easier...? Just convert arrays to strings and then compare. Works for all kinds of arrays.

    OFP has a limit on how big it can make strings (1024 or something?). If you try to 'format' an array and the resulting string is longer than that, it will crash the game. So for arrays that you know are going to be of a small enough size, format works fine. But otherwise you should use the posted function.

    I think the limit is (or should be) 2048 characters per string.

    I did a test like this:

    1. increment string to hold 2048 characters

    2. call format ["%1",string] ---> OK, no errors

    3. increment string up to 2055 characters, ---> OK no errors with call format ["%1",string]

    4. increment string to 2056 characters, error message displayed on screen, but no CTD still...

    5. increment string up to 2059, same error message but no CTD

    6. increment string to 2060, finally a CTD smile_o.gif with call format ["%1",string]

    I tested this a couple of times and everytime the result was same.

    Hmmm... what to say from this... I would say don't exceed 2048 chars in a string. It is possible that when you use some other functions which take a string as argument, you can get different results for the accepted string length until error messages or CTD appear. I only tested format so that's only a guess.

    But yes, for comparing two position arrays format ["%1",getPos obj1] == format ["%1",getPos obj2] is an ideal solution as I see it. Of course BIS could overload the == operator also for comparing arrays so we could compare arrays and especially long arrays more easily... if it would be CPU intensive then so what? It's the scripter who uses it excessively, not the programmers of the game right?

    smile_o.gif


  5. You can compare two arrays using format command to turn the position arrays into strings first. OFP's condition lines accept only number, string, object, side, group and boolean type of variables but not arrays.

    Example condition:

    <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">format ["%1",getPos obj1] == format ["%1",getPos obj2]

    But I think you will not get very good results by comparing positions, because it is very unlikely that they will have exactly the same values even if the objects look like they are at the same position. They need to be exactly the same if you are going to make your condition to work. Checking if one position is close to another position should work a lot better. You can use the distance command to check distance between two objects. If you measure distance in multiplayer, do it only in the server.


  6. Hi,

    do you have the scroll wheel enabled from Windows XP settings? The scroll wheel doesn't work in any program?

    You can check it from... hmm... what was it in English: control panel - mouse - there should be a box where you can select how the scroll wheel is detected - change it to something like "expect the scroll wheel is present". Can't check what it exactly is on my computer without uninstalling mouse driver... but it's there. Now go check it!

    :P


  7. Sad to hear you have been losing team members. But that's life, people find something new to do and they have to let something else go.

    For a long time it was only FDF Mod that kept me playing OFP. Being a Finnish Defence Forces reservist of course has influenced this a lot. I have always been very amazed of the high quality sounds that you guys made for The Mod. When I fired the RK62 for the couple of first times, it made me feel like I was back in the real FDF! I think the weapon sounds are the best thing in the whole Mod. A big thank you for that.

    smile_o.gif

    I am eagerly waiting to see The Mod in Armed Assault. The Team really deserves a break from modding. But I am sure you guys have your motivation back once Armed Assault is released...

    thumbs-up.gif


  8. For sure cheaters can totally ruin mp missions... I've seen it many times and the lesson was; choose the server wisely and maybe play only coop missions. So, servers where obvious cheaters are allowed to play will not see me there anymore. My last serious attempts at playing OFP online were in Spring and every attempt was stopped by a cheater (obviously wrong server choices) so I decided to give online playing a rest...

    Getting multiple tanks spawned in front of your eyes, or getting thick fog just when you are aiming at an incoming enemy tank with your RPG  launcher aren't the kind of things I am looking for from multiplayer gaming.

    But.

    What comes to how Armed Assault / Game2 will detect cheaters: I really hope it is not a system which kills innovative modifications like DXDLL or fwatch. The game developers of Bohemia Interactive Studio are also learning from the mods made by the community. Seeing what the community does to the games they developed will help them to get ideas of what the community wants to see in their games, no? DXDLL and fwatch are good examples. But time will show what we'll be facing in the future. Maybe we don't need any mods because the games will be so good right from the release, no?

    biggrin_o.gif

    That's a no vote for PunkBuster. The anti-cheat methods BIS will implement will be at least as good as any Buster. Because it's only a matter of time when someone breaks it, no matter if it's a Buster or Bohemia Interactive Studio's own Busta-system.


  9. I've used this tool since it dawned ages ago, it's great smile_o.gif

    But I'm having problems installing this new 3.1... confused_o.gif

    'System cannot open the device or file specified'

    No matter what I specify as a location for the install...

    And yes, I'm running XP (SP2)...

    And I have rerere-downloaded the file many many times.... etc... sad_o.gif

    You could try running the installation program from a user account that has full privileges to your computer (admin account). If you are not already logging in with full privileges (which is very bad) everytime...


  10. 1. Place a game logic to the map and give it a name ("server" recommended but not compulsory).

    2. Use the following to start the script on server only from a script like init.sqs:

    <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">? (local <NameOfYourGameLogic>) : [] exec "r.sqs"

    If the game logic is named "server":

    <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">? (local server) : [] exec "r.sqs"

    This should work.


  11. OK I'll give my ideas to the correct thread too... so here goes:

    1. EVENT HANDLERS IN GENERAL

    Mission designers should be able to select the visibility of each event handler. In other words one should be able to choose if the event handler should be executed globally, locally or only in the server. This should of course concern every event handler type. This would make event handlers much much better for use in multiplayer.

    2. 'DISCONNECTED' EVENT HANDLER

    Maybe there is already coming a good system for OFP2 to handle disconnecting from middle of game session, but anyway:

    An event handler which detects if a player has disconnected from a multiplayer game session would be a really handy one. It could be used to delete the disconnected player's unit or anything else the mission designer wants.

    Deleting units left behind by disconnected players could also be done with a setting in the description.ext file or equivalent. Like a boolean variable deleteDisconnected = true/false. This method should not exclude the 'disconnected' event handler.

    I think that it should be up to the mission designer how to treat a unit left behind by a disconnected player. Delete it or leave it as AI, both just fine for me but let me choose it, please.

    smile_o.gif


  12. @ Fork122

    With documentation I meant (sorry for not stating it clearly) that the game package should include (should have been included for OFP1) the command reference and a proper guide for the mission editor in digital form (it's still documentation). That is a fair expectation for a game that has a mission editor and a big part of mission editing can be done with the scripting language. And I really do not want paper copies of the command reference or tutorials.

    biggrin_o.gif

    Of course I am happy with what BIS has given to us to this date. But because they are professionals they know they should have released proper documentation at the first place, regarding the mission editor and the scripting language, not addon creating. My guess is that they ran out of time and resources with the documentation side when doing OFP1 and I hope it will not be the case for OFP2. As I already said, BIS could be a good example for other software companies in how to document their products.

    @ hardrock

    Will that updated version of the command reference be an unofficial version? Well anyway that's good news to all of us and I am looking forward to seeing it. Great!


  13. Here's a few of the many points that have popped into my mind during the years with OFP:

    1. DOCUMENTATION

    In the software industry companies tend to release products without proper documentation or sometimes, practically without useful documentation at all. Why not BIS be a good example and release OFP2 with full documentation for the mission editor (not like the crap that came with OFP1, with all respect to whoever made that...) and for the scripting language, including full list of actions and animations and how to use them etc... stuff what the community had to figure out for OFP1 with little or no help at all from BIS.

    The command reference should also include information of how commands behave in multiplayer environment.

    Generally everything that can be used in mission editing should be properly documented and released to the public by BIS with the game. Why? Because there is a mission editor in the game. Is there...?

    tounge_o.gif

    And because the quality of the product skyrockets if it has proper documentation with it.

    I am not asking to include documentation for addon creating, that's probably too much to ask. But it wouldn't hurt either.

    2. EVENT HANDLERS

    Mission designers should be able to select the visibility of each event handler. In other words one should be able to choose if the event handler should be executed globally, locally or only in the server.

    3. 'DISCONNECTED' EVENT HANDLER

    An event handler which detects if a player has disconnected from a multiplayer game session would be a really handy one. It could be used to delete the disconnected player's unit or anything else the mission designer wants.

    Deleting units left behind by disconnected players could also be done with a setting in the description.ext file or equivalent. Like a boolean variable deleteDisconnected = true/false. This method should not exclude the 'disconnected' event handler.

×