User talk:Geyser

Clean slate here, marking my change of status. I'm still an admin, and I'll be making a few contributions (mostly Edition brainstorming and todo). But you no longer should feel like you need my permission to carry out more or less radical initiatives. You're all big boys (as in grown-up boys with jobs), so there's no reason why you couldn't weigh the pros and cons of an initiative on your own. You just need to think of it for a while, not as the designer but as an implementer and an end-user; you have to try and take some distance with respect to every kick-ass idea of yours if you want to see what it's "actually" worth (good old cartesian doubt, sorta); experimenting with a bunch of pages in your user space is always a good idea if you're not sure whether your idea is somehow evil (you always have to ask yourself that before you embrace something tempting, right?). And if "it's not EZ being OC", then, heck, try not to be OC for a change, chances are that it will be easier... --geyser 03:19, 24 March 2008 (CET)

As for me, well, I'll try to maintain a minimal presence here, but I have an awful lot to deal with IRL. Truth is, I'll be lucky as hell to make it at all; I hold out hope that my dedication to Oni has not yet brought me to a point of no return, but either way these are going to be a very tough few months. Take care. --geyser 03:19, 24 March 2008 (CET)

Best wishes; I will miss your constant harassment on the wiki! In your absence, I promise I'll try to ask myself, "What would geyser say?", before making an edit. --Iritscen 15:05, 24 March 2008 (CET)

Really really on Oni-sabbatical now, until further notice. Expect nothing. Take care. --geyser 21:57, 10 June 2008 (CEST)

Enjoy your break from Oni. EdT

---

Just in case, you are not visiting OCF, Loser is back and has come up with demo of a wall collision particle system: http://loser.oni2.net/Videos/Head2Wall_collision.wmv

http://oni.bungie.org/community/forum/viewtopic.php?pid=6944#p6944

EdT 15:25, 26 May 2008 (CEST)

Loser's intuition and patience are impressive as always. However, it can be a bit frustrating how he constantly comes up with something new instead of consolidating the hacks-so-far into something reliable and non-controversial enough to qualify as a release. Thus, the general TRAM hacks in the latest Edition bundles cause crashes via memory corruption. I've commented on that HERE. Oh well... We'll figure out something Soon Enough. --geyser 21:57, 10 June 2008 (CEST)

---

Thanks for the comment on the YouTube video. I really don't know how to make adjustments with 3D meshes. Being able to edit the TRAC in .xml is great. It still needs a lot of work, like you said the pelvis height problem for one thing, but it is a fun start.

Here's the files: http://edt.oni2.net/AE_Files/motoko.zip

EdT 04:28, 27 May 2008 (CEST)

My adjustments to the meshes are mostly limited to selecting groups of vertices and moving/scaling them around. I try to keep the transformations consistent withe the model's symmetry, either by transforming self-symmetric group of vertices or by transforming a pair of symmetric groups in exactly the same way. In some circumstances I need to delete/subdivide/create triangles or weld edges, or to fix UV vertices. Those are rather simple operations after you've done them once or twice, but a lot depends on the quality of your tool's manual/help. Blender has very poor documentation (partly due to the fuzziness of the product itself), XSI's docs are wonderful. Dunno about Cheetah.

geyser 21:57, 10 June 2008 (CEST)

If you're interested I made some new weapons: http://edt.oni2.net/AE_Files/NewWeapons.zip It has Halo's assault rifle, an Uzi like machine gun and a shotgun. The shotgun is basically, the chaingun without sustained fire. However, if you continue to hold the mouse button down, the audio continues. I haven't figured out how to fix that yet.

Hope all's well with RL.

EdT 02:30, 29 July 2008 (CEST)

I can't say it feels OK to keep importing ripped Halo assets apart from the Spartan (I'd rather use original weapons or steal from other games). As for the shotgun and SMG, making Oni look like Counter-Strike is not much of an improvement, so this is not trailer stuff: prefer the weapon meshes that I listed on AE:BGI, which I think are original and futuristic in an Oni sort of way: of course they would gain from having unique firing properties and being more than just a bunch of bullet-spewing machines... but a "bap" (BGI AutoPistol), a shotgun and maybe a machine gun won't hurt and could actually make BGI troops look more badass (just a suggestion, though, dude: don't showcase a new weapon with a trite stand-and-fire sequence - rather, set up a moving camera, show a death squad of Spartan mow down TCTF/Strikers/civilians; don't forget clear views or close-ups of the weapon). Coming back to the shotgun: we'll come to polish the ONWC and PAR3 eventually, but in the short run (for the trailer) sound issues are irrelevant.

geyser 11:34, 29 July 2008 (CEST)

Good points about the weapons, I picked these models as a starting point since they had textures. Looked at the weapons on the BGI page. the lack of textures is a problem for me, I'm not good with graphics at all, (the Delorean as an example). But I'll work on getting the models ready for Oni.

I was reading the comments on the AE Trailer page and its obvious you have a plan for the Anniversary Edition. Currently, as a community we are going in all sorts of directions, trying out different things, which in a way is good. For ex Paradox's Imago project. Perhaps to get more organized, can you make a single page called AE:Roadmap with your ideas about the direction AE could take. I noticed you already made a few pages such as AE:BGI, AE:Ninja, AE:Training, but they get lost in the wiki. So a Roadmap page with links to these pages could help to focus our attention. The same roadmap could also be posted to OCF for the lurkers to take note and some may come out and help.

FYI, I have been trying to find some Mac programmers that could help with the Mac engine, but so far, no success.

EdT 15:49, 29 July 2008 (CEST)

"the lack of textures is a problem for me" I know, but you can always use THESE (pointed out on AE:BGI below the main list). Also, the "BGI autopistol" HERE has perfectly good UVs, so maybe ask coool or someone to have a look. That's a good point, actually - who in the community can texture a gun that has UVs (THIS one)? who can texture a gun from scratch (THIS one)? no one? then we're screwed, aren't we? how will a roadmap involving these guns make us less screwed?

"as a community we are going in all sorts of directions" I feel bad about assuming project lead (I'm on Oni-sabbatical, remember?) and I sorta hoped for some kind of resonance among the more motivated and creative community members, meaning that someone who's talented, dedicated to Oni and aware or the possibilities wouldn't just sit and goof around... and would instead either make something awesome on their own, or maybe discuss specific skills and priorities with a guru (like, me). A digest roadmap is a lot of work, and I don't even have a TODO for a "team of geysers" that I could dump right now. Also, if there's no one in this community who can make a simple wiki page that links to AE:BGI, AE:Ninja, AE:Training, etc... then we have a problem. You can see those pages, Ed. You can see they're "lost in the wiki" and you think they'd be interesting to "lurkers". So what the blam are you waiting for?

So, don't expect a detailed roadmap for the Edition from me at the moment. I might post requests for trailer footage though: that's much more to-the point than issuing directives to hypothetical modders without a clear consensus or deadline.

geyser 18:20, 29 July 2008 (CEST)

"I feel bad about assuming project lead". Buuut... you are the lead on the Edition, and always have been. If you have to take a sabbatical, I won't argue with that (Real Life > Other Stuff). But, frankly, you haven't always been open to other people's ideas as to where to go with Oni-related things, so I can't see you somehow sitting back and letting someone else guide the Edition, plus, you're the one who works closely with Loser, Neo, etc. I personally wouldn't want to be the one to take over and then get criticized by an occasionally-active geyser who drops in once in a while with a bombshell after lots of work has already been done.

P.S.: I don't speak for Ed, but it seems unfair to say "You can see those pages, Ed" as if the Edition is a completely democratic collaborative effort, when really you're the one with the plans for the Edition, and how can Ed know what you're thinking? I would be glad to be a substitute taskmaster, trying to corral people's efforts towards AE stuff, if I had any idea what specifically you had planned. If Ed hadn't pointed out those AE: pages, I wouldn't have ever seen them. They're orphaned, yet don't show up in the "Orphaned pages" list. All things considered, I still think the only efficient way for the AE to move forward is for you to use whatever time you can spare to manage it yourself. It would help if you made a page like "AE:Content needed" to let us know what's going on in your head, with needs listed item by item. The more we work together, the faster the AE can get finished.

--Iritscen 19:33, 29 July 2008 (CEST)

Perhaps I didn't make it clear up there, but I sorta hoped for some kind of creative resonance with "fellow geysers", open-minded and patient enough to take in the to-do that I've been outlining for a year or so (primarily on OCF). I expected those motivated and talented people to contribute modular things that are prominently featured in the AE forum (I mean, the DeLorean has been around for ages, you'd think someone would have retextured it by now, right?), and if they can't find a subproject suiting them, they'd go and find me (that's what's been happening with Gumby; we kinda sat down and figured out he'd do particles for new weapons). All in all, this hope for a "team of geysers" is not totally delusive, but I understand the frontend is less dense and "itemized" than most of the potential contributors would expect it to be. One reason why I'm not too motivated to draw a roadmap is that I'm not confident that major extra motivation and organization would ensue: I wanted to see at least one "fellow geyser" show up first... and all I see is people like Loser and coool who could do great but keep goofing around without consolidating anything ^_^ There are ready-to-work-on items all over OCF and all over the wiki, and no one is working on them; how would an itemized list change that? that's just bureaucracy, that's what.

About the meta-orphaned AE pages, don't get me wrong: I was just encouraging you or Ed or whoever to link to them from OCF or Current events or wherever. I meant to add more of those and I meant to consolidate them as a roadmap, but I haven't done so, OK? and, the situation being what it is, I'm not the only one who can do something about those pages being completely invisible, am I? If you identify me as the project lead and shy away from any initiative, you're in for a long wait and possibly a big disappointment at the end. If I didn't have a job, I'd design and author the Edition pretty much by myself, but that is not gonna happen. And you can't expect me to consistently detail in words everything I'd do and how exactly I'd do it, because that's even more time-consuming for me than sitting down and doing it all myself. The best I can do is mini-pages like AE:BGI, AE:Ninja, AE:Training, when I'm in the right mood for delivering accurate and concise summaries of my visions. I could also make other, more specific mini-pages, like AE:DeLorean, and then I'd just let Iritscen slap a nice little "cat" onto all those (something like "Category:AE_roadmap", maybe embedded in a template). Then the category's page could eventually be filled in with a nice big outdated list (really, who'd keep "AE:Content needed" up to date? the same people who look after the OniSplit page, huh? would you leave it all to me? why, thank you...), but I doubt that'd be necessary: just a category, and specific mini-roadmaps and discussions on the respective mini-pages.

get criticized by an occasionally-active geyser who drops in once in a while with a bombshell after lots of work has already been done if those look like lots of work to you, then you're simply not fluent enough. Every development process involves a few iterations, and unless I give you lots of concept-art and verbose-like-crazy explanations aforehand, there's no reason why you'd create something beyond revision (unless you're a "fellow geyser"). I'm ready to work closely with Gumby and Loser and coool and whoever, but this implies a repetitive (if not intensive) back-and-forth exchange of tentative content and constructive criticism. When I tell you "your HD Griffin doesn't suck by design, but the mesh is FUBAR and overkill, here's one I made in response to yours, why doncha scrap yours and work off mine" - that's one such iteration, and it's supposed to get "the AE to move forward". Then it all depends on how much my analysis and authority are worth to you, of course, but you can't avoid iterations altogether.

you're the one who works closely with Loser, Neo, etc only with Neo and SFeLi, and previously Alloc. Loser is secretive and unreachable, maybe because he actually wants to preserve that autonomy of his.

Anyway, like I said to Ed, don't expect anything in "Category:AE_roadmap" from me right now. It's much more of a priority to define/design/author specific content for the Trailer. In that respect, the closest thing to a roadmap is a list of needed scenes. Once you take those scenes in, you can try to figure out what they imply for the Edition, or you can just author those scenes blindly, concentrating on the intrinsic awesomeness. I hope to do a brainstorm dump on the AE:Trailer page tonight. Actually, I ought to have done so instead of writing all of the above, but probably those things needed to be said as well. Hope I made myself clear.

geyser 12:12, 30 July 2008 (CEST)

---

geyser, is there a way to get the members from the Russian Oni forum involved with the AE Trailer and other aspects of AE? It seems we need more help with getting the video clips made. Currently, I'm only able to spend a short time on the computer, this shoulder injury makes it painful to work on the computer, so I can't do much. EdT 07:09, 12 August 2008 (CEST)

I've been in contact with the OniMia community all along (actually posting there). The placeholder texture for the DeLorean was made by a fellow Russian (Ricker a.k.a. Iritscen.ru ^_^). There is a good artist (SeverED) who's seriously looking into texturing, and a couple of fluent modders. The problem is that those few fluent modders (who are apparently the only people capable of authoring something awesome or showcasing it in an awesome-looking way), those guys typically can't be told to sit down and "script something awesome", because they work on inspiration, and fail to be inspired by the trailer's "roadmap" for some reason... But heck, since we're all certified procrastinators, it makes sense that people tend to avoid responsibility and tangible results, continually losing focus: just who in the community is concentrating on trailer content right now? No surprises here. Ultimately, the only way to get anyone to "do what's necessary" seems to be for me to nag them into it personally (as in relentless IM or forum spam), and I clearly have only this much time to spend on "coaching" fellow gurus. Perhaps it would help motivate people "spontaneously" if a couple of truly awesome scenes were already edited for or into the trailer draft, setting the tone for scene dynamics, creativity and all that. But the sad truth of all this is that it's unlikely that we'll meet the deadline unless I sit down for a day and record 75% of the required footage myself. That's OK, though, because the editors of the Septagonal Gazette have been uncooperative, and the public awareness of the Edition is still nil.

geyser 12:44, 12 August 2008 (CEST)

I didn't know you hurt your shoulder, Ed. Don't push yourself if it hampers your recovery (not that I need to tell you that!).

I agree that we are not the most focused community in the world, and historically I have certainly been a good example of that lack of focus. My office is only now coming fully online (it's a complicated setup), and as it does I can feel my focus coming to bear on Oni. But hey, actions speak a lot louder than words, right? So I'm going to just do the work and stop talking about it for now. (I've also been off the forums so I can free up more time.) All I wanted to say is that help from the Russians would be welcome. I realize that it can be frustrating to try to get everyone moving in the same direction; that where's the expression "like herding cats" applies.

One more thought before I sign off: I've always felt that strong organization can enable creativity. Artist-types balk at the idea of being held to a rigid process, but in some ways it is actually more productive because the path of the workflow has been cleared for them to travel down. I see two general obstacles to Oni modding right now, and I feel that they are definitely impeding modding work:

Obstacle 1: Editing the binary data and importing it back into Oni to test it. The more OniSplit advances, the lesser this obstacle is, but we know OniSplit needs a GUI. I don't say that to put pressure on anyone who was going to do this task; I feel confident that we will Sooner Or Later™ have a GUI for the Mac and for Windows. I am simply observing that once we have it, modding will be wonderfully enabled.

Also, I still would *love* to see the classic Mac app OniTools written for modern computers. It allowed item-by-item inspection, in place, of the resources in Oni's data files. It wasn't finished because our knowledge of the binary data was lesser back then. A modern version written for OS X (and yeah, I guess for Windows too) would greatly improve the ability of creative types to find what they want to mod and then mod it (now that I know C++, I could probably write the Mac version). If the new OniTools allowed importing and replacement of existing resources, the modding would be even further empowered. So, geyser, let's set that as a general goal in the fairly-near-term for the community. The sooner it's done, the sooner the modding workflow gets a higher bandwidth, if you will.

Obstacle 2: Distributing modded data. Currently, we have the prototype of a kick-butt modding system in the form of the "plug-ins". Once we write some simple software that enables those plug-ins to be swapped in and out (enabled and disabled), and perhaps can read the plug-ins as packages with relevant information, we can greatly aid the dispersal of mods (if you don't know what I mean by "relevant information", think version numbers among other things, which are quite important once modders start fixing bugs and re-releasing their mods; also see this thread for what I wanted to do (this was before the plug-ins were introduced, but the thread is still quite relevant and there's a guy who posted a beta mod manager that I haven't tried out yet)).

I can't be the only one who dislikes manually managing the mods for Oni when they're scattered all over the freaking GameDataFolder. Once we make it easier to use mods, the overall experience will be much more newbie-friendly, which is just what we need if we are going to be attracting people who are new to Oni or at least new to working with modded Oni.

So I rambled on a lot more than I planned, but I wanted to just put down in writing what has been going through my mind for a while now. Now on to Final Cut. --Iritscen 18:10, 12 August 2008 (CEST)

ON Ob. 1: I was working on the GUI for Windows, but my Oni time has been shrinking for several reasons:

1. My stress levels are through the roof

2. My depression levels are also annoyingly high

3. I have no computer. I work off of the one in the living room. Which leads to me being bugged about what I'm doing. Which I don't particularly like to explain. And I don't particularly to install things on this computer, including the software to test the GUI.

4. I have no job, and thus no money to buy a computer.

5. When I do work on Oni related things, I have been working on my laser\rocket thing.

6. Life pretty much sucks right now, and I don't feel like modding.

(also, didnt EdT make a GUI already?)

On Ob. 2: Making an installer for AE and other mods isn't that big of a deal. I can even make it download from the web by itself. Unfortunately, Onisplit can take a while to unpack\repack dat\raw\sep files. So while it can't really be done "on the fly", a mod manager is a relatively easy task to do. I would offer to do it myself, but I still haven't bothered to finish my last GUI project.

Gumby 22:18, 12 August 2008 (CEST)

I made sure to say "I don't say that to put pressure on anyone who was going to do this task" because I knew you might read this and feel more stressed. Gumby, I know what it's like to have poor working conditions when trying to work on a project (in fact, I'm only just now getting to have decent work conditions myself). I don't want you to lose the fun of doing Oni stuff by pushing yourself too hard or feeling nagged, so don't let my words influence you in any way. Also, I think you should be able to rely on others to help with the Windows programming; there ought to be a couple community members, at least, who can pitch in, assuming they have the time.

The reason I said what I said was to reassure geyser (and myself!) that things would come together if we provided the framework for modders, but no one is imposing any do-or-die deadline on us like we're in a professional job, so don't sweat it.

Finally, I just want to say that writing the Mod Manager would first require a group brainstorm as to what features a mod package would need. That was the purpose of my afore-mentioned thread. But all in good time, all in good time.

Iritscen 00:18, 13 August 2008 (CEST)

There's no need to rub it in: things will come together Soon Enough a.k.a. More, Later, Never. A fully functional installation framework is definitely at the top of the list for the first public release of the Edition, which means (like for many other aspects of the project): that I'll do it myself if I have to; that I'd rather be dead than release without it; that if real-life priorities put back the development of that GUI, the Edition will likewise be put back for arbitrarily long. There. Hope that reassures whoever need to be reassured.

As for a GUI similar to Ian's OniTools, it has been around for a while. It's called Neo's OniBrowser. Sure, it needs NET and XNA, but it's there. What that means is that when and if Neo (or whoever) ports the XNA part to OpenGL, OniBrowser will be available on OS X as well. And technically, even now, it could be made available as a "light" build that leaves out the 3D previews and leaves only the XNA-free "explorer" features. It could also receive import functionality and an additional frontend for mod-managing needs.

So there's no need to scheme on anything, let alone to reinvent the wheel. It's all there, open-source and all, just waiting for someone to pimp it up. However, I wouldn't be so sure that there are talents out there, waiting for full-GUI support of COLLADA/XML import for environment and animations and such, and then they'll be all over Oni... Allowing everyone and anyone to mod Oni is just that - empowering the clueless. The lack of a GUI, of all things, is no obstacle to genuine creativity, or at least it shouldn't be.

01:29, 13 August 2008 (CEST)

Well, we've disagreed on that last point before, so I won't get into that again. But at least we're on the same page as far as priorities, so I won't bring it up again at this stage. And I'm glad to hear about OniBrowser; I never got around to trying it in Boot Camp, but clearly I should have. I guess I was aware of what it did, but I didn't think it would be easily port-able to the Mac. Well, we'll find out eventually :-)

Also, you may have misunderstood what I wanted to "scheme" about, which was the Mod Manager. The more forethought we put into the "protocol" for mod packages, the better the system will be. But I'm not going to tell you what to do about it. If you feel like reading through the thread I linked to above, and adding your two and a half cents, feel free. I'll shut up now.

Iritscen 04:55, 13 August 2008 (CEST)

As for OCF, I barely have the courage to read Edition threads now, and I refrain from logging in and posting even when you guys are telling total bullshit about Oni's works. But I've been well aware of Mod Manager since Tosh started working on it, thank you. I've tested it back then and I've even chatted with Tosh on IRC. Now, apart from a few shortcomings due to it being Yet Another Toy Project, Tosh's protocol is so-so, and I clearly intend to put some more "forethought" in the design of the (un)installer and in that of the "packages" themselves. Note that specific "brainstorming" in that respect can only be done by someone who has total awareness of what kind of binary or scripted modifications are typically involved in a mod (i'm talking full-scale mod, not experimental weapon or such). That would be me, and maybe a couple of other fluent modders, like Loser and Loser.ru, and even those guys can only start "scheming" when there are a few typical mods at hand to test our concepts on. At any rate, I won't start thinking about that before the trailer is out: not everybody can pretend to be a multitasking OS. And as for the modding framework empowering creativity - making the GUI foolproof is wishful thinking, and so is writing thorough, dummy-friendly docs about instance management and what may or may not cause Oni to crash. So the way I see it, the GUI will result in troubleshooting hell rather than creative paradise; unless you leave the dummies to themselves and only work with the guys who actually have something to contribute - but you can already have that now... --geyser 11:18, 13 August 2008 (CEST)

Anyway, our disagreement here is formal. There definitely has to be a GUI, even if it's only an emulator of OniSplit's command line. However, anything less generic than a fancy-looking command-line emulator is, IMO, a loss (of generality). Your AE Tools are already limiting the scope of modding dramatically; a mod manager needs to be completely generic. The way I see it (looks like I am thinking of it after all, hope you're happy...), you really don't want to mess with incremental mods, because it'll take you forever to design a system that keeps track of the updates in every situation or implement SVN in a way that won't scare casual modders away even more than the command-line. No incremental mods means that a mod is just a set or assumed prerequisites (that should be tested for availability and integrity), the possibility to rollback any installed/conflicting mod (that's easy as long as they don't interfere), and then for every mod a set of navigation commands, file operations and OniSplit calls. So any mod is little more than a shell script - a sequence of command-line events. All a "mod manager" needs is a solid implementation of that. The possibility of foolproof rollbacks needs a straightforward backup system: every mod should specify what files to modify/create on installation, and what files to restore/delete when the mod is removed. The script interpreter could be custom-built to interpret both Windows and bash scripts, but that's not absolutely necessary. In that sense, the mods are just carefully designed sets of shell scripts, with a metafile listing the prerequisites. --geyser 11:18, 13 August 2008 (CEST)

Yep, that's really all I was suggesting, geyser. (I was not aware of any work by Tosh when I started the thread, just as an FYI.) I do have a couple thoughts that may not have occurred to you, though. I'll tell you what, I'll do a quick dump of my thoughts on this new page: AE:ModManager. You can then work from there to express what you want to see in a Mod Manager. And no, I'm not saying to do it now. Wait until after we have a trailer if you want (I'm putting all my available time into it today. btw). Throwing up this wiki page is easy for me because all my thinking was done before I posted that thread ages ago, and I'm just copying it over to the wiki, so no smart-ass comments about me spending valuable time on this, please.

Iritscen 17:08, 13 August 2008 (CEST)

"Smart-ass" - it takes one to know one, buster. As for the name of the new page, spaces are your friends. I'm afraid that whenever I'm ready to "express what I want to see", I'll be better off just sitting down and coding and testing it, because as long as you're doing pure theory you run the risk of overlooking big-time practical issues (and that even if you're a fluent modder ^_^ ). After a quick look, your stuff looks overly complicated right now, as in "virtually impossible to get right". I think that you don't have to patronize modders (they should be encouraged to thoroughly test their stuff anyway), but if you do, you should disallow "code" completely, leaving the modders with nothing but a do-no-harm metafile and a bunch of resources. Oh, and don't forget about deltas or you'll run into legal issues pretty soon. --geyser 18:53, 13 August 2008 (CEST)

Not that I would promise to make such a Mod Manager until I complete\know I have time to complete the GUI, but a few questions...

1. Are delta patches applied to the .oni files or the .dat files?

2. Would it be preferrable for the manager to read from some sort of a configuration script to see what mods are installed?

3. Would it need to be both Windows and Mac compatible?

4. Is there a version of AE avaliable right now with the mods seperated?

I really hate when I don't have the time to properly make something. I have ideas in my head of how to do this sort of stuff, but I know it would never get done.

Gumby 04:16, 14 August 2008 (CEST)

0. Didn't I mention I didn't want to talk about it or even think of it until the trailer is done? isn't this exactly what I said? well? ^_^

1. It depends. Mostly .oni but some advanced alchemy may require, e.g., recombining stuff between several ONCC, which works best within a temporary .dat

2. I'm not sure what you mean, but every mod's installation folder can hold a trivial flag-file. See, e.g., the way it was done in nikanabo

3. Preferably, and that would indicate either C++/wxWidgets or .NET/mono. As for the latter, no hurry as in Maybe Just Leave It To Neo.

4. No, apart from the separation into 3 globalization steps (1=ONCC/TRBS/TRAC/TRAM; 2=SNDD; 3=TXMB/TXMP/M3GM ) and then step 4 (patches).

4bis. But step0004.bat can easily be split into independent sections: new weapons, dashing hack, modified combat TRAM, modified ONCC...

4ter. The only problem is that, e.g., some ONCC and TRAM hold not a single modification, but accomodate 2 or more separate initiatives.

5. "Uncontrolled lucidity", eh? what do you know, some side effects of using the wiki are actually quite to the point... ^_^

geyser 10:24, 14 August 2008 (CEST)

0. Too bad ^_^ I'm asking now, because I'll forget to ask later. And some future coder (or me -_-) can draw from this

1. Okay

2. Okay

3. Neo has enough to do, don't you think? :P

4. Well, with an actual mod manager, each bat (or section of the bat) will have to be seperated into an installation script (or whatever you choose to call it)

4ter. Well with TRAM hacks and such each mod will just have to list what it contains inside...a listing of what can only be modded once would be nice, but not needed at this point in time :D

4.4. By modded once, I mean modded once automatically. Some things aren't that easy to mod automatically, correct? (I may be wrong here)

5. More like "An invitation to madness" (try to guess where that one came from :D)

Gumby 16:12, 14 August 2008 (CEST)

3. Maybe, but even so, I have a feeling he'll be the only one to supply the right thing, eventually. Feel free to prove me wrong.

5. Heh, that could be a lot of places, from Freud&Co to that comic by Metrokitty...

4.3 and 4.4 - err, that's very confusing and confused, so maybe you should just take that well-deserved break... "LIKE ME!!!" ^_^ (try to guess where that one came from :D)

geyser 17:00, 14 August 2008 (CEST)

Actually, I was thinking along the terms of the anime "MADLAX"...and I am taking a break! I suppose we will just have to burn cross those bridges when we come to them.

Gumby 18:30, 14 August 2008 (CEST)

---

Maybe I'm just stupid, but I downloaded the version of OniMenu from your site, under the Tools folder in the OTA folder. I need to find flags to use for some scripting I need to do to record some video. Urg. Anyway, I successfully used a past version (also labeled 3.0, strangely, but with fewer .bsl files), and I thought that I could put the OniMenu scripts in the global folder, add "func pre" to the main function for each level, and do the reverse-flipping kick and the menu would come up. Has something changed? Also, I may be blind, but I searched the forum and didn't see any recent threads devoted to explaining how to use it, and this wiki has no documentation for OM either.

What's happening when I insert "func pre" is that the level fails to load past the point of that code. I also tried putting the OM scripts right in the "compound" folder (the level I want to browse) but no luck. No enemies, nothing goin' on. I'm probably making a simple mistake but I'm out of ideas. --Iritscen 02:39, 24 August 2008 (CEST)

What I do is run Oni in window mode, then look at the flags listed on the pages found here: http://zdlo.oni2.net/Items/Flags/ and then use chr_teleport 0 flag# to find locations I could use. EdT 03:54, 24 August 2008 (CEST)

Okay, I guess I'll take that approach, although I'd like to find out at some point what I did wrong with OM. Thanks, Ed. --Iritscen 04:46, 24 August 2008 (CEST)

Apart from the global folder not working on the Mac, there should be no problem. If in doubt, provide a snapshot of your IGMD folder. Also consider using the PC version, for which you can use THIS. More generally, I'm looking forward to some follow-up to THIS, and I'm curious why you're not using the PC version for recording. --geyser 11:40, 24 August 2008 (CEST)

Lately I've been browsing flags in a simplified manner, by repeatedly entering "my_flag= my_flag+1; chr_teleport(my_flag); chr_facetoflag(my_flag);" from the console and occasionally setting my_flag explicitly (when there are large gaps between flag IDs). Of course during this process I keep an eye on the lists found HERE or HERE. --geyser 11:40, 24 August 2008 (CEST)

Has anyone considered making an OniMenu-type script that actually lists a level's flags with descriptions of their locations in the level? You could drill down the menus, maybe starting with choosing what level's flags to look at if there's no way to find out the current level through BSL, then in a submenu choose the area of the level to go to, then choose the specific spot. In other words, scriptifying ZDLO's flag tables. It seems like a fair amount of work, but it would be easy work, mostly copying and pasting BSL code (wow, that guy in the Bungie West tour video was right, programming is cutting and pasting!; what was his name?).

Re: running Windows Oni, I anticipated having to do that to capture some of the modding work sooner or later, but nothing so far has required doing so; the fact that certain mods, like OTA, are more functional on PC really doesn't matter when all I'm showing in the trailer is a few seconds of mayhem. However, you have pointed out that I completely flaked out and never made a response on the PC Oni on Mac page. My bad, I'll fix that in just a little bit. --Iritscen 16:35, 24 August 2008 (CEST)

choosing what level's flags to look at if there's no way to find out the current level through BSL You're forgetting that the global folder doesn't work on the Mac, and so the menu you suggest would have to be level-folder-resident anyway. and even if it had a global component, flag-related information would just go in level-specific BSL files: the global core wouldn't "detect" the level, it would just load the currently relevant level-specific script (see THIS for an example). --geyser 01:37, 25 August 2008 (CEST)

I suppose your method would work fine. But I wasn't forgetting (this time) that the Mac couldn't do global scripts, I was actually imagining that one monster script would cover all 14 level files' flags, and that single script could get put in each level's folder so the user wouldn't have to worry about matching up a script to each level as part of some 15 folder-spanning network of BSL (plus it makes more work if there's a 1.1 release and they have to replace a 1.0 core script and then all the level-specific scripts (in case the 1.1 core doesn't support the 1.0 level scripts)). It's just more efficient that way. --Iritscen 04:42, 25 August 2008 (CEST)

I was actually imagining that one monster script would cover all 14 level files' flags That would have a chance of overloading the BSL engine, which can only load this much logic at a time. I wouldn't know about the "efficiency" of a moster script, and I'm not sure what the file-buffer limits of BSL are, but it's typically more sound to provide only the logic relevant to the current level. As the designer of OTA, I know what I'm talking about ^_^ --geyser 15:26, 25 August 2008 (CEST)

In other words, scriptifying ZDLO's flag tables. SHORT ATTENTION SPAN ALERT! Didn't I link to THIS above? It actually works on the Mac, except you're not able to read the healthboxes. You can easily make a version where you can review the IDs of the group of flags being shown and cycle through them. --geyser 01:37, 25 August 2008 (CEST)

MISSING MY POINT ALERT. I am now using ZDLO's tables in the way that Ed suggested, but it would be even cooler to meld his grouped, descriptive approach with your OniMenu system so it's all in-game and you can try each flag out by teleporting there. That's what I was saying. Right now OM makes you use an outside flag-number reference and you have to laboriously type in flag numbers by punching and kicking, so my idea is a landmark improvement for modders. That being said, how many people would be using such a script? So I'm not suggesting anyone jump on it. Just thinking out loud (I know you love it when I do that).

P.S.: Healthboxes? What healthboxes? --Iritscen 04:30, 25 August 2008 (CEST)

It seems like a fair amount of work, but it would be easy work, mostly copying and pasting BSL code. That'll be a "no comment" for me. Same for the words of wisdom about the essence of programming... --geyser 01:37, 25 August 2008 (CEST)

I think if anyone ever asks me, "Does geyser have a sense of humor?", I'll use the same response: "No comment." --Iritscen 04:30, 25 August 2008 (CEST)

I am now using ZDLO's tables in the way that Ed suggested You're the one who missed my point. I've been telling you that ZDLO not only wrote up the tables mentioned by Ed, but also came up with a series of menu-like scripts (hosted HERE). Those scripts have a new core tailored for the job, much lighter than OniMenu: a level's flags are displayed one group at a time, roughly following the groups established by ZDLO himself. By design, you don't even have to teleport anywhere, because all the information (every flag's location, facing and ID) is displayed by means of dummy characters: you just walk around and see the info. "Healthboxes? What healthboxes?" - precisely. The ID of the flags is displayed as the health of the dummy characters - this is enabled by ai2_showhealth=1 and takes the form of black text in a white box above every character's head (there is also a health bar extending upwards by 1 world unit for every hitpoint). The only problem is that on the Mac the health box above the characters isn't displayed, so you can not read a flag's ID directly. One workaround is to complement ZDLO's scripts with a mini-flag-browser that works within the currently displayed group of flags. A simpler solution is to list the IDs of the current group of flags, so that the user can explore them with chr_teleport. Finally, someone who can see the healthboxes can take a few screenshots and post them somewhere, as a complement to ZDLO's tables. Along with or instead of ZDLO's scripts, you can also use Neo's OniBrowser, which displays stuff like FLAG or TRGV right in the 3D view of a level. --geyser 15:26, 25 August 2008 (CEST)

how many people would be using such a script? The main point here is that developing such GUI-like tools (the term you use is "landmark improvement for modders") amounts to empowering lamers. A fluent modder typically won't limit himself to the range of flags (or other OBJC) available in the original levels. And if that modder does want to review some original flags, then the available lists, tables and browsers allow him to do so efficiently enough. In that sense, ZDLO's set of flag viewers are a gadget that may seem nifty to the lazy and clueless, but are definitely not a revolution for those who can actually use the knowledge to create great mods - those people know better than to ask or wait for point-and-click nicicles. If anything, they've been using OniBrowser to review that kind of stuff for the past few months... --geyser 15:26, 25 August 2008 (CEST)

Okay, I was totally ignorant of ZDLO's flag browser, so thank you for explaining it. I also didn't realize that PCs could display text above character's heads, but it sure explains this.

Also, you might be interested to know that I figured out why we disagree on the basic idea of making user-friendly modding tools; it came to me in a flash of insight. I'm a Mac and you're a PC. The guiding principle behind the Macintosh was that if you provided a well-designed GUI, creative people could be more creative. It would empower them. For years, even after Windows was released, there were DOS stalwarts who insisted that it was better to have to do the hard work from the command line than to have 'frivolous' things like mice and windows. Even though no one still adheres to the command-line-is-better school of thought, that way of thinking has a hold on many of the technically-smart Windows users to this day. Once a person switches to Mac, they realize that making basic UI tasks intuitive, and making multimedia work easier encourages the user to actually be creative. There's no need to pull oneself over a technical hurdle like, say, using OniSplit from the command line (and oddly enough, you seem to support the idea of a GUI for OniSplit) in order to get things done so it's easier to let your initial enthusiasm carry over instead of getting mired in stuff that should be behind the scenes. A recent exchange from the forum (names have been changed to protect the innocent):

OniVirgin: I think I should add some new moves to Yosemite Sam because he doesn't have as many moves as other characters.

Burt: OniVirgin: You might be interested in this page: http://wiki.oni2.net/OBD_talk:TRAM.

OniVirgin: That page looks useful. But... my new semester is coming and I must focus on my study. Maybe other time I can modify it...

What happened here? Our new and enthusiastic modder is thrown off by having to absorb 10 screenfuls of technical stuff that's not in his native language (and really, who does speak hex fluently? ;-). Now, imagine if we had a visual 3D TRAM editor, or even a GUI for OniSplit that basically said, "What parts of the TRAM do you want to focus on?" and there was a pulldown menu for "knockback", "damage-dealing bones", etc. and it would highlight those in the actual Oni binary data for an animation, and they could type a new decimal value in for damage, or pick a new bone from a popup menu, and the GUI would convert it to hex. That's just a random example of the philosophy of "enabling creativity through user-friendliness", and it's essential to the mindset of anyone who loves Macs. --Iritscen 17:31, 25 August 2008 (CEST)

Iritscen, love_Oni is not a fool: http://oni.bungie.org/community/forum/viewtopic.php?pid=9103#p9103. He may not be the best modder out there (like anyone is just starting out), but he is not an "OniVirgin" who is put off by a hex editor. At one point or another most of the modding community is "Busy" for one reason or another with real life.

1. Do you know how much of a pain in the arse it is to create a good GUI?
2. Is it really worth it to spend the time required to make such a GUI? There aren't even a dozen modders at this point, and most of them are at the point where they don't need a GUI (Unless you count OUP as a GUI, but it is really only a glorified hex editor). Would the time spent on creating a superb GUI be more than the time that it would save for the people who use the GUI?
3. Running Onisplit is not a "technical hurdle". "Onisplit.exe -import:nosep *copy* *paste* *copy* *paste*". There, I'm done. If I need to do the same action again, I can just hit the up arrow. In the end, I think hex editing through OUP and doing things the "hard way" actually enables more creativity. You learn exactly how things work out. If I need to make a small change, it takes me about 20 seconds to open up OUP and do it. If I need to make a large change, I can export the file to .xml through Onisplit and do changes there. For many things, the level recombining (level0) is the longest part. A GUI would not speed that up!!
4. Back on topic: What kind of GUI would you create for a simple flag browser anyways?! What we have seems about as good as it is going to get. (And you can run the Windows version through Bootcamp anyways. Why aren't you?) Gumby 18:55, 25 August 2008 (CEST)