T

thebgpikester

Member

Last active 4 years ago

  1. 8 years ago
    Fri May 6 08:34:21 2016
    T thebgpikester posted in 1.0.5 Released!.

    Yes! been waiting for this, thank you ALiVE team! :)

  2. Sun May 1 13:18:31 2016
    T thebgpikester posted in I think I've misunderstood persistence.

    Yes. The scenario I'm trying to solve is a persistent server thats up 24/7 that people can JIP, leave sitreps down, move mortars and battlefield components and otherwise play then come back to it later and the efforts they made still exist on map. The problem is that not all these people woudl eithe rremeber or be admin capable of saving server state and we may have server restarts in between. The current design appears to be (although persistent is a word used) based on a single game session that the same group come back to in an organised fashion. I'm looking for an option that bridges that gap, like say the exile/epoch/wasteland style 24/7 servers use.

    The challenge to this is that you need to find a way of saving automatically before a scheduled restart of the server, both in game and from outside if you restart the physical box. The current methods needs an attended save, so I understand. It seems it can cope with reducing the AI to not continue working, via one of the options in the ALiVE (required) module (disable AI) so it looks like it's been considered, in part.

    The other challenge is the CPU process as it iterates through all the objects. It's not something we want to happen often, but the only way to autosave is to launch that method on a customisable timer so that in the event of the server crashing or the physical box restarting unexpectedly, the servers comes up with say a 5 minute old snapshot.

    I'm not sure this fits with your lightweight "virtual AI" system which was designed to be saved to the cloud. But there are local DB's intwined with the current technology. The war room can still have its place as a stat machine, but IMHO the horsepower needs to be in a local DB for the persistence.

    Why?

    The modern gaming userbase has drifted from the old massive groups of loyal players. People now play multiple games, they get bored easily, they have modern pressures and cannot stick to kickoff times. People have shift work, can't stick to single evenings and even the younger folk complain of lack of time like the adults with young children do, and thus gaming groups are smaller, more dynamic, fragmented, struggling (feel free to disagree if you can remember ten years back). JIP, the term i only heard coined in Arma, suits many more people now and having a server you can jump on to, but pick back up a few days later and still be in the same session is a killer. It's effectively MMORPG style. Something that ALiVE can do that the base game struggles with is your Virtual AI system. It's genius and solves so many scaling problems (it's not new however, I'm thinking back to Falcon 4 who did this). With Virtual AI we can have game types like Capture the Island, but what we can't do is capture the island in one session. So whist solving the scaling issue, ALiVE went right up to the solution of persistence, danced with it and then dropped the ball, in my opinion.

    By adding "multisession JIP persistence" you make Arma capable of large scale warfare, logistics and can play the same session at any time over the months of the campaign, with some or all of your teams without ever having to worry about someone having to press a button to save progress. Seems such a simple thing but its has got a far reaching consequence for Server admins and game designers that allows ALiVE to be a must have mod.

    TLDR; AUtosave server state, autosave player state, autosave prior to mission shutdown and finally a commandline from OUTSIDE the mission that can call these functions prior to a shutdown or restart such a sa typical admin would have for rebooting so that the misison can be persistent without player intervention.

    I think these items would greatly improve the uptake of the mod.

  3. Sat Apr 30 18:55:32 2016
    T thebgpikester posted in I think I've misunderstood persistence.

    And the server state (which wwas the thrust of the post). Other mods can do this and allow reboot cycles.

  4. Sat Apr 30 18:53:35 2016
    T thebgpikester posted in Server will not save.

    same, already reported

  5. Fri Apr 29 23:19:21 2016
    T thebgpikester started the conversation I think I've misunderstood persistence.

    From what I've been reading, it appears someone actually has to save the server state to save objects. Then save himself before leaving. A little like closing the door on the way out. Is there any way to call this function when the last player leaves in a "persistent = 1" config, and same for the player details when a player leaves? ALiVE clearly thought about closing down AI processing when players leave and stopped short in the design there...

    Perhaps i'm asking of too much of the engine, but I don't see why when we can call the save in game, that that the save shouldnt be automated to save the session in the event of a restart and at last player leaving.

    The reason I ask is because to have a fully automated dedicated server you need to manage its reboot. Mine goes off and autolaunches the game and mission right back (actually I suspend it in the early hours but thats another story). So if I reboot a server, the game is forcibly closed down and no save ever took place. AFAIK there is no way of accessing the dedi console to run an execVM to call anything like a save...

    My vision is a 100% JIP, autosaving, auto-restarting server I can leave running without checking it, running a massive campaign, hopefully based on the Alive engine for efficiency. I cannot currently achieve that by having to log in as admin at the end of the evening just to save the game, seems ridiculous.

    With local database as a solution I can save player and unit from code on multiplayer events or on a timer, but I have no ALiVE which uses virtual AI anyway, so the solution taunts me.

    Surely someone must have come here looking for the same Nirvana?

  6. Fri Apr 29 15:18:22 2016
    T thebgpikester posted in Manual Server save hangs.

    I'm looking at a rollback too but I'm not sure its going to work, sounds like there were some under-the-bonnet changes.

    I think I'm going to start examining iniDB for persistence, this has never worked for our group and 20 folk are waiting on a promise I made based off this mod.

    I'd rather this was fixed though as on paper it had the solution.

  7. Fri Apr 29 08:02:16 2016
    T thebgpikester posted in Manual Server save hangs.

    rgr that. FWIW the server always rolls back to a single save made prior to 1.58 and the player pos/gear too, but player pos will update throughout the server session and save, but on the restart takes us back to the one last week. It's a damn shame I can't launch, I'd like to know if anyone has this working at all, there are so many configurations that can potentially interfere.

  8. Thu Apr 28 17:33:04 2016
    T thebgpikester posted in Manual Server save hangs.

    So, any thoughts?

  9. Wed Apr 27 20:23:35 2016
    T thebgpikester posted in Manual Server save hangs.

    RPT: https://drive.google.com/open?id=0BwUQri1lYjQ8TEdKWmpTTy16NkE
    PLUGIN https://drive.google.com/open?id=0BwUQri1lYjQ8NG1iTm9ISzMyMHM

    • Pastebin free doesnt accept more than 512KB pastes
    • Assume you meant the @aliveserver (plugin) logs, I searched the entire drive for an Alive.log and got no results despite ALiVE running.
    • I left it over 20 minutes whilst I did the logs and it remained as per screenshot.

    Bit worried about this alive.log....

  10. Wed Apr 27 19:50:13 2016

    Persistent=1 is better for the launch slowness I found, if you join a server then ask it to load a mission it creates as you join and thus you get this whopping wait where it feels like it hangs. If you have a persistent server it will load then you can JIP and it will be a lot faster. I need to test to see if the pause from ALiVE reduces my CPU when no one is joined a lot more. Not sure if it works that way.

View more