Last active 5 years ago

  1. 5 years ago
    Sat Dec 17 15:57:56 2016

    @Imbazil here's the gist of what we're going to do for influence: https://github.com/SpaceHunnies/spacehunnies-test.Tanoa/issues/4#issuecomment-266898540

    We need to write a getDominantSide function (getDominantFaction works for us right now because there is only one faction per side, but that's gonna change), and turn the script into a CBA per-frame handler, but that's pretty much all there is to it.

    I'd like to add the influence display to the C2ISTAR intel menu, but that looks pretty complicated. The tablet isn't really designed for extensibility.

  2. Sat Dec 17 15:55:10 2016

    Nope: https://imgur.com/a/YMBUi

  3. Fri Dec 16 23:19:59 2016

    Nope: "There is currently no text in this page. You can search for this page title in other pages, or search the related logs, but you do not have permission to create this page."

  4. Fri Dec 16 22:12:34 2016

    Hm, it looks like I have a Wiki account but can't edit anything or create any pages.

    Here's an example of the type of documentation I would like to create: https://gist.github.com/nateberkopec/1996216ed16291202a19b966b9fc1315

  5. Wed Dec 14 23:12:12 2016

    There's a Slack channel? Where? Wiki/google not showing any results.

    I'm not looking for a dev to explain anything to me, really, because the code is actually well written and easy enough to follow. But I feel like I'm learning a lot by reading that would be useful to other scripters and I should document that knowledge publicly. It sounds like I should just start a wiki section for that.

  6. Wed Dec 14 15:41:58 2016
    N nateberkopec started the conversation Wiki section for scripting/extending ALiVE?.

    I'm working on a Antistasi-style scenario with ALiVE (players are guerillas), and we're going to be adding some systems on top of ALiVE for tracking player progress, etc.

    The documentation available for people looking to extend, build on top of, or otherwise use ALiVE outside of the editor is kind of sparse. For example, the core data types aren't explained anywhere (what's the difference between an objective, a cluster, and a sector? What data does each contain?), and the headers on the code itself aren't very verbose either.

    As an example, we're looking to add an "influence" system, where the mission keeps track of which side is dominant in each town (if the players are dominant in a majority of the towns on the map, they win). It took me a while to figure out that the best way to do this would be to access all the civillian clusters via `ALIVE_clustersCivSettlement`, narrow it down via a TAOR, and then use `fnc_getDominantFaction`. I was confused by whether or not I should be looking at objectives or sectors, but realized clusters were really what I wanted. Maybe this isn't even the best way!

    The only thing currently available on the wiki for people like me is Script Snippets .

    Where should this sort of documentation live? In the code itself, in function headers? Or can we get a new Wiki section that documents the internals of ALiVE?

  7. Wed Dec 14 15:34:44 2016
    N nateberkopec posted in VCom and ALiVE.

    I've only just started testing this, but it seems to me like VCOM works far better with ALiVE than ASR. ASR seems to override unit waypoints set by ALiVE (attack objective, defend objective, etc), neutering the OPCOM.

    I agree about hearing distance though. The default is completely inappropriate for ALiVE.

  8. Wed Dec 14 13:43:03 2016

    @SpyderBlack723 Link? Anyone post a RPT file? I'll bet that's an access violation crash, not an out-of-memory crash.

    In any case, 64-bit hit dev branch today which *will* fix the particular crash in this thread permanently (since virtual memory will no longer be limited to 4GB, which is what caused this crash). From what I heard ALiVE doesn't work with it yet, though.

  9. Sat Dec 10 14:58:59 2016

    Another thing, which may have a bigger effect on this crash - there's a Reddit thread right now that alleges that the maxVRAM parameter is broken and doesnt get set correctly.

    All of our RPT files run out of memory allocating textures in DirectX, which is sort of weird because I would think textures go straight to VRAM rather than ever living in system memory. Perhaps ARMA thinks it's out of video memory and is using system memory to compensate? I don't really know anything about video memory, I suspect it's all taken care of by the card driver.

    Anyway, people having this exact problem (running out of virtual memory during DirectX createTexture) may try setting maxVRAM in the ARMA launcher to the exact value of their video card.

  10. Sat Dec 10 14:12:19 2016

    New performance binary increases maxmem (maximum memory in physical RAM) from 2GB to 3GB.

    I don't think it will fix this crash (since we were running out of virtual address space), but might be worth a shot. In the worst case it should be an overall faster build :)

View more