gammadust

try _unit joinSilent grpNull i don't think you can otherwise from the command menu.

Very glad you made it :) But let me add this, you may find some optimizations:

glad that you shared the challenge too :) (btw ignore the comment in regards to the curve being an ellipse, on second tought i should be wrong)

Well it can be simplified to a trigonometric question if the triangle we have at hand is square. If it is not we must decompose it into square triangles and proceed from there. As it looks in the sketch (assuming i represented faithfully your given constrictions - 2xspeed, reaching the point simultaneously,...) the resulting triangle is irregular for all situations but the one in which the player is on 90 degree course (not represented) in relation to initial line of sight with the parting AI. Not all is lost because we can still decompose it into square triangles (black vertical lines). If one finds the function which describes the line(curve) passing in all the P1, P2, for any arbitrary angle one needs only to find the intersection with that curve. If i am not mistaken (i am surprised at the result too) that curve passing in the Ps is a perfect ellipse (one would still need to find it's parameters -excentricity or small and big diameter). i am wrong. The special case of 90 degrees is curious:

Let me try and reformulate for the sake of chalenge. Basicaly you have a speed that can give at any point in time where a certain unit1 will be on a straight line, this will give you the range for any arbitrary t1, t2, t3, etc... you know that either unit2 (depending on its speed 2x or 1/2 of unit1) will have it's range circle in any direction intersecting that unit1 straight line - the circle either intersects twice if it has the speed (one of the intersections points can be dismissed), or it never intersects due to the angle that you do know but might be diverging enough to exclude any solution. But if it is a player anyway, at best you can make ai point towards a leading position based on current player veolicity and direction, they will eventually meet. EDIT:

during my tests whenever a leader has given some "attack" order to a unit, the latter is unresponsive to script do*/command* commands. For these tests i always {_group enableAttack false}. Even then your commands may be accepted but soon overuled by other lower ai behaviour directions (mostly if in combat). In the first case because of "priority" the second because of "expiration". tpw and mrflay, many thanks for this mod. I should pm you guys soon.

patience... maturin :) Here's another one showing the exact behaviour i mentioned up in the earlier post. (sory about the earlier mispublish) (=2 mins in, bonus matrix revolutions moment in the end between oposing ais :P) (i say in the video this is unmodified ai, but indeed i have allowfleeing 0, not that it makes a diference in this case) Opfor leader (OF12_1) has the same coverage script and is the only unit running it. It is currently detecting 2 threats and drawing lines to those perceived positions. Behind the building against him there are 2 blufor units (BF12_7 and BF12_8) they are 100% in coverage from the OF leader. BF12_8 is totaly off the perceived position, yet BF12_7 position is accurately identified. OF leader has OF12_4 sending him the correct position, but as soon as the BF unit goes behind the container there goes the leader's (and BF12_4) perceived accuracy, but only for the short while that his subordinate misses sight of the BF unit, which is later killed. This is a solution, unfortunately afaik, is out of reach of modders since these perceived positions read only (nearTargets). And we can't just make any AI forget about an already identified threat. EDIT: There is one possible explanation of the AI detection bugging out or not working as intended. You can notice it (@3:35 in the 2nd video), and i have been seeing this in the tests i made: when the units move, sometimes the their feet go underneath the terrain. I have placed one sensor on each foot (the position i am obtaining with {_unit selectionPosition "leftFoot"}) which sometimes turn the visibility line into red even when the caracter is fully under coverage (meaning it is returning no intersection detected = no coverage). This could mean there is some fringe cases (when model is being animated) where maybe, and this is pure speculation, the engine itself is doing the same and allowing AI to "see" in those very specific circumstances. Though currently the script only check objects intersect (ignores terrain) this should not happen in theory.

^^ exacly, though i haven't gone through much tests in vegetation. I have made also a take on the general issue (maybe too long ~9mins it shows more stuff related), but should be plenty to dispell any myths around. This is not to say that in some fringe circumstances the expected detection behaviour is not overuled by other facts, such as lacking/imperfect visibility model lods, or the current broken hearshot perception. But basically AI does what should do in this department. I do agree that it could be improved (see the point i make half-way through about the AI perception placing an enemy somewhere, place which has no enemy presence whatsoever - suggesting a fallback to previously perceived/actual conicidence). (btw this is on current beta - no dev branch)

I know for a fact this is not true. Looking at it at face value it just may _appear_ so... AI keeps track of enemies based on a _perceived_ position not _actual_ position of enemy. What you're seeing is the normal extrapolation of the enemy position based on its last _visible_ position AND _movement_. So if a enemy stops or changes direction (behind an occlusion) the extrapolation the AI becomes inacurate despite still following that "perception". The effect you are seeing is exacerbated to the extreme if there are other AI on the same group around with visual on the target, which WILL share the actual enemy position with pinpoint accuracy, this may lead to the notion that AI "sees" enemies through walls. This sharing is without delay and as accurate to the AI that actual has sight on enemy (and indeed BI could make this sharing less absolute to mimic human behaviour). I am also interested in this abnormal AI behaviour and have made some debugging tests that may help show my point. I'll upload a video or 2 with the experiments.

Not only that, not all mods are dependent on BI tools to be created. A text editor is best modders friend.

^ not acurate, but not far. Keep in mind there is also "Formation" native FSM running aside of danger.fsm, and that is the one most impacting (there's a graphic representation of it in the file "formationEntity.fsm"). DangerFSM does activate a gesture on enemy's first contact and also stops vehicles when it finds it is able to shoot. But it is indeed underused.

Can't say i'm impressed with the stream, though i liked the firing drill. The scenario will be a wonder to explore, no doubt. btw, i don't know what app you were using for the streaming, but i've been quite successful with OpenBroadcaster, give it a try (bonus: also allows to record directly to file instead of streaming)

get real MassAsster... fyi some of the current BI devs where contributing members such as gnat. don't drive the topic that way, please! On the license update itself, and as one of the ceptics, it looks to be a step in the right direction... the most significant part to me being: "(...)You furthermore represent and warrant that the User Generated Content, your submission of that Content, and your granting of rights in that Content does not violate any applicable contract, law or regulation" This should help in making any potential case, still though, IP dispute/Violation of 3rd party terms processes should have an official and distinct avenue (aside of report buttons and the like). Also this still leaves the burden of proof on the side of the eventual victim, not very pallatable to me. But an explicit admission in the license that it may be void in case of violation of other preceding licenses is a step in the good direction.

It is estabilished today how instrumental it was the Deregulation of Financial markets for the 2008-? unfolding of the World Financial Crisis, it's real human tragedy consequences, social breakdown, and the huge question mark facing civilization today... Given how adamant in advancing Deregulatory policies Tatcher was (see 1986 LSE BigBang)... If these are indusputable facts as they are, i think it is safe to say that Tatcher's legacy makes it hard to nurture any kind of sympathy, even if she contributed to this mess only to a very initial extent, even at the time of another human's death. I don't trade my respect for humanity against her's. Let those be my last words on her subject. OT: Don't waste your time with minutemen (or timekeepers for that matter). It's the "imor(t)als" we're after.

Yes, that is a southern moon! Yet the big dipper, polar star are recognizable in the sky. This is inconsistent.

I am sure NK will be able to come up with original textures, or ultimately distribute authorized modifications. So far to illustrate his idea, learn the engine and show the potential to improve the default looks, it is quite effective.

It's quite possible the .paa texture you're altering is/are defined in a .rvmat file. Those are binary but if you open them in a text editor you should at least be able to confirm if the texture in question is defined in one of those .rvmat, i wouldn't look too far from the pbo (guessing plants_f.pbo) you opened where the .paa was in (same name even .rvmat). GL

Not sure this structure should be a correct assumption. What would go under "PBOname/data/" should be the raw files for the engine to use, and not a .pbo itself. A .pbo file should contain that file structure, not be refered to within. So inside a PBOname.pbo : config.cpp (with properties containing references to relative paths - "data/changedfile*.paa" OR absolute paths - "PBOname/data/changedfile*.paa") data/changedfile1.paa data/changedfile2.paa data/changedfile3.paa The "Myname/PBOname" is recomended but then it must be the same throughout, so that would imply where absolute paths are used to use "Myname/PBOname/data/changedfile*.paa" instead of simply "data/changedfile*.paa". BinPbo creates the files. "config.bin" if the option to binarize is checked, "texheaders.bin" if textures are being processed. "$PBOPREFIX$" automatically or as specified in options. The file path should be as explained above, either relative (to the root where config.cpp/bin is) or absolute (including the relative but prefixed with "Myname/PBOname" as specified by $PBOPREFIX$).

Take a look at this thread, it simplifies modding the midrange detail texture. (feel free to share your intermediate results there if you so whish) In regards to the issues you're having with the tools, i have failed myself at it sometimes, one must indeed be careful, it is easy to miss one piece of data here and there and binning will not result in a usable .pbo. I suspect you're having issues with proper paths. How to make sure to have working paths? Short answer: make sure your $PBOPREFIX$ checks with the folder structure used in config.cpp. Long answer: EDIT: Just noticed you previous post, much more extensive in the explanation, hope you manage to get some pretty textures working soon :)

For better context, this was Gabe's talk i refered (30 mins in on f2p model, and value and economy creation afterwards, the meat is from 42m forward) Gabe at 48m05s, after recognizing the real value added by modders: So from the get go there is concern in making the platform fair, and i believe this is Jason Holtman's department, but i don't think valve has delved deeper into the subtleties the platform brings.

I was insuficient in my explaining: i am not merely saying the modder can't ignore it because of fear of losing the high reach SWS would provide. I am saying that: since an impostor will have higher reach than a SWS non-user modder, his IP is in higher danger of being lost. With little to no means to claim it back. And this is why it makes it harder do take a suitable decision between use or not use SWS. You get in trouble both ways, one is sure trouble the other is just a possibility but very real at that. Of course. That is what i suspect and saddens me at the same time, since it reveals their apparent neglect for the modders interest, which otoh they feel so cosy with (about 75% cosy) Look i've listened to Gabe's talk about his vision about this... And i really admit i got captivated by it, but the way it is being lead into practice comes to a really unbalanced deal towards modders. TF2 experience with trading of hats is all fine and dandy, but we're not talking about mere hats here. EDIT: to add that i may have sounded a bit materialistc back there, but what really worries me on top of it is the IP, someone said in this topic that modders don't earn the monies, they earn credit. It is mostly the latter at stake here. One thing i would see as a positive step on the part of valve is feel itself more responsible by what is uploaded. Be prompt in action when some thing is reported, have a formalized way of solving IP disputes... etc etc. They are simply leaving you out in the cold, the way it is working currently.

@ASR_AI requires clients to have it installed, this one is exclusively serverside but does influence client controled ai. This brings advantages in itself. Also asr_ai (i use it myself) is of much broader scope, despite configurable.

No doubt gnat... it occured to me but hadn't deeply seen what it comes from it. End-user would ultimately be the one more negatively affected by it. @boota Not using the workshop is what i intended since knowing about it's license. The problem is the modder in general can't simply ignore it due to it's comparatively expected higher audience, exposure and ease of use. So an impostor stealing work and using Armaholic and others to distribute would have much contained consequences (this putting aside how supervised those platforms are). I have to admit it is a very precarious non-solution. I really don't know what to think of it. It is valve that raises the issue, they are the ones leaving modders in the worse of all places possible.

Of course... you must first press "Escape" before "F1"

I would like to leave a suggestion mainly to the modders that would not otherwise use SteamWorkshop. Has an authorship placeholder, to prevent impostors taking the light, release a limited version of the mod to Steamworkshop. As limited as the features you don't want to surrender to valve's terms. A modeler could limit lod and texture resolution, a mission maker/feature scripter could limit certain functionality (ie config dialog, disallow customization, etc.) This so far is the best idea i have to deal with valve's current legal grab. It imposes some uncalled action on our part but i rather that than cry later.