Bluedrake42

Registered
  • Content Count

    674
  • Joined

  • Last visited

  • Days Won

    161

Everything posted by Bluedrake42

  1. Keep in mind they already do... nodes are simply expansions of the FOBs you deploy. You can deploy FOBs anywhere. So if you would like to have a helicopter pad somewhere different, than simply build another FOB and place it where you would like the helicopter pad to be.
  2. All the games you get you get for good, if you choose to continue being subscribed to get games in the future or just continue supporting our work then that is up to you. Re-subscriptions are automatic unless you decide to cancel, which you are able to do at any time.
  3. That's actually an excellent question, and one I forgot to answer in the development blog! Currently we have a system that removes (or hides) all organic objects from your deployment area when a F.A.R.P. is placed down. So for instance, if you deploy in the middle of a forest... the trees around you are cleared away. This makes it both harder to hide FOB's in forests, but also gives you greater choice in where to place your forward bases. However we don't have it set to clear buildings, and there is a decent amount of clearance required for each forward outpost! So you will likely not be able to build in the center of cities =P but definitely on the outside! However we thing that is a pretty decent compromise both for gameplay and balance =)
  4. Welcome to Project Reality: ArmA III's newest development blog! Project Reality: ArmA III ► Base Building & Forward Outposts In previous versions of both Project Reality & Project Reality: ArmA III... bases have been static, with fixed positions, and fixed assets. This means starting from the same bases, assaulting the same positions, with the same assets... every time. Boring. We intend to change this... by developing an entirely new asymmetrical, dynamic, and player driven form of base construction... that deeply impacts the entire enduring engagement of each missions, based on each team's early-game decisions. If you wish to follow the project, try to stay active in our primary development channels. Introducing Forward Arming & Refueling Points ArmA is a big game... and big games deserve big features. We've been working to redefine how forward outposts function in ArmA to compensate for the gigantic terrains and asymmetrical environments players encounter. Our solution... the Forward Arming & Refueling Point... your new universal deployment point for Project Reality: ArmA III operations. A deployed and fully upgraded F.A.R.P. Forward Arming & Resupply Points allow teams (with combined effort) to fully define the forces available to them, while supporting your entire team on the front-lines. These constructible forward bases not only allow a team to fully support vehicles on the battlefield... but also serve as deployment positions for team assets... including tanks, helicopters, light vehicles, and more. Varying stages of F.A.R.P. deployment F.A.R.P. bases are deployed from deployment vehicles (available at other upgraded forward bases.) Each forward outpost has expansion points (or nodes) that can be used to expand each base's functionality over time. These nodes can be upgraded to serve as vehicle respawn points, offer repair/refuel/rearm services, expand base defenses... and more. A player deploying a F.A.R.P. node into a helicopter deployment pad These nodes are permanent when deployed, or until F.A.R.P. is destroyed by enemy forces. Each node only serves a singular purpose, and only serve as respawn points for the vehicles it deploys... vehicles are not purchased in Project Reality. If the vehicle dies, it will respawn at the F.A.R.P. node it was deployed from after a fixed respawn delay. With this system, each team can ultimately create proper forward operating bases, that supply and maintain entire motor pools for a team. A variety of deploy-able nodes available at constructed F.A.R.P.s These permanent nodes change the entire combat environment for each operation, with each team able to decide what assets THEY need for the given operation. This system should create exponentially greater variety in team engagements, allowing each side to adapt to any given situation... as long as resources and deployment times allow. Base Construction Mechanics For the curious, here is an in-depth outline of the current F.A.R.P. deployment process. Please keep in mind that all these details are subject to change, our system is still a work-in-progress, and we are preparing to change our designs based on player feedback from future scheduled playtests. A simple mock-up of a deployment vehicle deploying a new F.A.R.P. To deploy a new forward outpost, a deployment vehicle must spawn at an established F.A.R.P. and travel outside of the outpost's construction radius to establish a new starting base. These deployment vehicles are spawned from "Deployment Vehicle" deployment nodes that can be built at established bases. If no deployment vehicles are available at forward bases, a permanent deployment vehicle node will always be available at each respective team's starting base. A simple dissection of forward outpost nodes and hubs When deployed... each F.A.R.P. has only five expandable nodes. These nodes cannot be sold or undeployed... and are permanent when upgraded, unless the F.A.R.P. is destroyed by enemy forces. Players will need to build multiple forward bases to have a variety of assets, supplies, and deployment points to engage from. Stages of forward outpost construction and expansion As the forward outpost naturally expands, the central structure also automatically expands with it. When newly deployed, a forward outpost only exists as a single deployable cargo outpost. However when the forward outpost successfully constructs three fully developed nodes, the central structure automatically upgrades to a tier II cargo headquarters. Lastly when the forward outpost successfully constructs five fully developed nodes, the central structure fully upgrades to a tier III cargo tower. Showcase of possible expansion node combinations for different deployed F.A.R.P.s Nodes are deployed using credits generated over time by deployed forward outposts. Each F.A.R.P. generates its own resources over time, which can be used to deploy nodes, deploy ammunition supplies, repair supplies, infantry equipment, weapons, and more. There is no other way to generate resources for a forward outpost, so defending long-standing forward bases is important to long-term mission strategy. Additionally resources spent on expensive expansions (such as close air support, main battle tanks, and more) may have serious consequences compared to purchasing cheap early-game expansions (such as light vehicles, transport helicopters, and beyond.) All forward outpost hubs offer supplies and logistical assets depending on their tier Powered by R3F Logistics Finally, all forward outpost hubs can supply infantry squads with supplies, ammunition, logistical assets, and even armed emplacements in exchange for generated resources. Each advancing tier of a deployed forward base unlocks more powerful equipment and supplies available to infantry squads. Tier I forward outposts only offer basic fortifications and logistic equipment, such as sandbags, crates, and barbed wire. Tier II forward outposts offer more useful supplies, such as ammunition and medical supplies... greatly decreasing the amount of supplies needed to be flown into the area, and turning a tier II forward outpost into a local resupply hub. Tier III forward outposts offer advanced equipment, such as anti-tank emplacements, thermal sighted turrets, anti-aircraft launchers, anti-tank mines, and mortars. New Development Repository Unfortunately we have recently experienced a serious security risk when using Github while working with previous developers of Project Reality: ArmA III. We witnessed a highly damaging abuse of repository administration permissions, that allow contributing developers to delete, transfer, or otherwise deface parts of our repository without authorization. Unfortunately while using Github, this issue is virtually unavoidable when working with large teams. It is a problem similar to giving twenty of your friends the password to your Facebook account, and waiting to see which friend ultimately presses the "delete account" button... even when nineteen don't. This incident caused serious setbacks for our development progress, and we have since spent considerable time finding and building preventative measures before continuing development on Project Reality: ArmA III. In response to this, we are proud to finally reveal our new code repository at https://gitlab.bluedrake42.com/ Our new self-hosted development website, powered by Gitlab With this new platform, we'll have greater control over our intellectual property, and have greater chance at thwarting improper usage of repository permissions, as well as having more direct recovery alternatives in the event of catastrophic events. Currently the server runs Gitlab Community Edition on our own web-server in Utah, is backed up by Amazon Glacier services, and provided support for by Liquid Web management services (all services I recommend very highly, and who help me considerably keeping this community alive.) We're hoping that now with a new platform to build our products on, as well as new confidence in our web security (although we are always learning and improving <3) now is the best time to continue developing Project Reality: ArmA III! Release Date As always... we always strictly adopt a "when it is done" development mentality. In fact we go beyond that... since this is a community developed modification, we have also strictly adopted a "you can help us get this done faster" mentality. This means if you see an issue, or a feature you want, you can be the person to fix it, create it, or donate it. We only will finish this project as fast as the community comes together to help us. If you are interested in contributing,make sure you join the project forums and Discord server. Additionally if you are interested in supporting our server, and ongoing development, make sure you VISIT OUR STORE to consider becoming a supporter. Additionally if you want to follow development directly, or possibly apply to become a developer for Project Reality: ArmA III please consider REGISTERING ON OUR NEW DEVELOPMENT REPOSITORY! Otherwise, thank you so much to everyone for your patience over the past few months, and we're excited to show you some of the incredible things we've been working on! We hope you are just as excited about the future of Project Reality: ArmA III as we are ❤️ Cheers! See you soon! - The Project Reality: ArmA III Team
  5. We're actually debating on making the entire source code open here soon, we were going to make a modding API but I think we underestimated how retarded we are. As usual. Keep an eye out for the next few weeks.
  6. Bluedrake42

    Update?

    Yeah actually, we're debating on just going full open source. It might cause issues with hackers and piracy... but if we can include the community more directly into the development of the game we're thinking it might be worth it. I'll definitely let everyone know what we decide here soon. I'm going to give it a little longer to see if we can get through it.
  7. Bluedrake42

    Update?

    We're having some trouble with a ship data refactor that was meant to add multi-blocks (aka 2x2, 2x4, etc block sizes) which has ended up being a major speedbump to the progress we were making. We are getting further with it now, but I'm not going to lie its been a major pain to work through. I will try and tell you more when we are further along, I'm sorry for the delay =/ this is why I always try to emphasize that I can't guarantee when things will be done. I will let you know more as soon as we feel more confident with our progress.
  8. Bluedrake42

    Edo's art

    ye. stroke that flashlight. stroke it good.
  9. Dude holy shit wat, this is fucking amazing
  10. Welcome everyone to the Iron Armada February roadmap update! Iron Armada Pre-Alpha v0.1.3 Welcome to Iron Armada's first proper development blog! In this article we'll cover what we have already accomplished, what has been released to the public, and what we are next looking to complete! Iron Armada is a completely original game, written from scratch in Java by our community developers. If you want to be more involved with project development, make sure you follow the development channels below! If you wish to follow the project, try to stay active in our primary development channels. Successful Greenlight Campaign Iron Armada is going to be on Steam! After a successful Greenlight campaign, we have already begun the process of registering our application on Steamworks, as well as adapting our current game-build to function with Steam's infrastructure. Thank you so much to everyone who helped us make our campaign a successful one, and we'll hopefully have Steam keys available for our active supporters here soon! Our official Greenlight trailer Current Features & Functions The current version of Iron Armada includes our core features, that serve as the foundation of the game, and will be constantly improved over the lifetime of the game. These features currently include full multiplayer gameplay, with multi-crew ships, large fleet faction battles, ship-to-ship boarding, resource mining, and ship construction. Current game features. Upcoming Features & Updates The current features of Iron Armada only scratch the surface of the game's gameplay potential. Over the coming months, we are expecting to begin releasing some of our more advanced features... that we feel will begin completely transforming the game. New features such as ship exteriors, multi-blocks, advanced power systems, new construction methods, rebalanced infantry combat, overhauled weapon effects, overhauled damage effects, and more... will likely turn Iron Armada into an unrecognizable experience. To illustrate some of these upcoming changes, we have prepared the following documents explaining future features. Following development blogs will delve into deeper specifics for each upcoming feature, as well as game re-balance, as development progresses. We're excited to talk in detail about each specific feature seen above, such as ship customization, new infantry equipment, new weapon types, new engine variants, and more. So make sure you FOLLOW FUTURE DEVELOPMENT BLOGS released on our forums! Release Date Iron Armada has a strict "when it is done" development mentality. However, we have already released the public pre-alpha testing build... so hopefully that will keep you entertained until the official Steam release! We are currently working with Steam to adapt the current game to their distribution systems, and we're hoping to have our first Steam keys available to active supporters in the coming month. However for today, that is everything to update you with! Thanks so much for your support everyone, and we all look forward to seeing you on the Iron Armada testing servers! If you have any questions about the project, be sure to visit the forums and Discord! See you soon! - The Iron Armada Team
  11. Welcome everyone to the Harsh Doorstop February roadmap update! Harsh Doorstop Pre-Alpha v0.01 Welcome to Harsh Doorstop's first development update, showcasing what we've accomplished, and what we're next looking to complete. Harsh Doorstop is an open source, and free development project... meaning we intend to cut costs, and incorporate affordable third-party material whenever possible. Our goal is to create an enjoyable, modifiable, multiplayer, team-work oriented platform for our community... developed affordably, and available for free. A strong reliance on third-party content makes this possible. Our core development team consists primarily of programmers and gameplay designers, orchestrating assets either purchased, developed in-house, or donated to the project. If you wish to contribute to the project, try to stay active in our primary development channels. Pre-Alpha v0.01 Video Showcase Enjoy the first video showcasing in-game footage of our initial framework. This framework showcases fundamental systems functioning in a multiplayer environment, including multi-passenger networked vehicles, true first person mechanics, large-scale detailed terrain, and elemental match management systems (round reset, factions, scoreboard, and match time.) Initial Features & Functions The first versions of Harsh Doorstop focus primarily on building fundamental systems needed to support a full game. Things such as multiplayer support, networked vehicles, true first-person perspectives, and basic infantry weapons. These systems are going to be continuously improved and polished throughout the lifespan of the project, and lay the groundwork for more advanced features in the future. Our current priorities revolve primarily around polishing vehicle integration (including network smoothing, physics balancing, and player interaction detailing) implementing new player animations (being custom developed by mistwalker) and balancing for realistic gameplay (which will better showcase our framework's potential for tactical gameplay.) Upcoming Features & Updates Subsequent versions of Harsh Doorstop will focus primarily on implementing wider variety of content, as well as establishing a pipeline for importing regular third-party content, and building an intuitive user interface for more seamless clientside game management (right now you launch the game and connect to servers through .bat files.) Importing third-party content. Building a reliable pipeline to regularly import third-party content will have major impacts on content release frequency. Unlike other commercial titles, Harsh Doorstop is openly embracing the idea of utilizing community developed content already available for Unreal Engine 4 on the open market. Using this to our advantage will allow us to implement large quantities of content at a fraction of the cost, in a fraction of the time, keeping our project free to the public, but still content rich. Upcoming Content These assets are not free without a studio license (the above assets are created and licensed by Hum3D studio) so we will need to purchase (and fully convert, animate, and import) each asset for use in Harsh Doorstop. Each asset (depending on complexity) costs anywhere between 300$ and 1000$ after completion. To cover these expenses, we will be running small community fundraisers as we continue development of the game. With consistent funding, more assets can be purchased, imported into the engine, and released in Harsh Doorstop... allowing for constant new content available to the community (as long as our budget allows for it.) For those still skeptical on the feasibility of importing third-party assets into an existing Unreal Engine 4 game, here is an example of an identical model (purchased from Hum3D) imported into a playable build of Unreal Engine 4 by our team. We converted this into this User Interface Overhaul The current version of Harsh Doorstop has only a placeholder (or otherwise entirely absent) user interface for player interaction. However our developer @Ethik has been building an entirely overhauled menu, interface, and heads-up-display for Harsh Doorstop. This will completey rebase our game's accessibility, and player experience. The new menu systems should allow all players to easily navigate through dedicated hosted servers, manage video settings, as well as communicate with other players, and manage in-game inventory items. Here is the prototype radial menu working in-game Release Date Unlike other commercial titles... Harsh Doorstop has strictly adopted a "when it is done" development mentality. In fact we go beyond that... since this is a community developed game, we have also strictly adopted a "you can help us get this done faster" mentality. This means if you see an issue, or a feature you want, you can be the person to fix it, create it, or donate it. We only will finish this project as fast as the community comes together to help us. If you are interested in contributing, please ensure you INTRODUCE YOURSELF on our official Harsh Doorstop project forums. List your skills, your region, your experience, anything at all that could be useful to helping us finish our project. If you have no skills developing in Unreal Engine 4, you can still help us by FINDING US TALENTED DEVELOPERS TO RECRUIT or HELPING US PURCHASE UPCOMING ASSETS. However for today, that is everything to update you with! Thanks so much for your support everyone, and we all look forward to seeing you on the Harsh Doorstop battlefield! If you have any questions about the project, be sure to visit the forums and Discord! See you soon! - The Harsh Doorstop Team
  12. So this is the part where you work for us right?
  13. Holy shit dude did you fucking make that that's fucking sick, is that all original work?
  14. Hey Rampage <3 I'm interested in processing this application. How much experience do you have with Github? Hopefully you can also help us keep our repo organized <3
  15. Long story short, yes. @SRDDonkey can tell you more if he gets on.
  16. I will fucking stab u cubba I swear to god
  17. Here is the first draft GDD for Iron Armada's first release. This is a focus on baseline competitive gameplay, for the initial version of the game. Complex features, for instance player inventory, and open world... would come after this release. Firing Systems: Marine weapons: always fire over "floor" blocks (no exceptions) Ship weapons: can fire over "floor" blocks, but also can target "floor" blocks (only if cursor is over block) Build Systems: Thrusters, turrets, airlocks all have "no build" 1xinfinity zone extending past barrel/exhaust ports (example) Lines only show up when attempting to build in "no build" zone, and only extend from attempted build to "no build" source (example) Four building block categories: Hull, Engines, Weapons, Power. Pressing each respective number will cycle through block types. (example) Each block upon placement is "unbuilt" and requires to be welded to completion to be fully built. (example) "Unbuilt" blocks can't be built upon until fully built. As crewman left click welds/repairs or places selected block, right click grinds/destroys or deselects selected block. Blocks must be reselected after each placement. Player can continue holding left click after placing a block to immediately begin welding it after placement. Repairs cost resources Multi-block blocks must be built one block at a time after placement to become functional. (example) Multi-blocks can also be destroyed one block at a time. Unlike single blocks, multi-block segments can be repaired until the entire multi-block grid has been destroyed. Auto-merge block placement system, that prevents awkward designs... and automates most exterior hull angles (example) Airlocks allow friendly players to go inside/outside ships, but act as normal wall blocks to enemy players. (example) Weapon Systems: Single-block turrets are pilot controlled. Fixed-block turrets are pilot controlled. Multi-block turrets are controlled manually. Weapon systems only fire if player left clicks in weapon respective firing cone area. (example) Weapon classes can be enabled/disabled per player position while piloting. (example) Weapons have restricted firing cones depending on their surrounding blocks. Heavy turrets have turret destroyed first before hull begins taking damage. Gameplay Balance: Only one cockpit allowed per craft, cockpits however can have multiple sizes allowing multiple positions. 15 second respawn delay for players. Equip-able Classes: Crewmen (Default Class) Half health Full speed Can repair Can build Can grind/salvage Can pilot/gun No weapon No jetpack (slow space movement) Looses health while moving in space Marine (Equip-able at Medical Bay) Full health/armor 2/3 speed Cannot pilot/gun Assault rifle (3 round burst) Jetpack Can survive in space Miscellaneous Fixes: Marines with assault rifles cannot "aim" while rifle is clipping through any wall block. When clipped, stance is forced to holstered.
  18. We're very aware of ACRE and TFR, unfortunately though unless Teamspeak begins allowing redistribution... we won't be able to package the system with the modification.
  19. We can always delete them for you, link me the post and I'll take care of it when I'm back home.
  20. The project is called Harsh Doorstop and is literally linked on the front page.
  21. Evan it isn't discontinued per say. We still host the server for the download client, we wouldn't be hosting that if we didn't intend to revitalize the project at some point. Currently we just have too many things to finish up first (one of which was finishing this forum) before we can begin supporting BF1942 again. However I have no reason to not do that again. If anyone ever wants to start hosting for it themselves, we still have all the required files to allow that. Including the Mumble configurations.