OpenXcom Forum
Modding => Tools => Topic started by: Warboy1982 on July 05, 2013, 10:13:56 pm
-
so the past few days i've got it into my head that a modding interface might be a good thing, so i whipped up a little something in my spare time (see attachment).
i'm just wondering... who wants to help?
i've pushed it to a repo HERE (https://github.com/Warboy1982/OXCTools).
the project is in it's infancy at the moment, step one will be reading in the YAML and displaying it in the lists. obviously i'll be "borrowing" heavily from the OXC codebase for certain things, like reading .pck files and so on, hence the choice to use C++ for this project.
i hope to integrate the map editor that luke and pmprog are working with as well, i realize this is written in C#, so i'm fine with having it as an unrequired stand alone executable.
created in Qt.
i won't be looking into any translated versions until the software is functionally complete.
-
very nice. I'm looking forward to this :)
-
Cant wait for this also ;)
-
i won't be looking into any translated versions until the software is functionally complete.
I'd say that you don't bother with i18n. Proper modding articles are mostly found in English.
That being said, this is great news for the modding community
-
Looks like the charm!
-
Looks nice. :)
Personally I would've just written it in C# so I wouldn't have to worry about libraries and junk (it can still interface with native code), and just to get the OSS community up in arms. :P
-
When I was chatting to Warboy I mentioned if it was C# we could merge it with the map editor and other tools I'm maintaining easier, but he is actually using the .NET framework with C++ so it should still be possible
-
actually i switched switched to Qt C++, because i have no idea how to use either of them, and the general concensus was that i shouldn't be using .net.
-
OSS can use .net too: mono :)
-
OSS can use .net too: mono :)
while that is true, you have to make sure you don't use any microsoft-only libraries. QT is much more likely to work cross-platform.
-
Can OXCTools show an Ufopaedia page, like the Sectoid Autopsy image for example and can it render fonts onto such an image?
It would be cool to see new research / discovery related text displayed on top of an artwork in order to calculate word count and maybe let us format the text via the basic word processing functions: new line, space, etc.
-
Warboy, will this tool share code with OXC or it will be completely standalone?
I'm asking because requests like the one above would benefit from the code sharing
Using the same data and renderer will result in the same result all the time, as oposed to having to update the tool if the OXC code changes. OTOH, the ufopaedia is completed and probably it won't change much...
-
Reusing the code would likely be the best approach but also the most complex. OXC code is deeply entrenched in its libraries and dependencies (everything graphic expects SDL surfaces etc.) and I don't think Warboy fancies that when he's trying to make less work for himself. :P
Plus if he had done it in .NET he could just reuse the loaders from Daishiva's tools, obviously the superior solution. ;)
-
Is it worth me looking at porting Daishiva's tools that I'm currently maintaining into QtCreator and Warboy's OXC Tools? I guess this is more of a question for Warboy than anyone else...
I can sort all (most) of Luke's changes out, whilst at the same time keeping us one nice clean tool that can access both original data formats and any new OXC formats
-
at this point it's all amorphous, i'm not really making any progress in either, because i'm learning as i go, and not many tutorials are dealing with my specific situation. i'm not sure how to even read in the ruleset yaml, apparently Qt can do it natively, or something, but it's a PITA, and i can't figure out how to include the yaml-cpp library, because apparently Qt isn't that kind of girl. so far it's taken me a week to get the tree view populated, and i'm pretty sure i didn't even do that right.
-
nope, far too ambitious on my part, nothing about this works, i'm just losing time here, learning nothing.
-
Awww, did my code sample not help? or did you post this before that?
-
So, any GUI apps programmer here who could write this utility?
-
Well, speaking with Warboy earlier, I might try and combine MARS with the other tools I've taken up :)
-
In C#? But first you would need to write MARS ;)
-
Yes, it'll be C#, and yes, I know I need to write MARS. I'm half tempted to rebuild the map tools based upon the data from a loaded ruleset, rather than it's own individual hardcoded config file
I guess we'll see though
-
Sounds nice. Hope to see some progress soon ;)
-
btw Warboy do you think that you could create sprite creator? e.g. load surfaceset with unit parts and then place them manualy on "animation frames". save all data to file and load it in OpenXcom?
every surface in surfeceset will have 4 values write by this editor for every animation frame:
x,y - position offset
z - draw order
v - visible
Editing could be very "simple":
3 controls [next, prev, list of all] changing frames (probably longest list here)
2 controls [left, right] changing rotation (8 direction)
3 controls [next, prev, list of all] selecting surface group (e.q. chest part, legs, right arm, corpse frame)
4 settings [v,x,y,z] values for current part
1 screen showing unit using with current frame and rotation
-
i guess i could write up a design brief and start building some of the context menus.
i was planning to steal the sprite drawing routines from OXC to build a rotatable image, which could preview different animations (ie, walking, shooting, holding various arrangements of weaponry) so if you were replacing frames within a set, (like, say moriarty's armour mod) you could see the changes.
i wanted to steal the geoscape globe renderer too, so you could see the country/region/mission zone borders as you were editing them. (drawing routines already exist within OXC to render these)
but these were plans for well down the line, like... finishing touches.
getting it to read in YAML is the first hurdle.
-
You could simply made desktop version of OpenXcom (somthing like this https://inanutshelll.files.wordpress.com/2010/04/2010-04-13-civ2.jpg ) :D
-
getting it to read in YAML is the first hurdle.
The upside is with C#, that part is the easiest as you can just use reflection to automatically load/save any class fields.
-
The MARS C# code I wrote can read YAML fine...
I did think about when (if) merging the PCK viewer, whether to add a simple "paint" package to let you edit them too, but I wasn't sure on the demand now that you can use bitmaps in the game engine.
-
In my humble opinion:
This project shouldn't be Warboys little pet of the week. (no offense Warboy) This project combined with whatever system for loadable-unloadable mods should be the primary direction of current OXC development. Once we have proper mod/modder support the only thing between us and 1.0 is bugs.
I'm thinking at some point SupSuper or someone should lay out a design doc of some type (feature list maybe) and new roadmap to 1.0. The reason I suggest a design doc and new roadmap is because X-COM was our perfect exhaustive design doc, we all played it for 10+ years; obviously we haven't already used the mod tools/support we'd be making.
Anyway, it's just my humble opinion because I'm really kinda on the outside looking in right now. I'm barely a real programmer and haven't had time for OXC lately.
-
Once a good AI is finished, everything will fall into place.
-
It'd be great if development was as linear as going from point A to point B, but there's always new bug reports, new feature requests, new stuff to do. :P The current feature list for 1.0 is just finish as many bug reports and popular feature requests as we can.
I have written a modding design doc that covers most people's requests and I'll look into implementing after 1.0.
-
This project shouldn't be Warboys little pet of the week. (no offense Warboy)
Is Warboy still looking at this? I remember I was going to start coding it into the OXCTools project, but alas, real life has been a massive distraction for the past couple of months, and is looking to consume my time at least until the new year.
-
I'm pretty sure he's working on the new battlescape AI and not really looking into this anymore.