HorribleGoat

Would recommend .asc from L3DT. Its pretty much the same as .xyz but I've sometimes come across problems with xyz and Terrain Builder. Using .asc has never let me down.

Greetings! I've been refining the firegroup control system and it is rather close to testable condition! However I've seem to have finally ran into a engine obstacle that there is no way around! The firegroup system is supposed to become configurable, so you can select which weapons you fire from what button. That's all just scripting, but the issue arises if you would like to use MOUSE buttons for firing your groups!! I was hoping to have a simple left / right guns division for starters and fire them with left and right mouse button. Would be quite intuitive right? But this unfortunately does not seem to be possible as mouse button actions can not be blocked and re binded as keyboard keys can. With a really hacky-hack way introduced by Commy2 I was able to disable the left mouse and us it to trigger the firegroup script, but right mouse is out of my reach. Only way it could be used was if all other actions were unbound from it from options (scope, zoom, etc) which is not really an option. Now I've got a workaround solution for 2+ seated machines where gunner and pilot/driver are separate. The gunner can use Q,W,E,S,A,D for example for the special fire modes since those are not needed for him and with this we can progress for now. This however might cause problems binding intuitive firegroup triggers on single seated vehicles as mouse would be quite essential in easy handling. We will continue on finding a solution, but in the mean time we will have to do what Arma allows us to do. Hopefully I can post up some gameplay footage soon! :D

Could the mouse buttons have the same script access for disabling and rebinding as keyboard keys? Currently mouse button actions can not be disabled via the same methods keyboard keys can and they always perform their options bound action no matter what. Use cases: Disabling firing in certain situations re-binding different actions to mouse buttons in certain situatons

Any mods running that might have broken it?

Sounds a lot like a config problem. Do you run many mods? Would suggest turning them off one by one to see what causes it. And if it is your maps config then finding whats wrong in it.

Uuuh very cool! Keep at it!

Couple of new WK-209 shots. Here is the internal structure: Up armored concept:

I'll leave this here since I forgot how fast dropbox links go dead. Sorry wildcatbridge!

Is it a large object? Arma engine has troubles with objects bigger than 50m.

I've had so much fun doing this video and had to share the draft version of it for you guys! Making the internal structure and making sure there is room for all the components and parts that make the machine tick is really interesting and inspiring work. Theres still ton of details missing, and modeling like this is obviously a lot slower than just making the exterior model. But this will have so much benefits in the long run! Best part in my opinion is that I've managed to fix all kinds of minor flaws in the design with this process and I'm confident that I can avoid the same issues much better in the future now.

The water still continues around your map without the synth.

Welcome to the forums. I suspect its not config error since geometry collision is not defined there. These links may be of use: https://community.bistudio.com/wiki/LOD https://community.bistudio.com/wiki/LOD#Geometry Basically what you need is to set mass to the collision mesh and it has to be simple convex object/group of objects and it/they have to be named componentXX. I Suggest you use the Object builder for this and when you open up the geometry LOD in it use Structure -> Convexity -> Component Convex Hull. It will transform your geometry mesh/meshes in to convex objects and name them. Then you need to give them mass so the engine recognizes them as collideable geometry.

Did not mean to cause confusion just tried to clear things up, I have access to the latest VBS 3.8.1 through work and it is particle emitter, just double checked it from the configs just for you. It does have better interaction with water surfaces than Arma particles, but it still is particles. The water surface movement is its own thing, and looks great, ships physx on the other hand do not always handle high waves too well and there can be peculiar incidents. What I intended to convey is that while VBS sometimes seems to have better features than Arma. Its not magically better, I woulds say it concentrates on different aspects.

You can find the turret paths with this : https://community.bistudio.com/wiki/fullCrew

You really should read through the scripting commands if you want quick answers.. Anyways, here: https://community.bistudio.com/wiki/removeMagazinesTurret

Just that you know the water effects are just simple particle effects much like exhausts on cars in Arma. They float for a time on the water and dissappear. I think such particle emitter could be configured into Arma as well, but really no magical tech is involved. Also there is a dedicated thread for VBS discussion since its not affiliated with Arma..

If the turret is part of a vehicle and has a hidden AI gunner you can use: https://community.bistudio.com/wiki/remoteControl the gunner could be in separate cargo compartment that has no getin/getout actions so no one else can go in it and the AI could be created in it when you use the terminal to make sure it does not operate by itself. If the turret is attached to the vehicle by attachTo the same applies.

Does this happen without mods? If not then try every mod separately. Could be (and quite likely) that one of the mods conflict with updated vanilla moves.

You could select the whole terrain and raise it all up the amount you need to raise it above sea level and do your edits and select it all again and drop it down.

Just a tiny little upgrade on the walker design. This time slight adjustments to fit in full interior components and the works. Basically this means that Im modeling all the inner pieces that make the walker dance and adjust the overall design when something does not fit. Like with the ammo feed I needed to do little resizing with the shoulders and arms to fit it in and still have enough armor on them so they don't just fall off. This really is how we want our design process to be in general, so that the vehicles and machines we make can actually fit in the parts/weapons/gadgets they are built from. This also allows us to make cool props for our map. Like a Walker factory with partially completed vehicles dusting away and such. Also This makes good base for damage/hitbox design since we actually have all the stuff in there and can then place hitboxes and armor accordingly. The interior modeling is going to take some more time so Im going to piece together a working unit from the adjusted exterior mesh so that WK-209 does not miss the next release. :D

Did a trial with the 8192x8192 heightmap again today as to see if there was any chance of increasing our current map size (20480 x 20480 meters with 4096x4096 heightmap and 5 meter resolution) since in the current 20x20km the city has taken over so much of it. Now im not complaining.. :D Just saying maybe there could be more of the surrounding area shown and played too. The 4k heightmap could be used for bigger map with simply stretching the cell resolution but the city design would neet to be altered a lot since it relies on the 5m cell size. Now the best/only way to do this would be to increase the heigtmap size and the next size is the 8k which is known to be buggy. Buggy or not I did however manage to compile and run an empty 40x40km 8k heightmap 5m cell map and it was glorious! With this successful test test Im again torn to try to push the map into the 40x40 km (madness right) but I try to resist the temptation and finish the 20x20 to a playable condition and maybe then increase the size.

Can't stop! It already has a life of its own! Even fire does not stop it!! :D And yes inside. How else could you capture it if you don't go in it?

Another shot of the city concept model from different angle!

How about inside? ;D

Yeah it does not. The Dragon we released was just for show. :9 The real one we've planned on building from pieces so it does not clip out of sight so easily and for other usability factors.