TrEuDaT

Member

Last active 9 years ago

  1. 9 years ago
    Fri Nov 14 20:38:32 2014

    Quick start mission ran fine....other than the logs say something is an old version....

    Posted server rpt here....

    http://pastebin.com/credS1bZ

    About to try my mission again...

  2. Fri Nov 14 18:40:51 2014

    sure...ill try and get back with you....thx fellas.

  3. Fri Nov 14 14:56:43 2014

    Yo Yo Highhead! :)

    Thanks for taking the case. I will definitely do what I can for you guys up until 14 DEC. Not that you fellas care, but I discontinued my server which will be up until then. I decided that either I don't know what I'm doing (most likely the case) or things arent mature enough for someone like me to come in and make the mission I know that ALiVE will someday make possible.

    Like i said at the top of this thread, kudos to you guys for undoubtedly spending the hours & hours trying to make a product that old guys like me can use. I hope that in the end....you all make some money somehow because you deserve it. If it is just for the fun, I understand that too...I'd be right there with ya if I had a different life... :)

    Regarding the database issue, I have referenced this many times as I've built my missions(http://alivemod.com/wiki/index.php/ALiVE_Data ). I can tell you that I've changed BOTH...

    1. "name".pbo: line 677 shows the mission file that was executed..."Z6". I created that mission from scratch starting with Z1 and its had several iterations. I remember exactly when i removed those weapon (around Z3) crates which are showing up in the server rpt I initially sent. There are no crates in the mission now.

    2. "onloadname" in the description ext: Mission Z6's description.ext file is...

    onLoadName = The President's Girl;

    The server report shows on line 783...

    9:50:24 "Operation: The President's Girl"

    ...so that verifies onloadname executed correctly. Now look at line 817....

    9:50:33 k [20]: Operation v: Boobs

    This is an old mission name from last week (Z3ish version). This line along with the ammo boxes that are listed under sys_logistics tell me that persistence and the database are corrupt somehow.

    Don't rush for me fellas....but certainly let me know if I can help you. Maybe you flip some switch or something now that fixes it.....thus saving many man hours down the road after your product goes platinum. Again, let me know if i can help.

    Thanks.

  4. Thu Nov 13 16:28:45 2014
    TrEuDaT started the conversation I don't know how you fellas keep it up....

    ....because I'm fried. To you ALiVE team members, kudos to you. After struggling hour after hour in trying to get things working, I might just have to throw in the towel.

    Currently, I am unable to start a mission because it gets stuck on the load screen. However, if I remove any links to the War Room, my server starts up just fine.

    Here is a link to my server report in case you have the time to look at it....

    http://pastebin.com/Eqdq9eA8

    My notes after evaluating the report...

    1. Line 817: Operation v: Boobs. This is an old op name. I have change both my onloadname in my description.ext, as well as my *.pbo filename. I think the persistence is trying to load old information to my new mission.

    2. To simplify things, I removed all OPCOM modules and any logistics modules. I simply have MP, MPC, and CQB modules. I removed all factions and I'm simply using the base factions. Starting at line 955, ALiVE_SYS_LOGISTICS stuff starts to report on ammo boxes that don't exist. Maybe in Operation Boobs they did, but in my current mission, I deleted the ammo boxes that are being reported lines 955-973. Again, I think the database is trying to upload old mission data into my new mission. Hell, maybe all of the information in this report is old....not sure.

    3. Then the error fest begins at Line 1441.

    Note: In trying to figure all of this out, I did download a new zip file for @AliveServer and I put it on my server. I did so because I thought I saw updated files based on file modification dates. I don't see how this would have screwed anything up though.

    Any ideas?

    And again...thanks for your time. I know you don't have to do this so I do appreciate you helping me now and on previous occassions.

  5. Wed Nov 5 03:26:42 2014

    the classnams for the RHS apaches are...

    rhs_ah64d_wd
    rhs_ah64d

    Get more info here or go into your editor and look into your configs. You can find classnames in there.

    http://doc.rhsmods.org/index.php/RHS:USAF

  6. Wed Nov 5 03:17:31 2014

    I think it also depends on what you have going on with the rest of your BLUFOR and OPCOM. If your OPCOM is using your logistics pool to feed its efforts, then it might take time for you to get your request. Try uping the logistics pool to see if that helps. Otherwise, I have no idea why its taking that long. When I hvae mine working, I'll see progress is being made on my request every 3-4 minutes....

    Good luck bud.

  7. Tue Nov 4 03:19:10 2014

    negative, although i've read and experienced myself longer wait times. When things are setup correctly, your wait times should be minimal. the status on your tablet should almost immediately show either request received or request acknowledged...i dont remember. If you see that, you know things are working correctly. If you just see "request sent" with nothing following for a long period of time, i would be something is broken...

    Now after 10 to 20 minutes...do you get the supplies you requested? If so, its working. You may just have issues with your insertion points.

    Note that if you put down a logistics module that is set to "Static", the insertion point for your resupply will be based on the actual location of your logistics module. If the objective near your logistics module is not under your control, OPCOM won't be able to resupply you. If you have it set to "Dynamic", the location of the module isn't supposed to matter. Your insertion points will be based on the highest priority objectives that you are controlling.

  8. Mon Nov 3 21:58:58 2014
    TrEuDaT started the conversation Possible MCQB bug....

    An observation, which I hope is helpful...

    I think there may be a bug with the Military CQB module....specifically, the "density" dropdown setting. For any setting other than off, I get CQB placements outside the taor marker that I've pointed it to. I've synced through a MP module (CQB>MP>taor makrer).

    For low/medium/etc densities, I'll get faction spawns outside the TAOR....even inside a defined "noCQB" marker using the blacklist lines. Another weird thing is that the spawns will come in as OPF_F faction only even when I've defined other factions in all other EAST side modules.

    I'm not exactly sure what the density setting is supposed to do, but I'm guessing it spawns additional CQB points outside a cluster....and right now, it does so regardless of the marker borders and it only spawns OPF_F factions.

    let me know if I can do anything or provide something that is helpful. You can try to duplicate it on your insurgency mission. It has one large OPFOR marker and one small blufor marker. Setup your blacklists so the noCQB marker isn't supposed to spawn any opfor. Then tweak your density settings on the MCQB module and you should see OPF_F spawns inside the noCQB marker.

  9. Mon Nov 3 21:44:44 2014

    yes it does highhead, thank you for taking the time.

  10. Sat Nov 1 19:42:24 2014

    BUMP

View more