Jump to content

tinter

Member
  • Content Count

    564
  • Joined

  • Last visited

  • Medals

  • Medals

Posts posted by tinter


  1. It could also be possible for the ramp to open automatically once someone tries to enter or exit the aircraft. That would at least keep the functionality without having to confuse people with why they can't get in or out. As long as it doesn't close automatically afterwards, as that would lead to a silly loop of opening and closing once a lot of people get in or out.

    • Like 1

  2. I reckon most of the people who have a problem with non enterable buildings wouldn't have complained back in Arma 2 about maps like Chernarus which had closed off buildings. Just play the map for a bit and learn how to differentiate working from non-working doors.

    The problem is that there's no consistent way to tell working doors from non working doors.


  3.  

    The outcome is the same either way, you run to the door and try the handle OR check the action menu, the door is locked and you collapse on the stairs full-o holes, it doesn't make a slightest difference what is or isn't behind the door, you shall not pass.

     

     

    Except the problem is that the game doesn't communicate properly that the door isn't functional. Lack of action menu entry is not reliable and it's a bad way to go about it. There's lots of times where the action menu does have the capability to do what you want it to, but it's just being fumbly. So how do you know whether the door you're trying to open can or cannot be opened and it's not just the action menu being fumbly like it is sometimes? You could look at the windows, remember that the rooms in this particular building can't be entered or do whatever, but the problem is that there's no consistent way to be sure. The idea is that you shouldn't have to fumble with the action menu until you realize it can't be opened takes, at least personally, me out of the game and is a slight, but annoying waste of time.

     

    It might seem like a minor thing, but it's one of those details that impacts it negatively. Communication is important in keeping the game functional and immersive.

    If I can't open the door then the game shouldn't give me the signals that I can open the door, which it does by making them look like normal doors in most circumstances.

    • Like 8

  4. I can't tell just by looking at a door if it's locked or not in real life either, in my humble opinion you fellas are over analyzing this a bit.  :unsure:

     

    Arma isn't real life. In real life you can pull down on the handle and check it. In Arma, all you can do is open the action menu and wave your gun around to see if you can get the action and even then you're not entirely sure. It takes you out of the game.

    Not to mention, doors in real life are locked because they don't want people inside, while in arma they're locked because there is nothing behind it. In real life you might want to get inside anyway, while in Arma they should be disregarded by the player completely and you shouldn't have to fiddle with the action menu. They should either change the appearance, or make an action which makes a rattle sound like a real door would.

    • Like 2

  5. BIS has always had a certain visual shorthand for buildings: if you can see into a building, you can go into a building. Tanoa is the same. If the door you are approaching has windows you can't see through, then it's locked and unenterable.

     

    This is not true though.

    https://vgy.me/exhZJc.png

    There's three doors here, but only the one that leads outside is enterable. Of course it has some logic to it, in that no rooms are enterable, but it should feel natural. There's no clear indication that these doors are any different.

     

    For more examples, here's another pairs of doors that look alike but differ in functionality.

    https://vgy.me/8mILE7.png

    And these two.

    https://vgy.me/IHa6AA.png

    There's also the doors on the wall here.

    https://vgy.me/kAEF8k.png

    They actually removed the door handle on the door that can't be opened, but it's not really a clear indication as it's not consistent with all other doors.

    Again, I'm personally fine with buildings not being fully enterable, but I just want it to feel natural. As someone has said it's a problem when you walk to a door and the only indication it can't be opened is on the other side of the wall you're standing in front of. You're gonna waste time thinking the action menu is acting up.

    Bottom line, you should know, from any side, whether or not the door you're trying to open can actually be opened, without having to try to open it or look at the windows nearby, which aren't even always a clear indication, mostly when lacking windows.

    • Like 1

  6. I think the gameplay considerations are worth noting. Approaching a door that is locked is not only disappointing, but more noteworthy, it's confusing and it's not obvious which ways you can or cannot go through. The buildings should be designed so that they make sense even if they're only partly enterable.

    Also, I've mentioned this a few times, but I'm worried about it and have not heard from BIS, I hope they will make the rooftops compatible with AI, they cannot maneuver up there at the moment and it's a shame. The rooftop is more interesting for combat than the interiors., but they really need to be usable by the AI. I hope BIS will work on this.

    • Like 1

  7. I know people have been complaining about enterable buildings, but I think the added rooftop accessibility more than makes up for it. The real problem is that AI has no real way to access those rooftops. You'd have to manually place them on rooftops and then use a bunch of commands to lock them in place. It'd be nice if BIS could find a way to remedy this.

    Has anyone made a ticket for this or is it a feature request? I think someone said that the top of the building counts as building positions.


  8. I know people have been complaining about enterable buildings, but I think the added rooftop accessibility more than makes up for it. The real problem is that AI has no real way to access those rooftops. You'd have to manually place them on rooftops and then use a bunch of commands to lock them in place. It'd be nice if BIS could find a way to remedy this.


  9. Usually this is the case, but not always. There may be times where things are loaded into requiredAddons, in which case you'll need to remove them manually.

    There was also recently an update that changed the way profiles work, when this change was on dev branch it meant that it was not backwards compatible with the stable branch. However as far as I'm aware it has only happened once and it's also not an issue anymore.

    So in short, the worst thing likely to happen is that you need to remove some things from requiredAddons section in your mission.sqm, it's a good idea to not binarize your mission.sqm if you're on dev branch.

    • Like 1

  10. As a heads up, none of the new variants (any of the gunpod versions, or the cannon or HOT1) work on dedicated server as far as I can tell. The dedicated throws up a "No entry 'bin\config.bin/CfgVehicles.sfp_bo105_pah1'." for whichever version you put in and switches to the next mission in the list. The bench seat and the standard guided AT seem to work fine, although it shows all of the external weapon options at once (but they cannot be used) (http://i.imgur.com/MsXI2u6.jpg). Also, Not sure if the gunner on the HOT1 is bugged or what, but you cant look around and switching to the weapon sight view locks it into an over the shoulder perspective, like you are looking past the pilots in the front seat.

    Are you sure that the mod is running on the dedicated server?


  11. I'm not sure if I should release my own version, as it does seem to work for organized multiplayer, where you have a set modpack and you can ensure everyone has the part that sends the event handler info.

    Also, to save on performance, it would be wise to change the surface splatter monitoring from spawning lots of threads, to a single function that loops through the bloodsplatters.

     

    I've also discovered a bug with the bloodspray I managed to fix. If you shoot a magazine full auto into a person you'd get some sprays that don't exit their animation properly, leaving sprites that are just hanging in the air. I fixed it by only allowing one spray to be animated at a time, setting a variable to true if an animation is in progress so that any new attempts will quit until it's set to false.

    • Like 1

  12. Also may I suggest adding a BL_var_ prefix to your variables? It's a good idea to keep them unique to avoid some other mod accidentally conflicting. Should use bl_fnc_ for functions, although you can also just use the functions library and it will prefix is automatically. It's cleaner than defining in a script file.

    • Like 1

  13. Hey, I've been playing around with your mod, tweaking the blood and trying to make it multiplayer compatible. This wouldn't work for a public server setting, but the idea I'm using is to split the mod into two, one that initializes units and other that has the function to draw the blood. This gets around the whole locality issue with the hitpart event handler.

    Other than that I've tried creating a seperate rvmat for the surface textures so that they're lighter and making the textures slightly transparent (0.95 opacity).

    https://vgy.me/8YcFFB.png

    I think this adds a nice effect. Good luck with your mod.

    • Like 1

  14. Your textures look great! I'm sure you'll appreciate what I've done with v1.1 as far as texture handling goes ;)

    As far as the shading is concerned, there's nothing I can do on my end to change that, as that's how the UserTexture object in ArmA is shaded. It's outside my realm of knowledge (for now at least).

     

    Couldn't you theoretically create your own model that you apply the texture to? That should allow you to set the rvmat and have more control over the shading.

    Perhaps if you're using the standard arma object check out hiddenSelectionsMaterials.

    As a command: https://community.bistudio.com/wiki/setObjectMaterial


  15. I have some questions about view distance.

    First of all, I have my video settings set up as such:

    efyhga.png

    But it seems the client view distance is higher than what I have set in my video settings. I'm guessing this because I have my OVD and VD set to the same thing, but I still see terrain without any objects drawn on top of it. It seems to occur after getting out of a vehicle, so I guess it doesn't reset properly.

    The other thing I want to ask. Is there support for setting the terrain grid setting to 50 automatically when in air vehicles and setting it to the normal value once you leave? Note I'm saying only air vehicles because it's still obscuring to a degree for land vehicles.

    Just asking now before I actually go make a bug report and feature request.


  16. When the EDEN update hit, gear randomization was apparently disabled for missions created in EDEN. I need this on for my mission, but I haven't been able to get it back either by

    setting bis_enableRandomization to true,

    running the script manually from the pbo,

    running the function,

    using the description.ext parameter that controls randomization.

    I need a simple fix that can randomize the uniforms and headgear without having to get all the classnames myself.

×