This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
Messages - iindigo
1
« on: January 30, 2017, 04:30:06 pm »
Finally someone realized that current unfoolproof way of config usage is absolutely terrible. Making application work even with missing at end of path, making it write comprehensive error on error and in optimal case, making it able to ask user for new directory as current one seems to be incorrect, dafuq is that complicated about this? This should have been implemented years ago, its barely a couple of rows of code, at least some of this stuff definitely is.
I understand it is annoying and I have been trying to make it less annoying some times in the past (especially things like missing fonts == bad path), but people have been working against. *shrug*
The reason this has not been implemented years ago is that as iindigo said his solution is platform dependent. This is the case since we can't load those damn fonts and textures and thus can't use our normal UI. I have been and will be seeing platform dependent things negatively. The Qt branch already has platform independent UI, and -- drumroll -- has such an error message and dialog to choose the right path.
Hope I'm not brushing anybody the wrong way by working on the SDL branch. I plan to work on the Qt branch too, but the Qt branch isn't really usable yet and I'm not equipped with the skills needed to make it more usable — my expertise lies in more traditional UI oriented desktop software, not reading proprietary binary files and drawing things in OpenGL. I can figure these things out (and have just a little bit - I'm working on an M2 tool on the side)but the ramp up time is not going to be short. I figured smoothing out rough edges on NSDL before working on NQt's UI might be a more productive use of my energy.
2
« on: January 30, 2017, 06:08:38 am »
Started working on improving Noggit's behavior in the absence of a config file (e.g. first run). Right now, if it can't find WoW or your WoW install is the wrong version, it just crashes and you have to open its log file where it only gives you a vague error about not being able to load fonts. This is nonintuitive (nobody would guess the problem is it not finding the game) and frustrating behavior.
After my modifications it instead displays an error dialog and then lets you select the location of your installation.
[media:7b2uor0u]https://d17oy1vhnax1f7.cloudfront.net/items/2e2p3K2H0u3A0A3R2W3j/dialog.mp4[/media:7b2uor0u]
Right now I've only got it implemented on macOS, but implementing it under Windows should be pretty easy since Noggit already links against winapi. I intend to get it working under Linux is well, probably with GTK+ (unless Linux users have a better suggestion of course).
It'll write the path you choose to a newly made config file (if it doesn't exist already) located where you'd expect to find config files on your platform (beside the EXE file on Windows, ~/Library/Application Support/Noggit/ on macOS, and ~/.config/Noggit/ on Linux).
3
« on: May 22, 2016, 07:21:47 pm »
OpenGL 3.5? It's been a while since I looked deeply at its source but I remember seeing quite a few OpenGL 1.x function calls...
Yeah, I just had a quick look at a couple of the implementation files on bitbucket and there's definitely old-style OpenGL going on. Can't say to what extent since I'm on my phone right now but it's definitely not all modern.
4
« on: May 22, 2016, 01:53:31 am »
A word of caution for reading noggit code: unless I'm mistaken, it's written with OpenGL 1.x which at this point is entirely obsolete — if you can avoid learning it you should. Graphics drivers may start dropping 1.x support over the coming decade, leaving you with skills you can no longer use. Neo is written with fairly modern DirectX if I'm not mistaken, so it should still be relevant, but keep in mind that DirectX is tied to Windows. If you're unfamiliar with programming languages I'd advise studying those first, but whenever you feel ready, here are a few places that will guide you through the basics of modern (version 2.0+) OpenGL, including rendering polygons to the screen: http://www.opengl-tutorial.orghttp://learnopengl.comhttp://antongerdelan.net/opengl/#onlinetutshttp://www.davidbishop.org/oglmetaEDIT: If you're curious specifically about how the WoW data files are read, Steff is right in that reading Noggit's code may be of some help in understanding. Just don't use it for instruction on 3D rendering.
5
« on: April 26, 2016, 08:48:53 am »
Not bad looking.
This is an area where MoP's ability to seamlessly blend terrain and M2s could really be used to great effect. You're modding with WotLK I assume?
TBH from a creative perspective I've always been a little frustrated with the limitations of WoW terrain. It'd be wonderful if it were more than a simple 2D → 3D extruded height map and had support for modeling fully 3D features into the terrain without M2s.
6
« on: April 18, 2016, 05:22:49 pm »
For outdoor areas you might be able to modify the server core to be able to read static/baked shadow maps from ADTs. This would work similarly to how vamp extraction works, reading ADTs and converting the desired information into something more readable. The server can then factor them into stealth calculations.
Obviously this wouldn't help for light sources like torches but it would reduce the amount of manual light marker placement work necessary.
7
« on: April 13, 2016, 02:26:40 am »
Did some updates to my spell editor recently, it's a bit faster now:
[media:6n0sasi0]https://youtu.be/eRmLi54PDko[/media:6n0sasi0]
Can't really fix the lag of updating the control's (loading spells) without redesigning the interface completely. I just rushed the interface and didn't really consider it might lag with this approach. Looks nice. To address the lag, how hard would it be to 1) throw loading on a background thread so the UI isn’t blocked and 2) set up a caching system for heavier resources (icons, etc)? Both are common in mobile development and help a lot to make heavy datasets feel light even with limited resources.
8
« on: February 13, 2016, 07:57:54 am »
This is something I’ve wanted to do ever since the initial glitter of Cataclysm started wearing off and I realized how badly it ruined the world I loved. I’d also like to do as Morfium mentioned and repair the Park area and the charred bits of wall, etc. So stumbling around Noggit for my first time, I noticed that all of stormwind is one big wmo (I hope I used the right term). Is the same true for MoP Stormwind/Orgrimmar? If so, could both of those wmo's be backported and inserted into 3.3.5a replacing their older counterparts? I know that the world terrain won't necessarily line up perfectly with the new wmo's but I am just curious if this is possible. I *think* SW is still a giant WMO in Cata and newer, with a couple of key differences: Vanilla-Wrath SW and Org included the ground as part of the WMO, while Cata and newer SW and Org WMOs have the ground carved out of them so terrain can take its place. This means that if you were to backport the newer WMOs you’d also have to find a way to shape and texture the ground terrain the WMOs sit upon to precisely fit the WMOs.
9
« on: November 21, 2015, 09:08:23 pm »
Don't have anything to really show for it yet, but I too have been working on parsing M2s. My focus is on lights though, because I'm trying to build a visual light editor that hopefully doesn't have the bugs that lightadder has.
I'm writing the logic in C++ and the UI in Objective-C. Why Objective-C? Because I'm firstly making the tool for myself and I use a Mac and because making UIs with Cocoa is amazing (even Qt is painful in comparison). I'll see about other platforms once the tool is more complete. Lightadder does not have bugs. They are client side limits of 3.3.5a. Blizzard lights are also bugged.
Well whatever the case, in 3.3.5 if you add a light to something you’ve also got to adjust the bounding box for it to work right, and light adder doesn’t do that. You have to tweak the box manually in a hex editor which is incredibly tedious if you’re adding lights more than once in a blue moon. If I target a newer version instead (say WoD) to get around the issue, it’d still be nice to have a visual editor that lets me choose a color with a color palette, lets me copy + paste lights between M2s, etc.
10
« on: November 21, 2015, 08:01:49 pm »
Well if it's any consolation, I don't know C++ very well either, haha. I'm far, far stronger in Objective-C. That doesn't stop me from using it, though! I learn languages by diving right into ambitious projects and going in way over my head because I learn through hands-on/practical experience far more easily than I do through books and reference. I can read about something for days but I won't have a real understanding of it until I just use it.
11
« on: November 21, 2015, 07:30:54 pm »
Don't have anything to really show for it yet, but I too have been working on parsing M2s. My focus is on lights though, because I'm trying to build a visual light editor that hopefully doesn't have the bugs that lightadder has.
I'm writing the logic in C++ and the UI in Objective-C. Why Objective-C? Because I'm firstly making the tool for myself and I use a Mac and because making UIs with Cocoa is amazing (even Qt is painful in comparison). I'll see about other platforms once the tool is more complete.
12
« on: November 11, 2015, 12:06:09 am »
The box you have to edit is "vertex box" which is bounding, "bounding box" is for collision. I updated the naming to be consistent with Blizzard some weeks ago on the wiki. This worked beautifully. Thanks! Take the values from vertex float boxes (max, min and radius.. 7 in total), and then go to the stand animation, and copy them into that animation's bounding boxes. That should do the trick.
It's a common bug that you get used to fixing with Obj2M2.exe. Garthog never got around to adding the fix.
---------------
For example - Fixing a dagger that has the same problem;
You take these, and put them here:
So then it looks like:
 Interesting. I haven’t used Obj2M2 at all, and have only been adding lights to M2s that already existed in WotLK (with exception to some down ported SW street lamps from Cata). These changes didn’t seem necessary after editing the VertexBox entries under the theFloats struct, as pointed out by schlumpf. I don’t doubt that this would also fix the bug, I’m just curious as to when either method is necessary. Should both be set? Also, has anybody worked out a way to dynamically calculate a proper vertex bounding box given an intensity? I’d really like to roll this into a new build of LightAdder if possible to reduce manual work. And how do attenuationStart/End work? They sound like they’d control the “gradient” the light uses as it fades with distance but playing around with it, I don’t really see any difference in-game.
13
« on: November 10, 2015, 11:16:35 pm »
Awesome work! Is this all done with client-side cinematic tech?
14
« on: November 10, 2015, 03:54:46 am »
So I’ve been going through Azeroth and adding lights to the various lamps, torches, etc scattered throughout (3.3.5) with LightAdder. This works great, but as some of you here are aware, M2s with lights added by LightAdder have a bug: their bounding boxes don’t match up to the sphere of light that the light(s) you added cast, meaning that all of the light the model is casting just disappears when the model isn’t in the player’s field of vision. This creates a distracting, unpleasant effect where lighting kinda pops in and out of existence as you walk along. To fix this, as suggested, I tried grabbing 010 editor and editing my custom M2 files with a template. I’m able to modify the M2 fine and it saves alright, but after logging into the game I see no difference, even after changing values to extremes (100+). So now I’m wondering if I’ve done something wrong. Am I editing the appropriate values? What is the range of numbers that I should be editing within — what units do these numbers represent? Is there a known mapping between M2 light distance values and M2 bounding box values? Below is a screenshot of the values in question. 
15
« on: September 29, 2015, 05:19:34 am »
Great work there, schlumpf. The general direction that the game has taken is questionable, but with each expansion I am consistently impressed with how much further the WoW tools + art teams manage to push this crochety old engine. They always manage to find ways to make it look better.
|
Show Posts