User talk:Iritscen: Difference between revisions

From OniGalore
Jump to navigation Jump to search
(→‎General Editing Talk: --> General Talk so we can chat here)
m (+cat)
 
(96 intermediate revisions by 12 users not shown)
Line 1: Line 1:
__TOC__
'''Talk page archives''': [[/Archive1|#1]] (2008); [[/Archive2|#2]] (2009-2014)


==Hacking Multiplayer==
==Re: Banner==
'''Who here was involved with that effort to hack multiplayer into Oni?'''
:Memory search: Alloc, Kumo, typhen (leader) and me.
:Programs: typhen (Onyx/OnyxPatcher), neonew (OniHook)


'''How was the multiplayer actually supposed to get implemented into Oni?'''
Hey,
:Overwrite the memory at runtime.


'''How much was accomplished?'''
haha yes, I'm sorry for that. The banner was located on my installation CD and actually, this is the installer splashscreen: [https://i.imgur.com/xti8qZC.png Click] --[[User:Noneatme|Noneatme]]
:Some memory findings (pointers, player/enemy values, ...). (All?) results are stored [http://oniplayer.oni2.net/contents/whatsdone/found_stuff.php here] (Used program: [http://en.wikipedia.org/wiki/Tsearch TSearch]).


'''What were the obstacles?'''
:Hehe, I feel somehow cheated that these levels never made it into the final game. The jewel case image you mentioned also gave me cancer and aids so I scanned the case for myself. Here is the [https://i.imgur.com/efLP43w.jpg back], [https://i.imgur.com/aUhqU3I.jpg CD], [https://i.imgur.com/JGf5AgJ.jpg inner part] and [https://i.imgur.com/NGwIbni.jpg front]. Also, the german sounds and voice lines are also well made and we have some translated textures like STAIRS at the warehouse level. And I also found some unused textures in some levels. --[[User:Noneatme|Noneatme]] ([[User talk:Noneatme|talk]]) 17:49, 29 July 2015 (CEST)
:Working in the memory in general
:Find the pointers (because the pointer position varies from OS to OS and from level to level).
:Time (as usual).
----
typhen stopped his efforts on the project in August of 2005 for real life (girlfriend).
:[[User:Ssg|Ssg]] 00:25, 15 February 2008 (CET)
:Kumo contributed some pseudonetcode in C++ that was supposed to interface with Onyx.
:Alloc's OniTrainer implemented most of the gathered knowledge as the project went.
:(OniTrainer had no network component, but it was a good tool for experimentation.)
:The problem with TSearching was with all the big dynamically allocated structures.
:It was a rather crazy idea to figure out those structures without disassembling...
:I think the project started in April/May 2005, so it spanned the summer of 2005.
:neonew's OniHook was totally independent of Onyx, so it's another project, sorta.
:I'm not sure whether neonew disassembled Oni's engine in order to do the hooking.
:A fair amount of Oni's engine has been disassembled since, by both SFeLi and Neo.
:The structures responsible for the "game state" and "character state" are known.
::[[User:Geyser|geyser]] 02:04, 15 February 2008 (CET)
----
Some history:


typhen came up with the project in December of 2004. The first steps in the memory were made with RAMCheat. In January of 2005 typhen found the (great) program TSearch and the real memory search began. In April of 2005 geyser joined the Oni community and two or three weeks later the Ikonboard-based Oni forum crashed. (Because of too many verbose postings by him. :p *just kidding* ;-)
==Annoying sidebar on smartphone==
When I browse the wiki with my Samsung/Android phone the side bar takes a good portion of the screen especially if you try to zoom in.


Unfortunately Harry never made this forum available as an archive.
It would be nice if that would hide when you scroll down and show when scroll up. --[[User:Paradox-01|paradox-01]] ([[User talk:Paradox-01|talk]]) 19:46, 23 August 2015 (CEST)
:[[User:Ssg|Ssg]] 11:57, 15 February 2008 (CET)
:The crash in April 2005 ''was'' supposedly due to me posting over a bad connection, which corrupted the database.
:My impression is that the actual project started in May 2005 and thus is largely covered on the after-crash forum.
:That's where you can see typhen and Kumo exchanging pseudonetcode, typhen and me talking about sync philosophy...
::[[User:Geyser|geyser]] 12:22, 15 February 2008 (CET)
----
Thanks for the info, guys. And sorry for being something of a jerk yesterday, geyser. Now, you said that the structures for game state and character state are now known -- are you referring to runtime variables? I don't see where those are documented in the wiki, unless [[OBD:ONCC|this sort of page]] covers that information. Is that whole structure just loaded into memory to be worked with at runtime, and do we know where in memory to look for it, or is that where the process became difficult, due to that whole "dynamically allocated" structure that you mentioned? --[[User:Iritscen|Iritscen]] 16:42, 15 February 2008 (CET)


:"And sorry for being something of a jerk yesterday, geyser." Sigh. I just don't understand why you avoid gathering first-hand knowledge.
:When you are ready to test this on your phone, try commenting out the "div#mw-panel" modification on [[MediaWiki:Vector.css]], then see how things look on your phone. I'm not sure if this is a mobile-friendliness issue with MediaWiki 1.19, but I'm thinking it's probably the fixed sidebar CSS that's the issue. --[[User:Iritscen|Iritscen]] ([[User talk:Iritscen|talk]]) 23:16, 23 August 2015 (CEST)
:Since you have that much free time, why not ''really'' come to terms with the object you want to provide accurate documentation for? Sigh.
:I must say you still post and edit a wee bit too compulsively (a hyperactive kind of hyperdedication), and with not enough second sight.
:Sure, the wiki needs regular editors, but you pretty much "jumped on it like an oversexed hippo" (C) Bungie. Hope it'll wear off somehow.
:^_^
:The disassembled engine is only documented in private databases, and we do not plan to publish those in any foreseeable future.
:The "game state" is a huge chunk of data holding various runtime variables and structured objects (other, big chunks of data).
:In particular, the game state structure holds a dynamically allocated array of character objects, each with a character state.
:The character state holds various runtime variables specific to a given character, much more than the static game content.
:Dynamical allocation means that the space required for the structures is not part of the EXE; it's requested at runtime.
:Depending on the history prior to the allocation, the dynamically allocated space may end up at a different location.
:The ONCC has little to do with "character state". In fact, the character state holds a mere link to the current ONCC.
::[[User:Geyser|geyser]] 15:43, 16 February 2008 (CET)


==General Talk==
Couldn't edit the page you linked to so I took that equivalent at my place. Also cleared the browser cache but didn't work. Then I tried Google Chrome while I wasn't even logged in and it looks normal. Whatever the bug(?) is, at least I know now I could use chrome when surfing with a small-screened device. --[[User:Paradox-01|paradox-01]] ([[User talk:Paradox-01|talk]]) 21:27, 24 August 2015 (CEST)
;Chapters and added value
:Flipping through the stuff as I updated the page layout, I was really impressed with the quality of some of the "added value".
:Keep up the good work, dude. I'm sure the chapter pages will grow (just a little bit) to be brilliant appetizers for all the rest.
::[[User:Geyser|geyser]] 03:38, 18 February 2008 (CET)


"I'm sure the chapter pages will grow (just a little bit) to be brilliant appetizers for all the rest."
:Ah, well that's good. Sorry, I didn't realize the main Vector.css page wasn't freely editable. But keep in mind that your user Vector.css page stacks on top of the main Vector.css, so when you comment out that CSS on your user page, it simply means that the main Vector.css is still used for mw-panel. You would have to re-declare mw-panel on your user page with its original properties in order to get rid of the anchored sidebar mod. Let me know if you want help with that. --[[User:Iritscen|Iritscen]] ([[User talk:Iritscen|talk]]) 21:44, 24 August 2015 (CEST)
That's what I'm hoping; I just spouted some random stuff off the top of my head as I made each chapter's Added Value section, so there's plenty of room for corrections/additional insights. --[[User:Iritscen|Iritscen]] 15:48, 19 February 2008 (CET)


----
Yes please. I couldn't figure out the right defaults. --[[User:Paradox-01|paradox-01]] ([[User talk:Paradox-01|talk]]) 22:40, 24 August 2015 (CEST)
Here's an interesting article: Starbucks offers 2 hours free wifi each day. http://www.usatoday.com/money/industries/food/2008-06-02-starbucks-wifi_N.htm


Also, this site may help: http://www.wififreespot.com/
:It seems like you only need to change "position" back to "absolute", which is the default, but that's just one of the changes made to the panel in Vector.css, so let me know how it works on your phone. --[[User:Iritscen|Iritscen]] ([[User talk:Iritscen|talk]]) 23:31, 24 August 2015 (CEST)


So now you have no excuse for not hanging out at the OCF and the wiki, during your move  :-)
Okay thanks. With your code it works now on the phone. --[[User:Paradox-01|paradox-01]] ([[User talk:Paradox-01|talk]]) 08:38, 25 August 2015 (CEST)


Sorry, I didn't know where else to put this, the Blender thread was getting long.
==Red links - weapon pages==
There's no talk page for [[Special:WantedPages]] so I will my question here: Why do we need extra pages for Plasma Rifle, Super Ball Gun, Black Adder, Plasma Rifle, Screaming Cannon, Wave Motion Cannon?


[[User:EdT|EdT]] 00:25, 4 June 2008 (CEST)
There's this [[Quotes/Weapons]] and IMO there's not more to say about them. Let's delete the red links? --[[User:Paradox-01|paradox-01]] ([[User talk:Paradox-01|talk]]) 20:51, 24 November 2015 (CET)


Aw, Ed... I kinda ''liked'' the idea of Iritscen taking up iPod therapy ^_^ --[[User:Geyser|geyser]] 12:56, 4 June 2008 (CEST)
:There's also [[Gameplay]], for some brief weapon tips. Here's the thing, though. [[Mercury Bow]] is already an article. Why should the M Bow get an article and not the other weapons? In fact, I would say that most of the red links highlighted at the top of "Wanted pages" are equally minor. While there may not be a lot to say about them, they deserve at least a short page, I think. --[[User:Iritscen|Iritscen]] ([[User talk:Iritscen|talk]]) 04:22, 25 November 2015 (CET)


It's as geyser says, being restricted to my little iPod keyboard will do wonders for my verbosity. Suddenly I'll have to get right to the point and not write rambling diatribes. Seriously, I will probably take my laptop down to the library once in a while to use their free wi-fi (more of a library person than a Starbucks person; I don't even drink coffee). But I'm kinda lazy and rarely feel like unhooking my 'Book from all my stuff and schlepping it downtown. My iPod can get wi-fi right in my backyard, so I'll probably use that most of the time. --[[User:Iritscen|Iritscen]] 15:25, 4 June 2008 (CEST)
==Wrong pseudo code==


==Importing from Blender==
Hi Iritscen thanks for fixing my wording.  
'''''This is the place where EdT tells me what was wrong with that Griffin model I gave him.''''' :-) What did you have to do to get it imported? (I know you already told me some of this, but let's state it here to lay the groundwork for the discussion.)
:--[[User:Iritscen|Iritscen]] 15:59, 2 June 2008 (CEST)


::General note 1: please provide links to every file you "cite" as an example, because "I extracted Motoko from the files you posted" or "geyser's earlier copy had triangles connected" just isn't informative enough. "Help us help you help us all."
I have just noticed a small error.
::General note 2: please stop guessing and start looking for systematic ways of investigating problems, because stuff like
:::"Its hard to say where the problem is, it could be Cheetah3D or it could be FBXConverter. All I know, is that the model's triangles are disconnected once I have it in Cheetah3D"
::and
:::"Hmm, I guess Blender's exported DAE might have had a problem that Cheetah only noticed upon exporting; that almost sounds more like a Cheetah problem, though. Maybe it's both program's faults, technically."
::is just not good for you.
:::[[User:Geyser|geyser]] 07:01, 3 June 2008 (CEST)
::::geyser, geyser, geyser. Although I didn't strictly label it as such, this was really going to be a discussion between Ed and myself (see ''my'' bold italics). The reason I didn't send you the files I was working with was so that I could focus on problem-solving. So when I used terms like "geyser's earlier copy", Ed knew exactly what I meant, because this dialogue was picking up from PMs we were exchanging. Now you've come in here telling us how to talk about stuff, and the page is all gummed up. I'm the one who should be "meta-sighing" here. I have little time for these games, as this is my last week on the Net for the next month, I barely have any time this week at all, and *all* I want to know is how to get my own models into Oni. Your comments so far are largely distracting from our efforts. --[[User:Iritscen|Iritscen]] 16:02, 3 June 2008 (CEST)
:::::This discussion is a public follow-up to your PM exchange, and if you mean to lay a solid groundwork for it, no detail is superfluous ''even'' if you're only talking to Ed. Precision is what enables expert troubleshooting and saves everybody's precious time. --[[User:Geyser|geyser]] 17:31, 3 June 2008 (CEST)


Where do I start? :-)
The following code:


Here's the basic workflow I use for Blender:
for (int i = 0; i < 50; i++)
:Export from Oni using AE Tools, option for Blender.
  {
:Import into Blender, using Collada 1.4
  print("Is this annoying yet?");
:The 3D model will appear in a standing position. Do not change the rotation or position of the body parts.
  wait(20);
::Interesting. Griffin was always standing up, but when I extracted Motoko from the files you posted, and brought her into Blender, she had her legs behind her head! (Get your mind out of the gutter!) All her limbs were pointing up above her head. Have you seen that happen? What does that indicate? --[[User:Iritscen|Iritscen]] 21:08, 2 June 2008 (CEST)
}
:::That's how the body looks like when the rotation of all the body parts is set to 0 on the x,y,z axis, also this is known as the default orientation. I believe that when a body part is selected and you type "n" a window appears showing the properties such as position, scale, rotation. [[User:EdT|EdT]]
:::For further reference, see [[TRTA|HERE]] and [[OBD:TRAM/raw0x34#Origin_and_direction_of_the_angles|HERE]]. --[[User:Geyser|geyser]] 07:01, 3 June 2008 (CEST)
::::Okay, I thought that might be what zero rotation looks like. Now, are you saying that if a model imports like that, I shouldn't rotate the parts to more normal angles? Because I did that for Motoko. Did that cause a problem when you went to import her into Oni? --[[User:Iritscen|Iritscen]] 22:06, 2 June 2008 (CEST)
:::::Yes, so I just copied the head from your files and pasted into my original one. Also, the head's center point was off, so I had to correct it. [[User:EdT|EdT]]
:::::Actually, everything but Griffin's head is untouched ''and 100% correct'', so you can work with Iritscen's file, without pasting the head elsewhere. [[User:Geyser|geyser]] 07:01, 3 June 2008 (CEST)
::::::geyser... you're looking at Ed's fixed version, aren't you? I refused to link to mine because it was so messed up. If the copy you're looking at has correct part names, then ''it's not the copy I was working with''. It would be a waste of time to examine that model and fix every problem when Neo has already fixed the export bugs and newly-made exports are fine. --[[User:Iritscen|Iritscen]] 16:02, 3 June 2008 (CEST)
:::::::No, I'm looking at [http://www.sendspace.com/file/rl6zre THIS] one. As far as I can tell it's the exact same "flawed" version as you gave to Ed, and apart from the head name/hierarchy/placement (and the head mesh per se) there's nothing wrong with that model. Oh, and I still don't like how you blame OniSplit (version number?) for abstract bugs. --[[User:Geyser|geyser]] 17:31, 3 June 2008 (CEST)
::::::::Whoops, I forgot Ed linked to my uploaded flawed model. See below for my answer on the "abstract bug" part. --[[User:Iritscen|Iritscen]] 19:00, 3 June 2008 (CEST)
:Make the changes.
:Export from Blender, Collada 1.4, options: triangles, disable physics, current scene. (I'm doing this from memory, I do not have access to Blender at work. will correct if necessary)
:Import to Oni, using AE Tools.


Things to remember:
found here:
:Each body part has a center point, when exporting from Oni as Collada, these center points are at the correct location.  However, if new parts are added, then the center point must be set. To set the center point, position the cursor at the correct location on the body part, you will need to adjust it on all 3 axis. Then go to the menu Object: Transform: Set to cursor. (from memory)
[[BSL:Manual#schedule_..._repeat_..._every_...]]
:When replacing a body part, its important that its rotation matches the original part.  Also, the name must be exactly as the one replaced. Finally, the parent/child relationship must be re-established.
::''The notion of rotation matching is a bit fuzzy here, there, and everywhere. You're not making it clear what to do about rotations that don't match. --[[User:Geyser|geyser]] 07:01, 3 June 2008 (CEST)
What went wrong with Griffin?
:It appears there is an additional object connected to the new head, which needs to be deleted.  The new head needs to be named correctly, it needs to be attached to the neck (parent/child). Finally the scale/rotation needs to match the previous head.
::I did in fact forget to establish a link to the new head (I realized after I had sent it to you). I will have to examine the issue of scale/rotation to make sure it is set properly in Griffin, I don't know that part of the program yet. I can probably figure that out. --[[User:Iritscen|Iritscen]] 21:08, 2 June 2008 (CEST)
:::The scaling is fine. As for the rotation, the head is supposed to be aligned with the neck. So the only things that need to be done (apart from deleting the garbage object) are as follows: rename to "head"; reparent to "neck"; move/rotate into place; set center from cursor; "Object|Clear/Apply|Apply Scale/Rotation to ObData". --[[User:Geyser|geyser]] 07:01, 3 June 2008 (CEST)
::::See, this is genuinely helpful. Thank you. --[[User:Iritscen|Iritscen]] 16:02, 3 June 2008 (CEST)
:::::My pleasure, but it's ''not'' helpful until you acknowledge that it actually fixes the Griffin you've been working with, in-place. --[[User:Geyser|geyser]] 17:31, 3 June 2008 (CEST)
:Perhaps, since I was working with the .dae version, and not the original Blender file, I was not able to export to Collada, it kept failing on me. Not sure why...
::Afraid you lost me here. DAE *is* Collada, but you said you couldn't export it to Collada.... --[[User:Iritscen|Iritscen]] 21:08, 2 June 2008 (CEST)
:::All I know is that after importing your .dae file, I could not export it out as .dae. [[User:EdT|EdT]]
::::Hmm, I guess Blender's exported DAE might have had a problem that Cheetah only noticed upon exporting; that almost sounds more like a Cheetah problem, though. Maybe it's both program's faults, technically. Well, in the future I will send you the .blend file if I need help, but hopefully I can make my own imports from now on. --[[User:Iritscen|Iritscen]] 22:06, 2 June 2008 (CEST)
:::::Actually, the exporting error came from Blender itself, you can try it yourself.  Import the .dae file you sent me into Blender, now try to export that file as Collada. [[User:EdT|EdT]]
::::::Just to clear things up: Iritscen, Ed's DAE->DAE problem has ''nothing'' to do with Cheetah3D. He's just importing your .dae into Blender and trying to export it as .dae from Blender afterwards. I'm not sure why he's having trouble doing so, because for me that same operation works fine.
::::::Still, I'd have a piece of advice as for exporting COLLADA from Blender: disable physics, use ''relative'' texture paths, ''and'' export selection only (select all body parts before exporting). The latter is to avoid accumulating layers of irrelevant and confusing metadata in the COLLADA file format.
:::::::[[User:Geyser|geyser]] 07:01, 3 June 2008 (CEST)
::::::::I have yet to try to import my exported .dae back into Blender and export it again, so I can't say yet if it will work for me. But I will follow geyser's advice about exporting from now on. The point about selecting all body parts and only exporting the selection, in particular, may be key to avoiding future problems. --[[User:Iritscen|Iritscen]] 16:02, 3 June 2008 (CEST)
:::::::::Well, DAEs exported with scene metadata are annoying more than anything else. It will justs end up as nested scenes when and if you import and reexport the DAE again, but it doesn't screw up the model in any way. For one thing, [http://www.sendspace.com/file/rl6zre THIS] includes scene data and I can work with it just fine.
:::::::::Please note your misunderstanding of Ed's DAE->DAE problem as an example of a situation where early disambiguation wouldn't have hurt. Just because you and Ed have been talking about Blender and HD Griffin in private doesn't make you able to read each other's minds. --[[User:Geyser|geyser]] 17:31, 3 June 2008 (CEST)
::::::::::I know what you're talking about when you say the scene metadata is annoying, I tried to read the file once with the naked eye, and got pretty ticked off trying to make heads or tails out of all the nesting.
::::::::::As regards my little misunderstanding about Ed's DAE->DAE problem, that was easily corrected by a short exchange between us. Even being as vague as you seem to think we are, we actually haven't wasted any real time due to misunderstandings so far. So we can at least read each others' minds enough that we don't have to spell out everything letter by letter. It's your mind I have trouble reading, geyser ^_^ --[[User:Iritscen|Iritscen]] 19:00, 3 June 2008 (CEST)
:What did I do? I used Cheetah3D.  I exported ONCCgriffin_generic as Collada, used FBXConverter to convert the file to .fbx.  I also converted your new model to .fbx.  I then copied the new griffin head to the griffin_generic fbx file, replaced the original head, set the correct rotation and parent/child relationship. Exported it out as .fbx, converted it to .dae using FBXConverter, then imported into Oni.  Also, regarding the triangles not being connected in my model, I did not Optimize the model in Cheetah3D before exporting.


[[User:EdT|EdT]] 20:51, 2 June 2008 (CEST)
is not correct. It is not equivalent to (at least if you change the variables, let say 50 to -1) in
::When you say you did not optimize the model... was that supposed to connect the triangles? Does Cheetah otherwise disconnect the triangles? That would be very odd. --[[User:Iritscen|Iritscen]] 21:08, 2 June 2008 (CEST)
schedule dprint("Is this annoying yet?") repeat 50 every 20;
:::Optimize in Cheetah3D connects the triangles, and a couple of others things, I don't remember right now. [[User:EdT|EdT]]
::::See, I just don't get that, because geyser's earlier copy had triangles connected. It concerns me that Cheetah would disconnect the triangles unless you specifically tell it not to. When you're working with the file in Cheetah, are the triangles already disconnected, or is that only happening when it exports? --[[User:Iritscen|Iritscen]] 22:06, 2 June 2008 (CEST)
:::::What can I say? I didn't know there was a problem, until you pointed it out. Its hard to say where the problem is, it could be Cheetah3D or it could be FBXConverter.  All I know, is that the model's triangles are disconnected once I have it in Cheetah3D [[User:EdT|EdT]]
::::::You could shed some light on this mystery by uploading the FBX file output by FBXConverter. --[[User:Geyser|geyser]] 07:01, 3 June 2008 (CEST)
::::::Yes, EdT, this may be helpful. --[[User:Iritscen|Iritscen]] 16:02, 3 June 2008 (CEST)
:'''it's important that its rotation matches the original part''' Conceptually, this has to do with the "center point": you have to define not only a position for it, but also a rotation, and thinking of it as a "point" can be misleading. I have no idea how Blender handles this exactly, but I'd be surprised if it was working with ill-defined frames of reference. Therefore the "center point" mentioned by Ed ''must'' have an adjustable orientation property.
::Hmm, not sure I get this, but do I need to get it? As long as I alter polys and don't add new parts (which, yes, I did do for Griffin, but only to get his new head on the old body that was un-importable), do I need to worry about center points and rotations? As long as I don't change either of those? --[[User:Iritscen|Iritscen]] 21:08, 2 June 2008 (CEST)
:::That is correct [[User:EdT|EdT]]
:::'''do I need to get it?''' That's entirely up to you. Stuff like "bastardizing" can indeed be done without "worrying about center points and rotations". But without a solid notion of the "reference frames" (a.k.a. "systems of coordinates") involved, a major screw-up is only a matter of time. --[[User:Geyser|geyser]] 07:01, 3 June 2008 (CEST)
:::'''only to get his new head on the old body that was un-importable''' Er? I'm confused again: what old body are we talking about, how was it un-importable, and how does this all fit in with you eventually combining that supposedly un-importable body with the new head? --[[User:Geyser|geyser]] 07:01, 3 June 2008 (CEST)
::::Just to explain this once and for all: I exported Griffin. Months ago. OniSplit was still buggy in the area of exporting at the time. Stuff was messed up in the model, but that would only become known later. It wasn't anything that I could notice while working on it. Eventually I realized, from seeing Ed's bug reports on Neo's talk page, that my model was going to be trouble. So, last week, I used OniSplit 0.9.14 to export Griffin, and appended my old file with the HD head onto the imported new export. I deleted the head in the new export and put the HD head into place (but forgot to parent it). --[[User:Iritscen|Iritscen]] 16:02, 3 June 2008 (CEST)
:::::That explains a lot, but the information is still incomplete without the version number of the OniSplit you used "months ago" and the way in which "stuff was messed up". Are we even talking about COLLADA? Didn't you start working on a Griffin imported from OBJ, before OniSplit even started supporting COLLADA? It may look like a detail to you, but it's very important that you remember. --[[User:Geyser|geyser]] 17:31, 3 June 2008 (CEST)
::::::I don't have an exact record of what version of OniSplit was used to export Griffin, or what month it was done in, but it was probably the end of March. And yes, I did in fact export Griffin as OBJ before the Collada support came along. The model on my sendspace account is in fact that model (imported to, and worked with in, Blender, then exported to DAE). Now, as far as the exact 'stuff that was messed up', all I can say is that I was reading Neo's talk page (which was completely different at the time), and my eyes were glazing over, because I had not delved into the technicalities and a lot of the exchange between EdT and Neo was like Greek to me, but I do remember reading about incorrect part names. I can no longer find that discussion in his page or any version of it in the past, but Ed can back me up on this, that he noticed that there were parts with names like "right right" instead of "calf right", etc. I believe there were other issues aside from naming, but I also felt that, even if I didn't know what the problems were, they were out there, lurking, and it was best to paste the HD head onto a new export. So, because I refused to let the old model's export problems trip me up (and yes, OniSplit was buggy, Neo will admit that), I never determined ''exactly'' what those problems would have been. --[[User:Iritscen|Iritscen]] 19:00, 3 June 2008 (CEST)
:'''What went wrong with Griffin?''' If that's of any help, you can let ''me'' (or Neo) try and import him ''any time at all''. When in trouble, there's nothing wrong with asking those familiar with OniSplit and/or the COLLADA format to have a look. What kind of masochist are you? If you're scared of me, try and "use" Neo. He may not help you all the way out, but he won't bite, that's for sure.
:: *shrug* Ed just seemed to be the person to ask. We're using the same programs, and he had clear experience in importing models already. --[[User:Iritscen|Iritscen]] 21:08, 2 June 2008 (CEST)
:::From what I have seen, Ed was quick to turn away from Blender and has since been working with Cheetah3D. No to say that he can't be of any help at all, but when it comes to Blender's COLLADA plugin and possible issues with ''that'', the right person to ask is Neo, who has taken the time to look at the plugin's (buggy) source to make sure Blender is decently compatible with the flavor of COLLADA used by OniSplit. --[[User:Geyser|geyser]] 07:01, 3 June 2008 (CEST)
:Oh, and I'm also very confused about '''work on Griffin began so long ago that OniSplit had some model exporting issues, which are now a part of the model, so the model is not able to be imported as is''' ... No bug report at all? Just what "issues" could we be talking about? Are those ''assumptions'', maybe? Well?
::[[User:Geyser|geyser]] 20:16, 2 June 2008 (CEST)
::The reason I didn't attempt a bug report was that I suspected the problems were extensive (wrong part names, for one thing, but probably more), and it was pointless to analyze the Griffin model I was working with as long as the head could be stuck on a new export of the original body. I knew I was going to do that so I never asked anyone to analyze the body I was working with (after all, only the head was changed and only the head mattered). Then, I *did* ask for a bug report from Ed by sending him my model, since I didn't know enough to find those bugs myself. --[[User:Iritscen|Iritscen]] 21:08, 2 June 2008 (CEST)
:::Meta-sigh. There is ''nothing'' wrong with the Griffin model you were working on: it's ''100% consistent'' with "a new export of the original body". It is ''not'' corrupt in ''any'' way, except for the hierarchy of the head, and that one can be fixed in-place without sticking anything anywhere.
:::Either way, in the future it'll be great if you don't casually attribute non-existing "issues" to OniSplit as if that was a fact. We have respect for user error; in return, please ''at least'' give the benefit of the doubt to the tools at your disposal (it's about ''your credibility'', not about offense).
::::--[[User:Geyser|geyser]] 07:01, 3 June 2008 (CEST)
:::::You probably get this by now, but the model that's "100% consistent" with a new export *is* a new export (except the HD head). --[[User:Iritscen|Iritscen]] 16:02, 3 June 2008 (CEST)
::::::Yes, but (see above) this still isn't telling me whatever was wrong with the old export: "wrong part names, for one thing, but probably more"... "probably"? Just what kind of suspectedly extensive problems were those. Please cope with my curiosity. --[[User:Geyser|geyser]] 17:31, 3 June 2008 (CEST)
:::::::(Answered above.) --[[User:Iritscen|Iritscen]] 19:00, 3 June 2008 (CEST)
::geyser, sorry my terminology is not correct.  What I called "center point" is the point where the body part will rotate around. I used "Rotation" as the orientation of the body part in 3D space.  When the rotation for all the body parts is 0 for x,y,z, then the pose of the model is the default orientation.  But since the pose in Blender is a standing pose, the rotation of the body parts is not 0,0,0. So if you replaced the head, with one that had a different rotation (even though it looked the same), the head will appear wrong in Oni.
:::''That's where the catch is, Ed: are you sure you understand how it is possible that 2 heads have "different rotations" even though they "look the same"? And in what sense is the rotation of the body parts not 0,0,0 for a standing pose? Think "local reference". --[[User:Geyser|geyser]] 07:01, 3 June 2008 (CEST)
:::''Blender designers do a great job at confusing people, in the way only global orientations can be seen and edited, but it's the ''local reference'' of each body part that matters, and the ''local'' orientations of most body parts (e.g., the head) are 0,0,0. --[[User:Geyser|geyser]] 07:01, 3 June 2008 (CEST)
::Here's the link to Iritscen's Griffin: http://www.sendspace.com/file/rl6zre  Also,  you can find my version of Griffin here: http://drop.io/EdT_OniFIles
::[[User:EdT|EdT]] 20:51, 2 June 2008 (CEST)
:::Thanks, Ed. Your TRBS is OK, I guess (as for the head mesh, that's a completely different story). The problematic .dae has been an opportunity to check out just what tool Iritscen is "forced" to work with. I'm definitely appalled at how much Blender sucks, from the confusing/confused design/philosophy to the online manual. In particular when it comes to coordinate systems and transformations, it's ''unspeakably'' clumsy. Of course, there are some decent workarounds (see 5-step instructions for fixing Griffin's head above), but that doesn't cover every real-world situation, and every such "exception" will be a little big nightmare. Maybe for HD modding or bastardizing the workflow won't be ''too'' lousy, but it will never ''soar'', that much is certain. --[[User:Geyser|geyser]] 07:01, 3 June 2008 (CEST)
::::Yes, the design is crappy (but don't tell them that, they have blinders on and can't see the appalling stupidity of things like no copy/paste command). Yes, the wiki-manual is crappy. But I think that we are actually close to a perfectly serviceable workflow. I used AETools this morning to export Griffin from the .oni file that Ed has up on his drop.io page, and it looks correct in Blender. I still have to test what happens when I edit the file (thus saving it in the .blend format), then export it to .dae from Blender, then import it into a .oni using AETools. It may very well work. Don't nay-say so much, geyser. Griffin in specific has had issues that will not ever come up again in the future. I still have to discuss him here because I need to fix the model for further work going forward, but our discussion here about workflow is somewhat a separate topic because it assumes that the OniSplit export is not buggy, etc. That's okay, because the OS export isn't buggy anymore. --[[User:Iritscen|Iritscen]] 16:02, 3 June 2008 (CEST)
:::::Blender is irredeemable beyond any complaint to developers. But I'll help you out if you choose to stick with it.
:::::Calling OniSplit export buggy without a proper bug report or even a version number... Final credibility warning.
:::::'''I need to fix the model for further work going forward''' "Yes you do... perhaps more than you know..." (C)Kerr
::::::[[User:Geyser|geyser]] 17:31, 3 June 2008 (CEST)
:::::::If you are insinuating something, please spell it out [[Image_talk:Poly_Mods-Griffin_Master_Comp.jpg|here]]. --[[User:Iritscen|Iritscen]] 19:00, 3 June 2008 (CEST)
::P.S. to geyser: I did offer these files to you by saying you could ask Ed for them... so, you can't accuse me of withholding them from you since I only just made them available to anyone at all, and you were included in that offer. --[[User:Iritscen|Iritscen]] 21:08, 2 June 2008 (CEST)
:::I wasn't accusing anyone of anything right there, but you have to admit that "oh, just go and ask Ed if you really wanna have a look at it, but I really wouldn't bother if I were you" is not the same as "here it is". Also, it's not just about "offering" stuff to ''me''; this is typically the case where I'd address ''Neo'' directly, at the first sign of trouble... "if I were you". --[[User:Geyser|geyser]] 07:01, 3 June 2008 (CEST)


Where do I begin? There is much being discussed here, so  I'm just going to put all my comments in one area.
the correct code should be the following:
:Regarding the "Rotation" terminology, this is my point of reference: I exported ONCCgriffin_generic from Oni  for Blender, get standing pose, select head, look at the Transform Properties I see RotX 90.00 RotY-90.00 RotZ 0.00 In comparison, Iritscen's griffin head has the properties RotX -0.08 RotY-1.993, RotZ 3.315. So even though the head looked the same, the Rotation properties were different. So if we were to export that file to .oni, would the head be in the correct position?


:Now my problem with exporting Iritscen's .dae I get this error from Blender (I followed what geyser stated about the export settings)
int i = 0;
do
{
  print("Is this annoying yet?");
  wait(20);
  i++;
} while (i != 50);   


  FEEDBACK: Illusoft Collada 1.4 Plugin v0.3.159 started
Why? If the conditional value is -1 or 0 (instead of 50) your code would never run (it would stop at first loop condition validation).  
  Traceback (most recent call last):
  File "/blender-2.46RC2-OSX-10.3-py2.5-powerpc/blender.app/Contents/MacOS/.blender/scripts/bpymodules/colladaImEx/cstartup.py", line 609, in ButtonEvent
  File "/blender-2.46RC2-OSX-10.3-py2.5-powerpc/blender.app/Contents/MacOS/.blender/scripts/bpymodules/colladaImEx/translator.py", line 63, in __init__
  File "/blender-2.46RC2-OSX-10.3-py2.5-powerpc/blender.app/Contents/MacOS/.blender/scripts/bpymodules/colladaImEx/translator.py", line 71, in __Export
  File "/blender-2.46RC2-OSX-10.3-py2.5-powerpc/blender.app/Contents/MacOS/.blender/scripts/bpymodules/colladaImEx/translator.py", line 346, in Export
  File "/blender-2.46RC2-OSX-10.3-py2.5-powerpc/blender.app/Contents/MacOS/.blender/scripts/bpymodules/colladaImEx/translator.py", line 516, in SaveToDae
  File "/blender-2.46RC2-OSX-10.3-py2.5-powerpc/blender.app/Contents/MacOS/.blender/scripts/bpymodules/colladaImEx/translator.py", line 1879, in SaveSceneToDae
  File "/blender-2.46RC2-OSX-10.3-py2.5-powerpc/blender.app/Contents/MacOS/.blender/scripts/bpymodules/colladaImEx/translator.py", line 2848, in GetBindMaterials
  File "/blender-2.46RC2-OSX-10.3-py2.5-powerpc/blender.app/Contents/MacOS/.blender/scripts/bpymodules/colladaImEx/translator.py", line 3106, in SaveToDae
  File "/blender-2.46RC2-OSX-10.3-py2.5-powerpc/blender.app/Contents/MacOS/.blender/scripts/bpymodules/colladaImEx/translator.py", line 2911, in AddImageTexture
  AttributeError: 'NoneType' object has no attribute 'name'


:For the disconnected triangles, I found the issue. Converting from .dae to .fbx no disconnected triangles, going from .fbx to .dae, disconnected triangles. Here are all the files: http://drop.io/EdT_OniFiles griffin_dae_fbx.zip The .dae/.fbx files with ORG in the name are the original .dae and converted .fbx. The ones with 2 is the .dae converted from the .fbx and back to .fbx.
While with:


:One other thought, the messed up names, I had that same problem when importing the ONCC as an object into Blender (Prior to the Collada option). The names of the body parts would be misapplied in Blender, so the head would be named something else, I don't remember the details.  So that's probably what Iritscen used when he first started to modify Griffin's head
schedule dprint("Is this annoying yet?") repeat -1 every 20;


[[User:EdT|EdT]] 18:51, 3 June 2008 (CEST)
It would run forever. Please consider to edit the page or if you want I can do it. Thanks. [[User:Script 10k|Script 10k]] ([[User talk:Script 10k|talk]]) 19:27, 2 November 2017 (CET)
 
:Oh, good point! Sorry I changed your pseudocode and didn't think about why you used "!=" instead of "<". Before I fix the page, let me ask, shouldn't I just set it back to the "for" loop that you wrote before? Is there a reason why the "do-while" loop above is preferable? --[[User:Iritscen|Iritscen]] ([[User talk:Iritscen|talk]]) 22:41, 2 November 2017 (CET)
:: Hi, yes I used the "!=" in the for loop because the reason above. Turns out that it was also wrong! Because it would also fail for this example:
schedule dprint("Is this annoying yet?") repeat 0 every 20;
 
for (int i = 0; i != 0; i++)
{
  print("Is this annoying yet?"); # this would never run with this code because 0 == 0
  wait(20);
}
 
See, it would also never run using my code for 0, so the do while loop is the correct equivalent imo. [[User:Script 10k|Script 10k]] ([[User talk:Script 10k|talk]]) 00:17, 3 November 2017 (CET)
 
Also I am thinking if the following code:
schedule dprint("Is this annoying yet?") repeat 0 every 20;
runs for long enough it could theoretically overflow with counter becoming negative and eventually reach 0 and stop, practically this can't ever happening because even if the counter would increase one 60 times per second it would need (2^31)*2/60/60/24 hours to reach zero (sorry if I'm doing bad the math but I am sure the number of hours it would take is just ridiculous). [[User:Script 10k|Script 10k]] ([[User talk:Script 10k|talk]]) 00:41, 3 November 2017 (CET)
 
:Okay, I implemented your "do-while" loop except that I am starting "i" at 1 instead of 0. I think that's what you actually wanted because it will iterate the correct number of times in all cases. (If it was initialized to 0 then it would stop after one iteration instead of running forever.) But I'm pretty tired right now, so let me know if that is also a mistake. --[[User:Iritscen|Iritscen]] ([[User talk:Iritscen|talk]]) 05:13, 3 November 2017 (CET)
 
::It wouldn't, note the i++ before the condition check, so the first check would be 1!=0. I will fix that part of the code no problem. [[User:Script 10k|Script 10k]] ([[User talk:Script 10k|talk]]) 11:09, 3 November 2017 (CET)
 
:::Oops, my bad. I shouldn't try to code after midnight. Thanks for the fix. --[[User:Iritscen|Iritscen]] ([[User talk:Iritscen|talk]]) 16:35, 3 November 2017 (CET)
 
== slowmo revisited ==
 
''[In reference to [[User_talk:Iritscen/Archive2#slowmo|this old discussion]].]''<br/>
Hi guys! Sorry for the massive bump. I am finishing my Omega Tournament Level and since I use slowmo in two calls, so I needed to investigate this issue (to find the correct ratio for both platforms). So I asked EdT to run the following BSL scripts (http://script10k.oni2.net/wikifiles/EnvWarehouse_slowmo_test_scripts.7z) on mac and to record it in a 60 FPS video. I did the same thing in windows. In the end I created two videos that compare the two versions of the scripts (one with slowmo 100 and other with slowmo 600) in both operating systems. The results seem to be the same!<br/>
You can watch the comparison here (you need a libx265 player):<br/>
http://script10k.oni2.net/videos/comparison_slowmo_win_mac_1.mp4<br/>
http://script10k.oni2.net/videos/comparison_slowmo_win_mac_2.mp4
 
In case you are interested the original videos can be found here:<br/>
http://script10k.oni2.net/videos/slowmo_os_comparison_original_videos.7z --[[User:Script 10k|Script 10k]] ([[User talk:Script 10k|talk]]) 04:58, 24 August 2019‎
 
[[Category:Userspace]]

Latest revision as of 02:14, 4 May 2022

Talk page archives: #1 (2008); #2 (2009-2014)

Re: Banner

Hey,

haha yes, I'm sorry for that. The banner was located on my installation CD and actually, this is the installer splashscreen: Click --Noneatme

Hehe, I feel somehow cheated that these levels never made it into the final game. The jewel case image you mentioned also gave me cancer and aids so I scanned the case for myself. Here is the back, CD, inner part and front. Also, the german sounds and voice lines are also well made and we have some translated textures like STAIRS at the warehouse level. And I also found some unused textures in some levels. --Noneatme (talk) 17:49, 29 July 2015 (CEST)

Annoying sidebar on smartphone

When I browse the wiki with my Samsung/Android phone the side bar takes a good portion of the screen especially if you try to zoom in.

It would be nice if that would hide when you scroll down and show when scroll up. --paradox-01 (talk) 19:46, 23 August 2015 (CEST)

When you are ready to test this on your phone, try commenting out the "div#mw-panel" modification on MediaWiki:Vector.css, then see how things look on your phone. I'm not sure if this is a mobile-friendliness issue with MediaWiki 1.19, but I'm thinking it's probably the fixed sidebar CSS that's the issue. --Iritscen (talk) 23:16, 23 August 2015 (CEST)

Couldn't edit the page you linked to so I took that equivalent at my place. Also cleared the browser cache but didn't work. Then I tried Google Chrome while I wasn't even logged in and it looks normal. Whatever the bug(?) is, at least I know now I could use chrome when surfing with a small-screened device. --paradox-01 (talk) 21:27, 24 August 2015 (CEST)

Ah, well that's good. Sorry, I didn't realize the main Vector.css page wasn't freely editable. But keep in mind that your user Vector.css page stacks on top of the main Vector.css, so when you comment out that CSS on your user page, it simply means that the main Vector.css is still used for mw-panel. You would have to re-declare mw-panel on your user page with its original properties in order to get rid of the anchored sidebar mod. Let me know if you want help with that. --Iritscen (talk) 21:44, 24 August 2015 (CEST)

Yes please. I couldn't figure out the right defaults. --paradox-01 (talk) 22:40, 24 August 2015 (CEST)

It seems like you only need to change "position" back to "absolute", which is the default, but that's just one of the changes made to the panel in Vector.css, so let me know how it works on your phone. --Iritscen (talk) 23:31, 24 August 2015 (CEST)

Okay thanks. With your code it works now on the phone. --paradox-01 (talk) 08:38, 25 August 2015 (CEST)

Red links - weapon pages

There's no talk page for Special:WantedPages so I will my question here: Why do we need extra pages for Plasma Rifle, Super Ball Gun, Black Adder, Plasma Rifle, Screaming Cannon, Wave Motion Cannon?

There's this Quotes/Weapons and IMO there's not more to say about them. Let's delete the red links? --paradox-01 (talk) 20:51, 24 November 2015 (CET)

There's also Gameplay, for some brief weapon tips. Here's the thing, though. Mercury Bow is already an article. Why should the M Bow get an article and not the other weapons? In fact, I would say that most of the red links highlighted at the top of "Wanted pages" are equally minor. While there may not be a lot to say about them, they deserve at least a short page, I think. --Iritscen (talk) 04:22, 25 November 2015 (CET)

Wrong pseudo code

Hi Iritscen thanks for fixing my wording.

I have just noticed a small error.

The following code:

for (int i = 0; i < 50; i++)
{
  print("Is this annoying yet?");
  wait(20);
}

found here: BSL:Manual#schedule_..._repeat_..._every_...

is not correct. It is not equivalent to (at least if you change the variables, let say 50 to -1) in

schedule dprint("Is this annoying yet?") repeat 50 every 20;

the correct code should be the following:

int i = 0;
do
{
  print("Is this annoying yet?");
  wait(20);
  i++;
} while (i != 50);     

Why? If the conditional value is -1 or 0 (instead of 50) your code would never run (it would stop at first loop condition validation).

While with:

schedule dprint("Is this annoying yet?") repeat -1 every 20;

It would run forever. Please consider to edit the page or if you want I can do it. Thanks. Script 10k (talk) 19:27, 2 November 2017 (CET)

Oh, good point! Sorry I changed your pseudocode and didn't think about why you used "!=" instead of "<". Before I fix the page, let me ask, shouldn't I just set it back to the "for" loop that you wrote before? Is there a reason why the "do-while" loop above is preferable? --Iritscen (talk) 22:41, 2 November 2017 (CET)
Hi, yes I used the "!=" in the for loop because the reason above. Turns out that it was also wrong! Because it would also fail for this example:
schedule dprint("Is this annoying yet?") repeat 0 every 20;
for (int i = 0; i != 0; i++)
{
  print("Is this annoying yet?"); # this would never run with this code because 0 == 0
  wait(20);
}

See, it would also never run using my code for 0, so the do while loop is the correct equivalent imo. Script 10k (talk) 00:17, 3 November 2017 (CET)

Also I am thinking if the following code:

schedule dprint("Is this annoying yet?") repeat 0 every 20;

runs for long enough it could theoretically overflow with counter becoming negative and eventually reach 0 and stop, practically this can't ever happening because even if the counter would increase one 60 times per second it would need (2^31)*2/60/60/24 hours to reach zero (sorry if I'm doing bad the math but I am sure the number of hours it would take is just ridiculous). Script 10k (talk) 00:41, 3 November 2017 (CET)

Okay, I implemented your "do-while" loop except that I am starting "i" at 1 instead of 0. I think that's what you actually wanted because it will iterate the correct number of times in all cases. (If it was initialized to 0 then it would stop after one iteration instead of running forever.) But I'm pretty tired right now, so let me know if that is also a mistake. --Iritscen (talk) 05:13, 3 November 2017 (CET)
It wouldn't, note the i++ before the condition check, so the first check would be 1!=0. I will fix that part of the code no problem. Script 10k (talk) 11:09, 3 November 2017 (CET)
Oops, my bad. I shouldn't try to code after midnight. Thanks for the fix. --Iritscen (talk) 16:35, 3 November 2017 (CET)

slowmo revisited

[In reference to this old discussion.]
Hi guys! Sorry for the massive bump. I am finishing my Omega Tournament Level and since I use slowmo in two calls, so I needed to investigate this issue (to find the correct ratio for both platforms). So I asked EdT to run the following BSL scripts (http://script10k.oni2.net/wikifiles/EnvWarehouse_slowmo_test_scripts.7z) on mac and to record it in a 60 FPS video. I did the same thing in windows. In the end I created two videos that compare the two versions of the scripts (one with slowmo 100 and other with slowmo 600) in both operating systems. The results seem to be the same!
You can watch the comparison here (you need a libx265 player):
http://script10k.oni2.net/videos/comparison_slowmo_win_mac_1.mp4
http://script10k.oni2.net/videos/comparison_slowmo_win_mac_2.mp4

In case you are interested the original videos can be found here:
http://script10k.oni2.net/videos/slowmo_os_comparison_original_videos.7z --Script 10k (talk) 04:58, 24 August 2019‎