xdaniel

Quick thoughts about Railgun S episodes 17-19:

Lots of C#, XML and Lua later, we have a control container for less crappy updating and drawing, buttons and labels for user input and output, timers that tick and elapse, faders to fade parts of the screen in and out... local Controls = ControlContainer(Game)local Timer, Fader, Label = Timer(Game, 3500), Fader(Game), Label(Game)function Fader_FadeInComplete(sender, args) print("Fade in complete, turning on the timer...") Timer.Enabled = trueendfunction Fader_FadeOutComplete(sender, args) print("Fade out complete...") Controls:Clear() ActiveControls = nil printColor("Cleared controls; here would come the next part...", Color.GreenYellow) dofile("ContentScriptsTitle.lua")endfunction Timer_Tick(sender, args) -- printColor("Timer ticking, " .. sender.SecondsLeft .. " seconds left...", Color.Orange)endfunction Timer_Elapsed(sender, args) print("Timer elapsed, starting fade out...") Fader:BeginFadeOut()endTimer.Enabled = falseTimer.Tick:Add(Timer_Tick)Timer.Elapsed:Add(Timer_Elapsed)Controls:AddControl(Timer)Fader.LayerDepth = 0.0Fader.Location = Point(0, 0)Fader.Size = Vector2(Game.GraphicsDevice.Viewport.Width, Game.GraphicsDevice.Viewport.Height)Fader.FadeInComplete:Add(Fader_FadeInComplete)Fader.FadeOutComplete:Add(Fader_FadeOutComplete)Fader:BeginFadeIn()Controls:AddControl(Fader)Label.Text = "Greatsounding Novel Title ~Lua Scripts in the Content~n169 2013 by DigitalZero DomainnnPowered by " .. EngineVersion .. " Visual Novel Enginen169 2013 by DigitalZero Domainnnhttp://magicstone.de/dzd/"Label.Font = "DialogFont"Label.AutoSize = falseLabel.Location = Point(0, 0)Label.Size = Vector2(Game.GraphicsDevice.Viewport.Width, Game.GraphicsDevice.Viewport.Height)Label.ForeColor = Color.WhiteLabel.BackColor = Color.CornflowerBlueLabel.TextAlign = ContentAlignmentFlags(ContentAlignmentCenter)Controls:AddControl(Label)ActiveControls = Controls

Most likely (?) environment settings format: aaaaaa bbbbbb cccccc dddddd eeeeee ffffff gggg hhhh Where: a = Ambient light color (RRGGBB) b = First diffuse light direction (XXYYZZ) c = First diffuse light color (RRGGBB) d = Second diffuse light direction (XXYYZZ) e = Second diffuse light color (RRGGBB) f = Fog color (RRGGBB) g = Fog near distance h = Fog far distance

Makin' controls for an XNA GUI... ...which can be created and configured from Lua scripts, too!

Nah, it's alright and useful information to boot. There's a note about texture sizes in SO's Readme, but I don't think it was as comprehensive as your list is (ex. regarding texture formats). About my XNA stuff... I've got an idea about what kind of engine I'll try to make. Some stupid messing around, which you can see in the screenshot below, made me think...:

...and from that "movement", right now I've got a terrible sunburn and am rather tired. Also, honestly, individual file saving is a lower priority for me anyway as most people apparently work with ROMs. It's not forgotten, I will implement it, but it's still a version or two away.

Yeah, there still doesn't seem to be much interest in SceneNavi over there, but I've gotten some feedback from one or two people, including about this bug. I'm checking Maco once a day or so regardless, so if something is posted ex. about SceneNavi there, I do see it.

Now that I've got some time... int ptlen = (int)(PolygonArrayOffset - PolygonTypeOffset); /* Official maps */ if (ptlen <= 0) ptlen = (int)(WaterboxOffset - PolygonTypeOffset); /* SO imports */ if (ptlen <= 0) ptlen = (int)(this.GetAddressGeneric() - PolygonTypeOffset); /* HT imports */ Basically the problem is detecting where the polygon type definitions end as they don't have a set count. Official maps all have the polygon array directly following the polygon types, so that's easy to detect. SO assigns a waterbox offset regardless of if there's any waterboxes defined, and those would directly follow the polygon types. I had simply not used HT when I initially wrote this part of SceneNavi - in fact, I still haven't used it much - so I didn't know if HT stored its generated data any different from either the actual game or SO. I only learned about this when I got a bug report on Maco regarding this very same problem, and lo and behold: In HT-generated scenes, the collision header follows right after the polygon types, neither the polygon array nor the waterboxes. This has been fixed for Beta 7, as I posted on Maco a few days ago.

Not much time; HTs generated collision header and data is annoying to detect starts/ends with, namely polygon types. Will go into detail later.

ClariS - irony (Oreimo season 1 OP) Remembering when the show wasn't crap... RIP Oreimo -.-

Oreimo episodes... uh... nope, I haven't watched them yet. And between the tweets from Stilts of Random Curiosity, alphaheiti's post, and Zanibas' post on RC for episodes 14 to 16, I have no desire to watch them anytime soon. I guess I will eventually, but, like...

Sorta related to Kokoro, as in it's the result of a long train of thought regarding "A scripting engine would be cool, wonder how difficult that is...", "I really like Antidote's console...", "Damnit, I need to learn more about XNA/MonoGame...", "Crap, I've never used Lua before...", "This has become pretty meh, I'll start over...", etc. Gonna try and take it really slowly now. Edit: ...switched to XNA proper. For one, I couldn't get keyboard text input to work reliably in MonoGame, even in XNA that requires some nasty stuff AND I still can't catch certain keys, such as @, € and because they require pressing AltGr and then Q, E and ß respectively with German keyboard layouts... or should I say kezboard? Anyway, also been looking some more into Lua, like defining variables, etc., as well as hooking C# functions up to it (through NLua).

http://code.google.com/p/sharpocarina/source/browse/trunk/MapDev/MainForm.cs#1359 /* Now add default environments ... normal environment */ /* ... underwater environment */ /* ... rainy environment */ ...but granted, they weren't documented outside the source, and not beyond those short comments. Also, IIRC those are only the defaults for "outdoor" scenes, dungeons have different (fewer?) environment settings.

I didn't name the lighting color options in SO because I would've wanted to name them properly - ambient, diffuse, specular, etc., not just "upside" or "downside". And unless we figure out which color really is what, I won't be naming them anything other than "Color A", "Color B", etc. in SceneNavi either. But that aside, really nice findings there, I need to experiment with them a bit too

â–²ChriisTiianâ–²: Okay, I get it now, but I don't think I'll be adding this feature either. I feel like that would be 1) kinda out of the scope of the project and 2) too much work to implement in it. There's also other more important things I still need to work on in SceneNavi (the Scene Metadata tab, etc), and the area title card editing was as mentioned just an accident, although a positive one. That said, I might, emphasis on MIGHT, someday look into making a separate texture importer/exporter or fix up the one I started, which you could use for scene/room textures or ex. the title screen, but do not expect this to happen and do not hold me to this statement.

â–²ChriisTiianâ–²: Uhm, "textures of selected area"? I'm not sure what you mean by that...?Heavy: If you mean the texture exporter/importer I was working on ages ago, that wasn't just for the title screen logo, but supposed to be for any kind of texture, in any kind of N64 format, in any N64 game. If I remember correctly, I dropped it because I never finished the importing side of things (or what I had for that was crap, or something like that). And I won't add anything like that to SceneNavi; the area title card is all it'll be able to edit, texture-wise, and I only added that feature because the scene table happens to provide the offsets anyway. It's pretty much just a happy little accident.

Etrian Odyssey IV: Super Arrange Version - Battlefield: Storm Still a big fan of EO1's Initial Strike and Destruction Begets Decay, but EO4's OST (and Super Arrange Version) is off to a good start in my book

Tree of Tests! Edit: In different versions, too:

The way in which Oreimo is gonna end really soured the whole show for me. It's also why I haven't yet watched S2 episode 13...

Back to PCs (laptops) and a non-Madoka wallpaper: (Also reset my phone's DPI back to default, too many display problems...)

mzxrules: As in, leave the 0x18 command out of the room/map files, but leave it in the scene itself? Not sure if that'll work... If the game really looks them up like "SceneHeaders[stageNumber]" and "RoomHeaders[stageNumber]", it'll probably just read garbage data for the room headers then, seeing how the 0x18 command needs to specify the alternate header's offsets... Rinku: I basically made the alternate header list point to the nightmare instead of the intro, and to the intro instead of the nightmare. The result was that the intro used the nightmare cutscene's camera angles, etc., but that ex. no actors appeared, presumably because the intro's room actors were loaded, not the correct nightmare ones. Also, yeah, the Scene Metadata tab (and maybe a separate Room Metadata one, depending on how I'll do the GUI) is planned to have a bunch more options, including timeflow, skybox settings, etc. Finally, I changed the treeview as per the above findings/assumptions; still needs some more sanity checks and general testing: And for those curious, the corresponding XML document for the stage descriptions is called StageDescriptions.xml, resides in each ROM version's folder in GameDataSpecific, and looks like this:

Exchanged the alternate scene header pointers of Hyrule Field's intro and nightmare cutscenes - changed data at 0x27D6074 in ROM to "02011D60", and data at 0x27D6080 to "02011AD0" - and got this when I ran the game and pressed A (technically, when I messed around a bit first, then restarted the cutscene and pressed A): ...so unless I'm a complete moron (please point out if I am and why), this might be proof of those relations...

Speaking of the headers, I've been wondering... Seeing how the room(s) of a scene appear to always have the same amount of headers that the scene itself has, and appear to be directly related to each other just by their index, should I try to group things into "stages" in the way the Map Select does? I mean, for example, instead of going "Ice Cavern -> Scene Header 0xF6A0 -> ice_doukutu_room_0 -> Room Header 0x100" the treeview would go something like "Ice Cavern -> Header #2 [maybe description here, if feasible? Like "Cutscene: Learning Serenade of Water"] -> ice_doukutu_room_0", without a separate room header selection. I guess that would make it easier on people who have no idea what in the world a "scene header" is or why it's important.

Rinku: I think it was Strati who documented those a while ago on the forums here, checking where it was exactly... *searches* ...and there it is: https://www.the-gcn.com/topic/2471-the-beginners-guide-to-music-antiqua-teasers/?do=findComment&comment=40641 - Think I'll make this a drop-down list, too, in the next build.

It does "work" on Dolphin if you disable Dual Core support and/or Idle Skipping, but once it's time to go in-game, you'll be hit with repeated "Failed to compile pixel shader" errors, regardless of the renderer (D3D9, D3D11, OpenGL; software doesn't work at all). Don't really have anything else to say about it; haven't played the final game very much, so I couldn't compare the demo to it, either.