Defunkt

I have just read, very good. Now might this be added to a server-side addon such that it is set by the server-op but without having to edit each mission?

I wonder if anybody has benchmarked the clipboard because given the next leg of the journey is over the net I'd have thought it was neither here nor there which method was used. Certainly I doubt it'd be worth falling foul of BattlEye though perhaps an exception could be negotiated there with $able. ---------- Post added at 09:39 PM ---------- Previous post was at 09:36 PM ---------- I meant to ask, any plans to have the plug-in auto-connect to the server specified host so that this might truly replace VON in a public server scenario?

It's an island, a blank canvas, it's up to you and other mission makers to set the story. ---------- Post added at 06:51 AM ---------- Previous post was at 06:32 AM ---------- That said, it's true, Russia is not known for its African colonialism and if there is a lot of Russian signage that'd be hard to work around without scripting its removal. Still think it's a bit strong to tar map-makers (including this one specifically) as 'lacking imagination', you can always make your own maps you know.

Good job we got back on topic. :biggrin:

Nothing I'm mulling here would be any help at all with camera views (i.e. a second picture-in-picture view centred on a separate point) FLIR etc included. I don't see that there's any way around rendering both views entirely and for this reason I imagine such views would continue to be full screen only. However with a 3D scope view you have two different FOV's sharing the same origin so there I'm wondering if it would be possible to construct a single frame which could serve both purposes and portions scaled up or down when written to an output buffer. The primary determinant for LOD is presumably distance but within a certain radius of the viewport center (i.e. that portion of the output that would be zoomed) the magnification could be be factored into that selection.

I don't follow, LOD is just a decision about which model detail level to render, the resulting frame can still be re-written at differing scales. It might be desirable to use a higher LOD than would ordinarily be applied at the widest FOV but it's not essential and still ought to be more efficient than rendering (and processing occlusion etc) two scenes. ---------- Post added at 07:28 PM ---------- Previous post was at 07:25 PM ---------- For that matter it seems feasible to me that it might weight the LOD selection based on whether the object will appear in the up-scaled image (i.e. it is within a certain radius of screen center).

Well, I suppose that would depend on what you want to achieve with render to texture but okay, congratulations on getting this far. ---------- Post added at 04:46 PM ---------- Previous post was at 03:12 PM ---------- Something else that occurs to me about one particular use of render-to-texture, specifically 3D weapon optics (some might say the Holy Grail of render-to-texture), is that they surely shouldn't actually require the scene to be rendered twice. Rather it should simply be rendered once at the widest FOV (ideally but not necessarily to a larger than normal resolution) and then a portion of that same scene is simply re-written to a 3D surface at a larger scale. TBH I feel a bit stupid that it's taken so long for this to dawn on me. As far as I can see, 3D scopes and vehicle instrumentation should be entirely possible.

I have no idea what you're on about there unless you're imagining camera views made from CutRsc graphics which is (I thought obviously) daft and not at all what I'm talking about.

Yes the GPS/map is a good example but for others you only need to look at what Mandoble achieves with CutRsc's. If BIS were to setup an instrument panel or a couple of MFD's on each crew interior addressable in this way modders could create all sorts of systems and the hokey default HUD could be ditched entirely in favour of 100% 3D instrumentation.

I think you misunderstand, I'm talking about the ability to send CutRsc graphics to a display associated with a 3D surface (i.e. the cockpit instrument panel). You won't get camera views but you could do a lot of instrumentation very simply and flexibly without having to create & animate polys in the model.

C'mon EricM, you must know that changing the 3D buffer resolution is nothing like re-calculating the scene (and occlusion and z-order and lighting and God only knows what else). You only have to compare frame rate when zoomed out and in to know that shit is what kills FPS. I'll say it again, the ability to plot 2D shapes and images to a 3D surface is half the result with virtually no cost.

Largely over my head but colour me impressed. Good luck!

Arrowhead is a stand alone game but what we think we know at this time suggests that it will also be able to use ArmA2 content if that game is installed. This means the true ArmA fans (i.e. the ones who're active on this board now and who run servers) will probably have both and I predict many/most servers will require players to have both also.

Super work, now all we need is to have the plug-in connect you to the gameserver specified TS host...

You know you really ought to find out something about an engine before launching into commentary on it. I fail to see why adding new content without first removing the outdated content is a desirable patching process but the fact is you could do so with RV (though again I've no idea why anyone would want to). The facility to have the content of one 'archive' supercede that of another is already fundamental to modding RV.

IMHO switching the camo layer from ACU to MC provides the perfect reason for Binkowski's units to co-exist alongside BI's (however much he might not be a fan of MC himself).

It has nothing to do with what people need to know to do it, it's about the fact that "re-purposing" and "installing" software is as you've just admitted a normal usage. What possible reason could there be to install software other than to alter what transpires between input and output and how can such a thing then be described as a 'Black Box'?

Thank you for that rather vague and meandering definition, I'm sure I should be much the wiser. Many things have inputs and outputs, the actual defining concept for a 'Black Box' is that one doesn't monkey with the internals which of course pretty much everybody routinely does with a PC (see re-purposing, re-programming, installing software above).

Every time you install a software package you are re-programming and re-purposing your computer. I frankly find it hard to imagine a more mutable or configurable piece of technology and if that alone isn't the antithesis of what a 'black box' is we're very obviously debating two utterly different concepts. One of us obviously misunderstands the accepted meaning of the term.

It may be that the people you know make similarly limited use of their car and their computer but it doesn't then follow that the purposes of both car and computer are similarly limited. Do people really imagine that an auto-download manager would actually make life significantly easier for new players at this moment in time? Unless it has some sort of differential patching built-in they'll be prompted to download around 1+GB of ACE mod about 3 times a week (assuming the server-op has bothered to maintain a redirect and doesn't just turn downloading off). And then unless BIS also add some sort of mod-specified in-game key-binding system they'll be stuck with each mod's default (hopefully not conflicting) key-bindings and settings. That said it won't matter because they won't have any idea what functions ACE actually has because, well, life is so simple now they don't need to find out anything at all about it. Just seems a little convenient to blame BIS, good things are sometimes complex and often require an investment.

Your logic is spurious, any black box can be altered given sufficient technical ability but it doesn't then follow that anything that is designed to be altered (i.e. a PC) is then (or should also be) a black box.

Rubbish, the entire point of a personal computer is that it can be programmed. The car and the gaming console are black boxes and you don't get the option to run either far out of their factory spec.

No, because cars fulfil a very finite purpose, the correct analogy would be car to gaming console. The general purpose personal computer is something quite different.

I have been following the thread and just worked my way back through it again, the last thing that was said on the matter two weeks ago cited (amongst other things) time pressure preventing testing of "advanced MP features"... ...so hardly concluded.

I'd also appreciate an update on that count. I read that it was mostly working in MP but haven't seen any detail on what is/isn't may/may not be functioning correctly if this is known yet.