Jump to content
Bohemia Interactive Forums

feersum.endjinn

Member
 View Profile  See their activity

  • Content Count

    528

  • Joined

  • Last visited

  • Medals

Posts posted by feersum.endjinn

  1. Posted

    So due to the new signs it is impossible to patch a pbo, you always have to red/l the whole pbo? If that's true -- and I guess it is when you say that -- many small pbos aren't a bad solution. That'd also make it ultimately easy to split work...

    You can patch the .pbo just fine, you just need to supply new signature file (I assume bisign files hold the authentication signature).

    I'm not sure if current pbo tools like cpbo handle SHA-1 authentication block at the end of the pbo properly yet but it shouldn't be too much of an issue.

    Whatever structure we go with only affects development process, final releases are better off made as full complete downloads since patching system just confuses users unless you have idiot proof installer but writing one is a lot of work (just witness trouble people are having installing 1.01 at times).

  2. Posted

    Hmm, completely I forgot about binarize requiring PAA header info for proper alpha channel blending, scratch that idea then.

    What we did with FDFmod was that during binarize process we copied config.cpp into p3d directory and removed it before packing model as pbo. Of course that approach has it problems as well, if for some reason script failed to remove config.cpp you sometimes ended up with multiple versions of same config in different pbos and it was bit random which one got loaded first...

  3. Posted

    For OFP/Resistance MLODs there was limitation of 32 characters for texture path which was one reason why OFP addon directory structures tended to be pretty shallow (and nondescriptive). Is this limitation still there in Oxygen 2.0?

    Alternatively, do P3D's, rvmat's and textures have to be in same PBO? Would it be possible to have structure where config, P3D and rvmat's were stored in single PBO and textures in another, as textures tend to be most space consuming part of addon (especially more so in ArmA). At least for sounds I don't see why they should be in same pbo as p3d's or configs...

  5. Posted

    Next thing to do is to agree on repository structure, in my opinion it should be same as PBO file structure will be.

    As what the PBO structure will be, I'd propose structuring it in so that every vehicle type has their models and textures in one pbo (tracked, wheeled, characters, everon.pbo), sounds in another (sounds.pbo) and configurations in separate .pbo. That way each part of a team can do their changes in one specific directory and test their parts only by rebuilding single .pbo at time.

  6. Posted

    (Made a new thread for this since other thread isn't really proper place for this discussion smile_o.gif)

    Yep, feer. I tried to open an OFPE p3d with ofp tools, that obviously didnt work, so I think the file structure is the same.

    The ODOL P3D's have version number embedded in first few bytes of file, it is worth checking if they have same version as ArmA models.

    Though in my opinion proper way would be to get MLODs from BIS (if possible, does BIS have rights to give them away or do Codemasters own rights to that material) and give them quick check they have every LOD required by ArmA. That would leave option of upgrading them to ArmA quality texturewise in later stages of project if desired so.

    It might be even necessary for some things like getting new animations and custom faces to work if they use old czecj selection names.

  7. Posted

    Yep, for me going from Nvidia 6800GS to 7900GS was like playing completely different game. 6800GS wouldn't simply be playable in anything higher than 800x600 and since I have TFT display, it would look just horrible due to display scaling it to its native resolution.

  8. Posted

    I do actually have the Elite version of Intro Island in Arma.....it just doesn't have any textures or layers.......a snowy desert island.

    How much OFP:Elite has common with ArmA in P3D and WRP structures? Lot of graphical features of ArmA were already in Xbox (fairly impressive IMO considering hardware Xbox has) and models might be fairly easily portable since they probably have proper shadow LODs.

    My experience with internals of Xbox version is mostly limited to snooping around PBO structure, config.bins and seeing how normal map textures were implemented but what I saw was identical to how things are done in ArmA...

  9. Posted

    The Itch @ Dec. 08 2006,03:14)]Also, what i did in my mission (soon te be released) is using the old ofp method. Create a east soldier, give him a high rank and a name and group your civilian units to him. Now write this in his init field: deletevehicle unitnameofeastsoldier

    deleteVehicle was very very dangerous command at least in OFP multiplayer - if you used it on unit that was already deleted you got instant crash. Now since init line is run on all clients when they start the mission, think what happens when they lag slightly at mission loading and server has already deleted that object...

  10. Posted

    At the moment it seems not too many addon makers are going to go with JAM in ArmA since main problem why JAM was invented originally was to solve magazine incompatibility between weapons. Now with cfgMagazines, such problem doesn't exist anymore.

    Instead of making things more complicated than they should be, I'd rather see addon makers base damage values on existing ArmA ammo classes or use existing cfgAmmo and cfgMagazines classes when applicable (30Rnd_556x45_Stanag, 30Rnd_545x39_AK etc). When it comes to small arms, default values are just fine - it was tanks is where biggest balance problems between addons were and JAM never solved that problem (nor it really can).

  11. Posted

    If OnPlayerConnected/OnPlayerDisconnected at least would provide something like the player entity that someone just joined in or left,but noo...... .

    As Wiki says: "Variables _id and _name are set.". If onPlayerConnected is set on init.sqs, it will be run on client as well and simple check like "if (name player == _name)" will let you identify if script is being run on connecting client.

    As almost all scripting functions that require object as a parameter have to be run on client where object is local, I don't think this is much of an issue.

  13. Posted

    It is more than a sound bug. When it happens, you can't see flash, recoil or smoke either, it is as if only bullet event is transmitted but not actual shooting event. And it happens to every player in that MP game, actual sound card hardware has nothing to do with it.

  17. Posted

    Not to sound like noob who knows nothing but tht first bit u posted where do i run tht from. Script/Init/Description?

    and where do i add the last one you posted. for when new players join.

    Put it into separate file, for example "weatherthingy.sqf". Then put into init.sqs line

    <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">spawn compile preprocessFile "weatherthingy.sqf";

    As for last line, you can add it into beginning of "weatherthingy.sqf" or directly into "init.sqs". It doesn't really matter where you put those scripts as long as they get executed at mission start.

  18. Posted

    Altough I would not keep a ?local server in the loop, but make a seperate loop for server and client, as now it keeps checking in the loop if it's a server or a client that is running the script, dunno what kind of performance thing that is, but at the very least it's not nececairy.

    I think performance hit is negligible, especially as SQF scripts are precompiled instead of parsing during runtime. You have to run setOvercast on server anyway as I think during rain you get more fog than on sunny weather and it may affect AI.

  19. Posted

    What you need to do is to have script that is launched on every PC at mission start. That script is fairly simple loop that check state of signal variable and if it has changed it acts according to contents of signal variable.

    Note that I'm writing this on work PC, so scripts may not work fully as I cannot test them smile_o.gif. You get the general idea though.

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

    signalWeatherChange = -1;

    // you need to have gamelogic called "server" to make this work

    if (local server) {

    // store initial weather to serverWeather variable

    serverWeather = overcast;

    }

    // loop forever while mission runs

    while {1 == 1} do {

    // when signal variable is zero or greater, it means someone activated the action and publicVariable has been broadcast

    if (signalWeatherChange >= 0) {

    // fade new weather in 10 seconds

    10 setOvercast signalWeatherChange;

    signalWeatherChange = -1;

    }

    // if script is running on server, store weather setup so we can broadcast it when new player joins

    if (local server) {

    serverWeather = signalWeatherChange;

    }

    // only check it every 10 second or so

    sleep 10;

    }

    and on your action you run following script

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

    signalWeatherChange = 1.0; // or 0.0 if you want it to set sunny weather

    publicVariable "signalWeatherChange";

    To make newly joined players get proper weather, also have following thing on run on server

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

    if (local server) {

    // when new player joins, broadcast weather state again

    onPlayerConnected { signalWeatherChange = serverWeather; publicVariable "signalWeatherChange"; }

    };

    Funny fact: OFP/ArmA multiplayer scripting is only time ever I've had to put stuff I learned in concurrent programming course at university into practice.

    edit: fixed syntax

  23. Posted

    I'm definitely looking forward to FDF for Arma! Still... it would be cool to be able using those sounds in the out-of-the-box missions. Or is it possible? I have to admit that I've never tried FDF for Operation Flashpoint as I (literally) heard about it for the first time only yesterday, when I stumbled upon that video on an ArmA fan site. I think I give it a shot.

    Yes, if you run standard OFP missions with FDFmod enabled new sounds are there. There's no reason why it wouldn't be same way in ArmA as well.

  24. Posted

    Those numbers seem bit random at medium range and don't really line up with hardware people have got...

    Better benchmark probably would be to have various complex scenes with units in them and have camera runs through city/desert/forest terrain at walking/land vehicle/aircraft speed and then have Fraps take minimum/maximum/average frame rates throughout whole thing.

  25. Posted

    Hmmm, Feer, something is wrong with your ArmA-Mark picture crazy_o.gif

    Not that I'd not like to have ArmA mark results like that, but... tounge2.gifbiggrin_o.gif

    Imagevenue sometimes gives out broken links and it just redirects to random image instead biggrin_o.gif With amount of not-safe-for-work stuff people upload there results can be interesting indeed. Should be fixed now tho.

×