Jump to content

TheVigil7

Member
  • Content Count

    10
  • Joined

  • Last visited

  • Medals

Community Reputation

4 Neutral

About TheVigil7

  • Rank
    Private
  1. TheVigil7

    Ravage

    Sorry- there's 375 pages of comments and this is my first day here at the Ravage forum thread. @Vandeanson- I had a similar problem with item duping when setting up my inidbi persistent save. I have resource spawners all over my map that you can spawn a selection of base objects at, then pick up and move them where ever (or even store them in vehicle cargo). My persistent save function only saves the objects specified for base building, all cars, and all object inventories, within a defined zone. The problems I haven't been able to resolve (that you are tackling) was allowing players to base build anywhere on the fly (not a pre-defined in the editor zone) and any player can pick up and move any base object; the addactions aren't owned by any specific player. RE: the Headless Client, I was able to connect some HC's to my Ravage mission last night, but I'm pretty sure this doesn't actually do anything because you need to tell the mission to spawn the ai on the HC instead of the dedi. If Ravage does not have functions to support this currently it won't work. There's a lot of ai/logic scripts tied to the ai that Ravage spawns so if we try to move the spawned ai to a HC after Ravage spawns them in... we lose all that ai logic and scripting. We need Ravage to spawn the ai on the HC and keep all the ai processing on that client.
  2. TheVigil7

    Ravage

    Oh hey all- Just a quick question that I haven't been able to find an answer to yet. Does Ravage support headless clients? If yes, how do I get the zombie and ambient ai's to spawn on the HC's? If no, this would be an incredible feature for mission performance :) (Thanks for an incredible mod Halek!) Vandeanson- really excited to try out the base building! I've implemented a version of base building in a Ravage scenario I created, but its really clunky/cumbersome and I can only save the bases persistently by defining save zones and having inidbi2 record objects in the zones. Meaning I have to know where players will build a base and define that in the editor, players can't 'build it live'.
  3. Hey- just wanted to follow up and say I haven't noticed bugs in this since the fix. Thanks code34! Awesome project.
  4. This seems to have resolved the duping, I'm still seeing weird output in the db, like a vehicle that was in the zone, and moved out of it is still listed in the db.. however on a server restart it wasn't loaded so the behavior seems correct. I also see it dupe one object, and only one object, sometimes. Not sure if its actually being duped or just more weird output I'm misreading. I'll just have to playtest and give you any bug further bug reports I may find. Thanks for the quick patch! You revived a really cool project I was working on, excited to get back to it.
  5. Thanks! Every other part of it works amazingly, setting filtered zones, filtering out specific objects... love inidbi2 and oo_pdw api. I am saving player data without issue, and outside this duping bug almost have a framework for saving world data ready. If I can figure it out this gives me a useful framework for a lot of future missions and ideas, great work man!
  6. Thats actually really close to what I had originally- I'll try that when I have the chance, but I think I still have the same root issue with that code, if there is one object in the 'including marker' zone, it gets recorded once, second iteration, it gets recorded twice, third iteration, recorded 3 times, etc.. all I want is to record everything in the zone, AT THAT SPECIFIC MOMENT, inidbi seems to write back whatever is CURRENTLY in the zone PLUS everything it had PREVIOUSLY recorded thus causing objects to be duplicated at every save.
  7. Here is my code snippet, I am running it from initserver.sqf - ignore all the parts about the counter, that code is running correctly and was just an attempt by me to try and differentiate between each autosave happening in the loop. If you let this code run for a bit, with a single truck in the specified zone that is being autosaved... every consecutive save creates a copy of the truck as I demonstrated in my OG post. There is still only one truck in that zone, in the same spot with the same inventory. This tells me that every object gets stuck in 'memory' somewhere in this script, I want it to forget ALL previous objects before it re-runs the autosave, so I only record every object still in the zone once. Everything about this code works except that it is duping all objects, first time it saves, it records the truck once, second save it records the same truck twice, third save the same truck 3 times... etc...
  8. hi Code34, Thanks for the reply. I added the counter because I am re-running the save command repeatedly, and was hoping by adding a counter I could pick an autosave out of the entire log. it was just an attempt to try and make this useful. However, even with the counter it is duping the same object over and over again. for troubleshooting my issue, ignore the counter its not important. To reproduce this is simple. Just set up a zone on a map that you want to save the objects in it. place a single object, like a truck. Then just have a loop run the save command every few seconds. The first time it runs, it will create an entry for the truck. The second time, it will create two entries for the truck, third time it makes 3... etc. If you attempt to order it to load the objects saved to the log this way, it spawns the same truck, in the same location, X many times based on how many copies were saved in the database, resulting in some truly spectacular physics glitches. I just cannot understand why it always creates a copy of the object unless inidbi itself is holding onto this variable somewhere. I cannot get it to clear all data its holding before writing new entries back.
  9. Hey guys- I posted this on the forum for oo_pdw since I'm using that framework, but I think my issue is actually in inidbi2 and I haven't gotten any answers on that board after a few days now. I have been working on persistence functions for my missions. I can save players info no problem but am having trouble creating save zones that record objects, vehicles and inventories within a marker. oo_pdw has functions for this and I can actually currently save everything in zones no issue, the problem is the next time I save them, I dupe the items. I've added a counter to the database key so it increments 1 every time, and I've got it set so that it writes to a new section every time, and yet its somehow keeping track of all previous entries. The example below shows how every time it auto saves it creates one additional copy of the vehicle even though every time I call 'save' it is writing to a new key and section in the DB. Does anyone know any commands in PDW, or INIDBI itself that can clear the old data out before writing back to log? Or has anyone had this issue before and found a work around? At this point my best guess at how to accomplish this is to just keep creating an entirely new database file EVERY time I call a save, the problem here though is that oo_pdw is hard coded to save the database name to 'oo_pdw' every time and I'm a bit of a novice and not 100% sure how script that off the top of my head, and I'm kind of hoping there's just a delete function in inidbi2 that I've missed.
  10. I have been working on persistence functions for my missions. I can save players info no problem but am having trouble creating save zones that record objects, vehicles and inventories within a marker. I can save everything in zones no issue, the problem is the next time I save them, I dupe the items. I've added a counter to the database key so it increments 1 every time, I've got it set so that it writes to a new section every time, and yet its somehow keeping track of all previous entries. The example below shows how every time it auto saves it creates one additional copy of the vehicle. Does anyone know any commands in PDW, or INIDBI itself that can clear the old data out before writing back to log? Or has anyone had this issue before and found a work around?
×