• Content count

  • Joined

  • Last visited

  • Days Won


Everything posted by Wingnut

  1. cloth

    Hi @jorditantadiaz. Take a look at THIS browser-bogging playground. First, notice the demo uses CannonJS physics engine, and not the default Oimo physics engine. (line 5-6) CannonJS is currently the ONLY 3rd party physics engine for BabylonJS... that allows meshImpostor. meshImpostor is how to get a physics impostor... that perfectly "matches" a complex shape such as a manikin. So, your manikin MUST use a CannonJS meshImpostor... for its physics impostor (like I did with the torus knot... which is a complex shape). Now for more bad news. meshImpostors ONLY interact-with sphereImpostors! OH NO! Thus... notice I changed particleImpostor... to be sphereImpostor... for the cloth (line 53)? I had-to. When it was particleImpostor, the cloth drops "thru" the shape. And notice the speed of the demo? Browser killer! 4-5 FPS? Nod. But, this is your challenge. Cannon MeshImpostor on the manikin, sphereImpostor-based sim-cloth for your garment. I don't mean to discourage you, but your hopes... are rather large. What you MIGHT wish to code... is a custom collision system. Perhaps it will be much less powerful and detailed than Oimo or Cannon, yet it will allow you to place garments upon manikins with SOME body-contour-following accuracy (spandex). But even then, garments and manikins are NOT simple bounding boxes, so simple mesh intersect testing/checking... is difficult. Now if you want to use "weighting" on the entire surface of the garment (so you can see how a dress or sport coat "hangs" on a person)... you will need many many many weight points and calculations (for proper-acting clothing). This is a big challenge for Javascript. Interesting, though. I figged I would tell you some little things about meshImposters and complex shapes. Perhaps others may comment. The "super-hero" move would be... get particleImpostor... working with meshImpostor (deep Cannon.js hacking and native-method calls). That would be essentially the same as coding your own custom collider/intersecter. You would essentially be creating "CannonJS For Clothing" ... also a big project, I suspect. I'm no expert, though, ok? I could be wrong about anything, anytime.
  2. (Wingnut giggles and points at Ozrocker for being pulled-over by the topic police) (Wingnut also reports officer Palmer to authorities... for being far off-topic... with his off-topic-ness comment.) heh Now we're REALLY confused, huh? Ok, but now, "BJS is moving fast"... umm... uhh... crap... I can't think of anything pertinent to say. Let's see... I need a universal "juicy" comment... to keep the thread alive. USA... 1950's saying... "So's your old man!" There, I said it. NOW we have some controversy and drama, again. Maybe Ozrocker will think twice next time... before using comedy to lighten the mood of a tense thread.
  3. endCapTri is undefined (uh oh) @Rolento... did this label avoidance thing. *nod* *thx* N. Containers. Groups. Borders. Padding. Are groups... containers? Should they wrap, overflow, clip, auto-expand-to-fit? Are borders added to padding? (thus, are border widths part of wrapping/clipping equations/consids?) Do groups need to communicate very carefully with their "assigned" border prim? hmmm. I love speculating about this crap. Sometimes Nox teaches me cool stuff. hehe
  4. Hi gang! Newbie Wingnut here again, hope everyone is well. I've been playing with the multiple-basic-object (primitives) demo in Tutorial 02. After firing it up... I found that the PLANE involved in that demo... starts on edge to the camera, and is black (textureless) on one side, and invisible on the other side (backface culled). AND, the plane is too big in my opinion. AND the camera too far away. A few tweaks and things got closer to looking like the demo picture... but no apparent default material is on the plane. And I suspect that we can make cones with a correctly-argged createCylinder. All in all, I think BABYLON.Mesh.CreatePlane should create a plane that is more see-able by default, via positioning it as a 'floor' upon creation, with its non-culled side UP, and via putting a default material on it like the other primitives/basic-geometry. But, that's really not what I wanted to yack about. I can foresee a time when we will have LOTS of procedural (dynamic) geometry-making routines in babylon.js. So many, in fact, that I think a 'procedural geometry pack/lib' might be considered as an add-on library to BJS. So I ponder this... Instead of things like... BABYLON.Mesh.CreatePlane(blah, blah, etc) We/you instead have only one geom-o-generator command... BABYLON.Mesh.CreateGeometry([word or number], blah, blah, etc) In the first arg/param... a word/name or a number. IF its a number (say 12), a dodecahedron (12-sided polygon) is created like any other of the basic shape primitives. IF the first arg/param is a WORD, such as cube, sphere, cone, box, etc... it works like it does now, using the rest of the parameters as beginning settings FOR that object. That first word could also be the NAME of a procedure/method that might be inside the geometry generator lib mentioned above. IF the first arg/param is a word that is NOT defaultly recognized, such as "octagon", the call looks in the 'shape generator library' for a procedure of THAT name, and if the right amount of added args/params are set to satisfy the call... it uses the code in the 'generator' to make said geometry(s). Now lets go back to the NUMBER as the first arg/param. Lets say that number is 8... which means produce a octagon-ish 8-side polyhedron with either a builtin BJS procedure, OR call the addon geometry generator's octahedra method. This way, we/you could essentially eliminate all the createWhatever commands (there could be lots someday), and use one instead. The command would sometimes/always defer the action to the add-on primitive/shape generator. I goof around in 3dMax a bit, and I've seen their massive 'library' of procedural primitives/shapes, and one would think that BJS is destined to have every one of those, plus a few hundred more. Thoughts, anyone? Thanks!
  5. Cool! Congrats on the new positioning system, Noxxy! Was the refactor caused by a situation with container flow/overflow/scroll/wrap/wordwrap? Bet so. Containment SUCKS! The folks at CSS Styles Working Group, and the folks who work-on browser "flow" systems... have all gone insane. They're all in mental institutes... getting shock therapy. It's very big. Padding == 12 mile nautical boundary waters. Wrap = South China Sea. Containment... is a HUGE subject. Don't let it take you down, Nox. Borders, paddings, margins, wraps, scrolls, overflows, etc... hasn't yet been learned by earth creators... so YOUR system of working with those... cannot be done perfectly, yet. (Wingnut being goofy.) Did you lose some backward compat on the primitives? Major changes to some of them? It's all okay and expected... along with time needed. Farm-out tasks if you can, Nockawa. I'm qualified to do laundry and fetch groceries for you, but that's about all. @thiendv's context menus were quite easy, though. A little steep learning curve, and some problems with isPickable when we installed it in the scene... but... worked good. Once we learned how the knobs were used, we turned them to the correct values. We were picking the skybox with the mouse right-click, and the context menu was bouncing around in the scene. Then we set skybox .isPickable = false (and some other isPickable tweaks)... and it all started working good. @adam's doing some things, too, I think, right? Working-with centering prims/wsc2d's on their trackNodes... I think. Maybe that's what caused the need for positioning refactor, eh? Thanks alot, Adam, dammit!!! (just kidding, of course). Thanks for your work on the prefect-centering issue, truly. Bounding box measuring hell, I bet. We also want to find that guy who wrote the "labels can't overlap" demo/system, recently. I want to make sure that his system STAYS WORKING. (I can't rem his name). SO... let's find him and his demos... and make sure the new positioning system... doesn't break his no-overlap system. If so, let's help him fix it. I think the "no overlapped labels" is a rather important tool to keep handy. ok, party on, guys!
  6. Hiya SR! First, that error has been seen in CannonJS, too. Even though it is annoying, I think it can be ignored, for now. No impact to physics operations have been seen so far, caused by that error report. BUT... it could be related to the ORDER that the physics impostors are added to parent/children. You should probably read this thread. It does some talking about the ORDER of impostor-adding.... when dealing-with parent/child compounding. This badly built Oimo document might be of some help, too.... for advanced OIMO learning/hacking. (I don't wish that on anyone) ("native" calls are scary!) And... lastly, we have seen SOME indications that... it is un-wise to scale a mesh that will be used as a physics parent. By using the meshBuilder system of creating basic mesh, you can set some mesh size/scale dimensions... without needing to use .scaling. Scaling, rotation, and position are handed-down from parent to children, and this is how it could be related to the "order of adding impostors". I'm no expert, and docs are introductory level, so far (but thank goodness and Raanan for those, too). Perhaps you can help us with advanced physics docs, in the future? Don't forget playground searching, too. Hope this helps.
  7. VERY nice, @thiendv! You ARE an expert in BabylonJS! I think you are ready to open 3D Graphics School and teach others. Well done! Only one (context) menu activated so far? No door or drawer opening/closing? It's okay. Perhaps you can create "Doors, Drawers, Context Menus and Color Changers" ...teaching playground, someday. Yes? Maybe in a year, okay? In a year, perhaps @Nockawa and his team (he needs MORE team, by the way) will have new context menus. They will be much easier to use than our current method, T. Anyway, again, congratulations @thiendv... your scene looks great and works great! COOOOOOL!
  8. Hi hunts. (Some basic obj loading - see console for mesh names.) When used at home, you must include the object loader extension. See Hope this helps.
  9. Hi K! No replies yet, huh? Sorry. I see no particles reflected in the mirrors of my xmas tree demo. Something is broken or something has changed in 2.6 alpha. These things are normal for alpha versions (work-in-progress), and thanks for the report. We'll make sure @Deltakosh sees this issue, and that it gets addressed before 2.6 official release. I wish I had more answers, but I don't. I know some webGL 2.0 things are being tested, but I don't know if those would affect 2.6 particles and mirrors. Perhaps others will comment soon. If not, I will eventually tour the 2.6 git-mits (github submits) and see if I can determine when/how the issue was introduced. Thanks again for the report... good find, well done.
  10. Hi BT! Sorry for slow replies. I am not expert, but I try to help. Please DL/view It is "stripped" (and white-spaced) dude.babylon. In "meshes" section, I have removed almost all values in big arrays... such as "positions", "indices", "matricesIndices", and "matricesWeights". Now they are only for looking-at. This .babylon file will not load properly. I broke it. Please take notice of matricesIndices and matricesWeights. Those affect animation. See all 58 matrix animations in stripped_dude.babylon? All are dataType 3. Go to some playground and enter line console.log(BABYLON.Animation.ANIMATIONTYPE_MATRIX); Returns: 3. All 58 animations... are matrix animations! They are being done to "bones" which are not mesh, but really matrix transformations, that happen to mesh... which have properties matricesIndices and matricesWeights. Starting to see answer to Q1? When you do see it, TEACH ME ALSO, PLEASE. heh. Q2: Here I was playing. I do funny rotations in line 25-26. In line 27, I get positionsKind data for meshes[1]. Then lines 28-30... I try to move (transform) one .position/vertex. Then line 34, I try to "write" positionsKind data back to object, with parameter updateExtends = true. (updateExtends adjusts boundingBox size if needed). As you can see, bounding box size IS growing, but I cannot make a vertex on dude's head... move/display movement. Maybe he is set updatable = false. hmm. Just playing with the mesh... having fun learning. Q3: and Q4: I have no answers. Possibly, JSON parsing/de-serialization performance is optimized by using these methods. Not sure. Perhaps @Deltakosh or other 3DMax exporter contributors will respond soon. Fellow forum helpers... please help, and please correct me if I have said wrong things. I am no expert in bones, skeletons, and their animations. (actually, I'm no expert in ANYTHING, except perhaps aimless talking.) heh. Darn. Matrix transformation animations! Coooool. Bad to the "bone". Sorry I wasn't more helpful.
  11. Hey @fenomas... notice that we (Hans and I) are not concerned about seeing the jitter, and we are not concerned about reducing CPU load. We just want to keep the player box atop the platform. But a THEORY we have is: Jitter affects friction. AND... we have a new issue that Hans has raised: Friction is asleep on sleeping bodies. So, if we move the platform while player box is asleep, platform-player friction will not work, and player will not move WITH platform. AND... we would like to learn about LOCAL linearVelocity and see if we can impulse the green box from side-to-side ATOP the platform... without affecting the platform (other than maybe tiny platform tilt due to mass position-change). NOW we're tuning some parameters. Ground-platform mass/friction, platform-player mass/friction, etc. But still, we have studies to do on auto-sleep... and when to wake, and why. If we slowly tilt platform... with sleeping player atop, will player EVER start sliding? hmm. Perhaps player box will wake when tilt starts. Tests ahead.
  12. AllowSleep on world. Wow, I didn't expect that. Cool, thx. Does it affect anything in our 5-minute jitter-off scene? Did you test it, @fenomas? This is your "working" demo, with both renderLoop anims disabled. The green box falls-off-of the red platform... after about 4.5 minutes (on my desktop machine). Is that "working"? Hans has done lots of "parameter-tuning", already. Telling him that incorrect solve... TWICE... well... seemed a bit hard-nosed to me. Then again, you didn't back-read the thread, so you didn't know what was already tried. *shrug* It's all cool. Hans has been waiting a long time... for better help than I... and we have both done some begging for help... for about what? 3 weeks now, Hans? A month? Not many forum helpers wanted to come to this campfire. We're glad you visited, Fenomas! Sorry for the long thread... but... it's been THAT long unsolved. We just kept experimenting and trying things... and failing. But we were also working on an issue about scaling physics mesh-shapes, too. Thx for the reminder about world.allowSleep. I think that is the solve we were looking-for. Added that line at 157. That demo now shows a quick-change to player.sleepState = 2. And, I'm not seeing any indication of jitter-off. YAY! Perhaps we can learn about auto-sleep, now that it is activated and apparently working. Who would have expected world.allowSleep to be false by default? hmm. Okay, we have things to work-with, now. New life for our dead-end thread. Thx @fenomas, well done.
  13. You are using a tranquilizer dart for sleep, and "smelling salts" to re-awaken! heh. That's not the same as "falls asleep" Comedy aside, I think all should be automatic. There should be no need to test for intersection, and no need to force sleep(). It should be magically done FOR us. (maybe) hmm. I'm going web reading about this - see if I can learn something before I fall asleep.
  14. @fenomas, what IS sleepSpeedLimit, allowSleep, sleepTimeLimit, sleepState supposed to be used-for, then? When is the auto-sleep system SUPPOSED to be used? For what? Why do these parameters exist... if they are not used to stop forever-jitter? I'm confused. (thx for clarification) By the way, I turned-off all the before-render animation in your demo: Although I didn't watch it... I estimate about 5 minutes until the green box jitters-off the platform. Fenomas, can you (kindly) clarify? Auto-sleep cannot work... when gravity is a constant force? Do you know? (This was talked-about in previous areas of thread. I think Hans saw sleepState = true IF he reduced gravity to zero.) Or maybe, sleepState NEVER had ANYTHING to do with jitter? Maybe it's not intended for that. (these are some thngs we could use answers-to, everyone). Hans has been a delight to work-with, too. Kind, extremely patient, entertaining, willing to experiment and invent, reports all discoveries, just a great guy. I highly suggest we try to treat him kindly, in return. Yes, multiple issues have been addressed, here, but still... topic is on-subject with... WHY no-sleep/why jitter-off? Perhaps Hans and I are on a wild goose chase.
  15. Hiya @SebRomeo, welcome to the forum. Sorry for slow replies. Does "infinite relative map" === "infinite terrain"? I'm no expert in webGL, but we DO have some BJS infinite terrain projects nearby. @NasimiAsl's Blog500 is such (pg demo, too, use down-cursor to back-out of Nasimi's "home cylinder"). And I believe @Pryme8 has some noise-driven infinite terrain in his Teriable demo. Tiled grounds has been tested a bit, too. Please visit the 3 links for CĂ©lian Garcia... seen in our Offsite Tutorials List. I played with tiled ground a bit myself... here. It uses a divided-up displaceMap/heightMap to create 16 tiles, which I then try to assemble back together. Mostly, I fail. This demo/series is still awaiting a lighting-normals "sewing machine" - to "average" the normals across the seams - to avoid color changes at the seams. There's a massive thread about it all... here. All participants in that thread... died of boredom. heh I hope I am on-topic. If not, sorry, please clarify. I wish I had more/simple examples to show... but I don't. Perhaps others will comment soon. Welcome again.
  16. Hi guys! This is some heavy thinking, here. Binki, I feel your pain and curiosity. Here's my take. The best compound impostor... is made-of various other impostors... which are cooperating (grouped). But, think about that. When two sphereImpostors are linked/jointed together, they are in battle. So, to build a compound impostor, it is more sane to "sum" the area of the two shapes, and attach a box impostor of THAT general size. Since ONE of the two shapes will be ONE "extent" of this new "summed low-detail boxImpostor", we might as well use it as the "master" of the compoundImpostor. I think this is why ONE of the shape-parts... is used as the master. It is considered a boundingBox extent (one edge/corner of the new derived bounding area). OR, I could be completely wrong! Has anyone ever wondered... what would happen... if child mesh overlapped parent mesh? (both physics-active) You know how those darned impostors HATE being inside one another, and prefer to "spit-out" each other? Coooool. Would one impostor be put into constant "barf it out" mode, while the parenting says... "you ain't going nowhere, overlapped child impostor". Parent-child wars! CPU mega-chow! Pretty soon your browser's immune system would start breaking-down, and then... blue screen of death! err... okay, maybe not that. Good questions/thinkings, Binki! Gotta think about... "What IS compounding?" When the sphere impostor is attached to the box impostor... don't you lose the best features of both? Really, they should be distance-jointed together, so sphere keeps its sphere-ness physics, and box keeps its box-ness physics. Even then... that joint... hurts the box and the sphere. They are both hands-tied... so they can't roll with the flow. Over in another thread, I think @Hans and I discovered that we shouldn't ever scale the parent, but that's all I have learned. (I hope you weren't expecting anything wonderful from me) heh
  17. Interesting! I like hearing camera talk. The more info I can gather, the better chance i can update our cameras tutorial... someday. I'm still leaning towards TWO docs, though. Basics, and Tumor-Level. inputs.attached. hmm. Backward compatible. hmm. Three main inputs for FPS game. hmm. I wonder if there is a version of BJS in a secret folder... that is "rogue"... and it doesn't care ANYTHING about backward compat. I wonder if it exists. hmm. BJS - Version X - Black Ops (Don't even bother THINKING-about asking for help with it. It's black-ops, unpredictable and dangerous.) "If the scene you created today... works again tomorrow... then you're doing something wrong." heh
  18. Nah, you don't want to deal with 3JS... they're all a bunch of drunks over there. Oh wait, maybe I'm thinking about ME. To be frank, I don't even know what "field of view" IS... when dealing with stereoscopic rigs. metrics.interpupillaryDistance and metrics.lensSeparationDistance are not what you are seeking, though, apparently. Even if we DID get standard .fov working for both rig cameras... I don't think THAT is what you are seeking, either. I would have thought .interpupillaryDistance == fov (for stereo rigs). But I guess that might be considered "cross-eyed-ness", huh? Wait, isn't cross-eyed and wall-eyed... the FOV for stereo rigs? err... no... I'm repeating myself. I don't have much experience in this new fancy stuff. I probably should have left this one for @davrous. He gave you a LIKE, but then he didn't have an answer. I hope your question didn't give him a brain tumor. But, don't you worry at all about a BJS solution. It's all JS. EVERYTHING is customize-able... if you have a little patience, time, and diligence... to learn about camera rigs. Everything is here. We just need to mix the correct dangerous chemicals together. Meantime, what the heck do you mean by FOV, Niko? If you DID get individual control of standard .fov property on both rig cams... do you think THAT would fix your issue? If you feel like talking some more... I would surely listen, and perhaps others would, too.
  19. Hiya K... welcome to the forum. Perhaps my friend @Temechon won't mind my intervention, here. Essentially, we start with a highly-subdivided Babylon GROUND... which is a plane with... well... lots of subdivisions. I think these are sometimes called "patch grids". In line 29, we make a ground grid... with 512 by 512 subdivisions. It is a fairly hi-rez mesh. This is needed so that our engraving has good "clarity" or "granularity". Now for all the BAD news. Nearly EVERYTHING in this playground example... had to be done "upside-down". In line 22... hemispheric lights almost ALWAYS aim straight-up... 0, 1, 0. This one aims straight down. Line 24... the groundColor, which normally is used to color the BOTTOM of hemi-lit mesh... is used to color the TOP of your engraved panel. Weird, huh? We're just getting started. Line 33... the displacement map minimum height = 0, and maximum height = -.5 ? How goofy! Line 34... AHA! There is the reason. The ground-grid needed to be inverted.... ie. flipped-over, to make the hand-writing be correctly oriented. Without flipping the ground, the hand-writing was backwards. This can likely be fixed by using a CreateGroundFromHeightMap... instead of an applyDisplacementMap. You can experiment with that, as wanted, of course. I wanted to show an example of Temechon's idea. Some might say... "Hey Wingnut... why did you bother adding a StandardMaterial and doing material settings? Why not leave it without material?" (lines 35, 38, 40). Well, line 40 is important. We are viewing the BOTTOM of the ground-grid, and we needed to give it some color/texture. Sure, we might be able to get some color with light2.diffuse = someColor3 but... I decided not to try that... yet. Remember... with light2... (the hemi).... the .groundColor is the top of the ground- grid, and the .diffuse is the bottom. (Because of the unusual -Y direction of that light) So... setting light2.diffuse might eliminate the need for having a material, and the need to set .backFaceCulling. Maybe. Lastly, this is a lighting nightmare. (a good challenge). Light0 and light1 are twin v-opposing directionals... with .intensity of 30!!! Holy crap! That will burn your retinas into french fries right now, huh? And still... our negatively-displaced engraved text "channel"... is quite dark. There's HOURS and HOURS of lighting fun to be had... trying to light that engraved text! PARTY! Don't forget THIS SECTION of our lights tutorial. It says we can have more than 4 lights on a material! All we need to do is set groundgrid.material.maxsimultaneousLights = 10; Yeah, with 10 (or more) directional lights... I think we can properly light ALL the "facets" of the engraved text "channel". Maybe. heh. FUN!! Perhaps we could fill the channel with petrol, and start it burning? Then the engraving would be well-lit, huh? Ten directional lights... grouped, and then spin the group of lights REAL sloooow... and the facets inside the text channel... should start to twinkle. (Might need to increase the .specular on all lights, and increase (high-powered-color) the .specularColor on the material itself. Did you know that the values within a BABYLON.Color3(here, here, here) don't NEED to be between 0 and 1? You can put BIG FAT numbers in there! I use blue values of 6 OFTEN! DEMENTED!!! Fun! There's definitely some possibilities for sparkle, here. Might need to change 512 to 1024... more facets to sparkle. LOVE that sparkle! Hope this helps. Holler as wanted... but have fun experimenting, first. Try modifying that playground, make some more saves, show us what you discover, if you wish. Here are some more engraving images. Good luck! What's that? You say you want another demented factoid about the upside-down ground-grid? Ok, let's add light #3... a low powered pointLight. Line 26... there it is... a point light working fine... except... umm... it MUST have a NEGATIVE Y value (-80). It is UNDER the groundgrid, yet it shines light atop it. WOW! What a "topsy-turvy" playground we have!
  20. Hiya Niko! Welcome to the forum! I made a little scene.beforeRender animator (val -1 to +1), and tried making "pokes" (sets)... on camera._rigCameras[*].fov (lines 55 and 56). hehe. It was a deep demented attempt and didn't work. Oh well. Lines 53 and 54 work (need to activate line 57, too). They do something, but you have already done tests on the metrics. Aw heck, let's activate line 53 and 57 and see what it looks like. Not very exciting, huh? *nod* hmmm. Let's keep playing/experimenting... and invite others to play, too. C'mon everyone, play with our playground... make more saves, see if we can get something that Niko can use. I dunno why I couldn't make settings to camera._rigCameras[0].fov and camera._rigCameras[1].fov. Not only did it fail, but I got no smoke, sparks or explosions. How boring.
  21. I did a few more tests on scaled shapes (all MESH class, no MeshBuilder). I THOUGHT the problem was .scaling that is inherited from the parent. But even with no scaling on the railings... ...the railing impostors are having problems stopping player slide. I'll keep thinking. Update: Essentially, thou shalst not scale parents... when using physics. Cursor keys are fast and smooth on that one, huh? *nod* WASD for cam, as always.
  22. Hi MW! I don't think that kind of fine granularity is possible, but you might be interested in our new version builder... Be well, stay tuned. More (and smarter) comments might be forthcoming.
  23. Hiya Adrian... welcome to the BJS forum... good to have you with us. I don't have any answers or help, but I wanted to say hello. Can you elaborate on the version-builder failure? Did the version-builder complete the build? If so, gITF loading failed using that build? Can you get gITF loading to work AT ALL, in ANY version? Give us many details, if possible. Version-building is somewhat new to us, and could have some minor issues. And, gITF loading is certainly new... to everyone. Keep in mind that gITF loader is an extension which probably needs to be included as a separate <script>. See this. Let's ping BJS superstar @Luaacro and see if he has some advice, or wishes to monitor our thread.. He might be heavily-involved in the new gITF feature. Stay tuned.
  24. I don't think others have as much free time... as I do. But the subject of my year-ago rants... was specific. I was trying to establish the league of extraordinary forum helpers. I got piss poor response, so I decided to show fellow forum folk exactly what extraordinary forum helping IS (in my opinion). In doing this, there was not much room left for others to participate in that. 4-8 of us helpers were kicking Q&A ass SO FAST... that nobody else had a chance. heh More about the specific purpose: Those rants and blood-boils are/were attempts at setting policies for forum helping. These won't appear as being helpful at first glance, but after the emotional reaction and pout wears off, they leave a residue. That residual "resent" might have a Wingnut-hating after-taste, but they are still valuable for setting helper policies, and for helping other helpers... self-examine. Essentially, I tried to make it OK to fight for altruism, and not okay to be ego-centrist (self-centered). These things... how to care about others, no matter how annoying... is more than just a forum policy and attitude. It is LIFE policy and attitude... and thus... it strikes at the heart. When you question someone's heart, and put it on a pedestal for all to inspect, it's going to piss off some people. It might not have appeared helpful, Nox... but I think in some cases... it is/was. It is attempting to teach... Wingnut's version of... the "spirit of teaming". It's commie in nature, and it goes head-to-head against competing (competes with competing? heh). Competing, in my opinion, is an epidemic, mostly caused by money tug-o-warring in folks' lives. Nox... it is a HUGE foe, and takes some serious heart-string pulling... to affect. Lots of forum friends have steered and adjusted my thinking, too. I strive to take others' wisdom and experiences into consideration, whenever possible. Try to keep in mind what was being attempted with those rants. They had a specific purpose against an elusive and overwhelming enemy. It's related to my anti-capitalism ways, and my 9 years on USA Team Air Force (a commune). Thus, it touches onto politics and morals. Those things can "seem" off-topic to those who don't normally work-on communes and team spirit.
  25. thx db. Too bad he had to wait 3 days. That's just embarrassing. I stop working the dailies for a week, and a 3-day-old 0-reply drops through the grates. How many forum helpers here? 40? Sad.