Stian GH

cosmic10r: ​Classname: Land_Atm_01_F Eden Editor: haleks: Aha, I see. Just because I'm curious, and if it's easy enough for you, can you post a list of objects you disabled? So I can try to figure out what's been causing the other crashes (if indeed this is the unitary source of those crashes).

Crash Update: I've been able to totally consistently reproduce the same type of crash (0xC0000005 memory error) and it only occurs when Ravage is loaded​. Here's how I produce the crash: ​In one way or another (editor, zeus, script), place an ATM on the map: Crash (at least for me!). I believe this is because of the "ravaged" look in Ravage. I dunno how this works, but I'm guessing there are some modified config files to swap some textures, and the ATM is somehow misconfigured. I don't think that the crashes I've been experiencing have been exactly because of the ATM, but I'm guessing other objects are subject to the same misconfiguration, and that every now and then such an object has been spawned and caused crashes. Please let me know if you also experience a crash to desktop when spawning an ATM (for example, search for it in Props in Eden Editor) when the Ravage mod is loaded, and if you do, Haleks, pretty please fix :D

Crash Update: Today we played through the whole evening without a hitch. There's one thing, though: I hosted the game from Eden Editor. :huh: :blink:

Hey haleks, I'm having some bad issues while playing Ravage with my mate. We're playing: Arma 3 v1.58 Listening server (not dedicated) Version 0.1 of the escape mission by Bad Benson, Evil Organ, Tourist & CosmiC Mods: We keep getting crashes. Every once in a while, after maybe 15min, maybe 30min, there's a 0xC0000005 memory error, sometimes "The memory could not be written", sometimes "The memory could not be read". It would've been kinda livable if it wasn't for the fact that usually (but not always, wtf) this crash corrupts the save and we have to start all over again; Dunno how many times we've looted that damn lighthouse by now! I've Google'd around, but couldn't find anything which fixed the issue. I suspect, but am not sure, that it might have something to do with saving. (Or maybe there's a misused array somewhere i.e. trying to read an out-of-bounds index?) To test if the issue was related to saving, I slightly modified the last few lines of MPsave_init.sqf: systemChat "Initiating multiplayer save loop."; while {alive player && !isMissionEnded} do { systemChat "Saving character..."; uiSleep 3; call rvg_fnc_saveMPplayer; uiSleep 3; systemChat "Character saved."; uiSleep 60; }; It just prints some text 3 seconds before saving (to give me some time to notice it) and confirming the save after another 3 seconds, and also limits saving to once per minute. I added the 1 minute delay because I thought that maybe the save would sometimes take a little too long, and another save call would overwrite mid-way through the first save, causing corruption. I haven't actually had a chance to play with this modification for long enough for there to be a crash yet. Will report back to you if the crash occurs within 3 seconds of "Saving character..." having been printed. While I haven't had a chance to test for the crash, I did discover that something is definitely up about the save loop: It is running several times in parallel. While playing, I've seen the loop running 3, 5, 8, etc. times in parallel, meaning: I initially get 5x "Initiating multiplayer save loop." prints, then 5x "Saving character..." prints, and then 5x "Character saved." prints. And sometimes those prints are happening with different delays, sometimes interleaving. So even with the 1 minute sleep, there is a whole bunch of saving happening simultaneously. Imagine what it's like when it saves every second (which is the current published state of the script). I also discovered that this multiple simultaneous loops issue does not occur when testing from the 3D editor ("Play in Multiplayer (MP)"). You have to host it normally. My friend, who's using these same modifications and connects as a client to my listening server (not dedicated), also get's multiple printouts. I also added this as a first line to fn_writeSave.sqf: diag_log format ["%1, %2", time, "Ravage: Writing save file."]; I'll get back to you with a RPT when we're unfortunate again :/

​This!

Nice one. Also check out: Feature Request - Change stance while switching weapons.

First of all thanks for weapon switching on the move! I have a feeling this isn't the right place for this request, but here it is anyway: A further improvement to the feel and flow of character control (which is cruicial!) is to implement changing stance while switching weapons. I have noticed that reloading is already possible while switching stances. (Also check out Feature Request - Switch weapons interrupts reloading.)

Reported some issues with Weapon Switching on the Move.

The character undesirably moves a step backwards when: Repeatedly pressing the key bound to the action "Crouch / Stand Up" (in Infantry Movement) while holding binoculars, causes the character to move backwards. The backwards step performed when going from Standing to Crouching looks natural and is possibly intended, but if this is so, then when returning to Standing from Crouching a forwards step should be performed so that the character ends up in the original location.

Hopefully this is the correct place for me to report these issues. Stance animations are bugged when: There is an undesirable intermediate stance when: There is undesirably fast camera movement in 3rd person: * By "moving slowly" is meant holding down (or having toggled) the key for the action in Infantry Movement called "Walk or run temporary" (or "Walk or run toggle").

What you just wrote na_palm is interesting and relevant to me. Can you, or maybe Haleks, explan to me in more detail what's OK and what isn't? :)

Unless you want base building because you actually want to build a base​ (in which case, why are you playing Ravage, or even Arma? :P), what you want in a base is safety, storage and respawn. Some alternatives to base building: Capturing camps. Capturable camps could both be placed manually and spawned procedurally in specific circumstances. A camp is kinda like an objective: If you clear it, the camp no longer spawns AI (and becomes persistent). If you are not in the area for days, chances are that the camp will be overtaken by other survivors. Camps have crates for storage and you can respawn there. Camps also provide safety by lockable doors: Lockable doors. I'm thinking that there should be a script (not necessarily tied to Ravage) which enables doors to be both locked with keys and picked with the right tools, and also, importantly, semi-randomly locks doors in towns. For Ravage, randomly locked doors adds an additional uncertainty factor when trying to take cover in buildings: They might be locked! As a substitute for base building, with the right tools you can change the lock on any door to one which you have a key for. These tools are of course rare (with the same intention that base building requires a lot of materials). I also think there should be a way to temporarily barricade doors (maybe requiring your character to stand still close to the door?). Garrison. If lockable doors are implemented well, any building could potentially become a hideout. To substitute for base building, what's missing is just placeable crates.

l like the idea of customizing the toughness of zombies. It could be combined with spawn size to create smaller groups of tougher zombies and bigger groups of easier zombies. This gets in the vicinity of some other ideas I'm currently fleshing out. To be continued :)

A vote for COOP. I've been fiddling with it myself, but progress is slow as I've never touched scripting in Arma before. I'm thinking the Altis demo mission, just add some more survivors to the group (i.e. more slots) and keep it just like it already is. Except: Each player is not spawned randomly at one of the spawn locations, but all at the same one (randomly chosen at mission start instead of player join). Also enable revive. As for respawning, there are some alternatives: 1) Put a respawn marker at the initial crash site. 2) Spawn a new wreck situation at another one of the spawn locations. Those are the obvious ones. But I have some more interesting ideas: I'm thinking of rolling these ideas into a standalone module. But I'd probably need help with that, hehe!

*deleted*