dragoness_e: Living Dead Girl (Living Dead Girl)
The more I work with ad-hoc APIs, the more I appreciate formal, written standards. Means code doesn't break because some dev suddenly decides it would be more aesthetic to re-arrange the order of parameters in an API call in the newest version. With a standard: forty-year-old C code will compile and run just fine as long as it follows one of the international standards the compiler recognizes. Without a standard: yesterday's Minecraft mods may be broken because some dev decided to re-arrange the terrain generation code overnight.

I have encountered both situations. There's a lot of open-source devs out there that don't seem to understand that an API (Application Programming Interface) is supposed to be a STABLE interface to back-end code; you can re-arrange the back-end code to suit, but the interface (API) is supposed to remain the same.
dragoness_e: (Echo Bazaar)
So "WeatherMaker", the old command-line tool for generating D&D weather reports, has now been cleaned up and made to compile under a semi-modern C++ compiler. I've posted the source code to GitHub, and released both a Windows-64 and a Linux version of the executable. Yay, me! Hopefully the gentleman who sent me the e-mail query gets my replies and the update. It's also possible his spam filter ate my replies.

In Minecraft modding news, I investigated a crash bug one of my users reported, and kicked myself for blowing off testing my code in server-client configuration, as well as in single-player configuration, because the alloy furnace thingy (aka the 'fusion furnace') was indeed "crossing the streams" and calling server-only code from the standalone client. Whoops. I fixed that, but between overhauling WeatherMaker and the Fusion mod's little issue, I haven't moved forward with any of my modding--just fixed bugs for several days now. Meh.
dragoness_e: (Echo Bazaar)
Thanks to a gentleman who inquired about a possible update to an 18-year-old weather generator program for D&D, I decided to find it and check on that. That led to realizing I'd never finished repairing my old website from the damage done by my web host's PHP upgrade (namely, all the old pages broke, because they used deprecated/removed functions), including the page with the download for the weather generator. That led to fixing as many broken links and malfunctioning pages as I could and recovering misplaced old sections of the website (I had links all over to old versions of the site, and wanted to move them and reconcile them), and now it's late afternoon, where did the day go?

I still haven't unpacked wthrmkr and checked if it still compiles yet. I think I'll do that next.
dragoness_e: NASA F-15A #837 (NASA Starscream)

DEPRECATED - see for 1.13/1.14 modding info

To wit, posts I have found somewhat useful for Minecraft modding, particularly 1.7.X. This list will be changing over time, hopefully growing, but also having outdated stuff pruned from it.

Not all modding tutorials are useful. Some are outdated, and some were written by people with a shaky grasp on Java, how Minecraft works internally, the MinecraftForge source, or all three. A lot of them are uninformative, because the authors start at the beginning and never get to advanced topics, so you have a lot of tutorials on how to make a basic block, but very few (if any) on how to add new items to the ore dictionary or render entities or add new crafting interfaces.

Read more... )
dragoness_e: Living Dead Girl (nasty bitch)
So Forge has updated from 1.9 to 1.9.4, which helps me decide--yeah, no more mod updates for 1.7.10, and no more porting to 1.8.9. Going to port directly to 1.9.4 from here on out.

It's too damn much work to keep three separate, incompatible ways of writing Minecraft mods straight in my head. Git is great for keeping the 3 branches of code separate, but I don't have a Git for my brain, so, one port to rule them all, one port to bring them all and in the compiler bind them. Long live 1.9.4!

Also, Mojang has already announced the first 1.10 snapshot, so as far as I'm concerned, 1.7.10 development is dead and overdue for burial.
dragoness_e: NASA F-15A #837 (NASA Starscream)
Just posted my 2nd Minecraft mod; this time, it's a port of someone else's code to Minecraft/Forge 1.7.2. akkamaddi has not been able to work on his mods, and he gave permission to all and sundry to pick up his open source code and update it. At my daughter's request, I ported akkamaddi's Sterling & Black. It was an interesting project, and I may pick up and port some of his other mods.
dragoness_e: NASA F-15A #837 (NASA Starscream)
Sinhika's Bark, which is a mod to add things to do with tree bark to Minecraft--including making unbreakable birch bark canoes. I actually started it some time ago, and had a semi-working version for 1.6.4, but never released it. Recently, at the request of some fellow players who were really annoyed by Minecraft's incredibly fragile boats (lilypads break them), I dusted it off, and re-wrote it as a Minecraft/Forge 1.7.2 mod and have finally released it.
dragoness_e: NASA F-15A #837 (NASA Starscream)
I have updated some old Traveller utilities, htmlsect and associated static library cworlddat, to actually compile under gcc4. Updated the Makefile to something more modern and standard, too.
dragoness_e: (Default)
For those of you that have totally forgotten this project, it's the DAOC mapping utility that I took over maintenance a long time ago, decided to overhaul, and fell off the Earth after Hurricane Katrina. I'm finally back to work on it; it was so close to release 3 years ago that it's heart-breaking; I'm sorry I never did put it out.

Continue here for those interested in DAOC MapperGUI 2 )
dragoness_e: (Default)
Okay, been poking at the Windows version of MapperGUI 2.99-beta and the newer incarnations of Python and wxPython.

1) I can't use Python 2.4 on the Windows side. I'm still running on Windows 98, and Python 2.4 extensions require MSC 7.1 & .NET SDK to be compiles. .NET SDK requires Win2000/WinXP/etc. Not an option for Windows 98. So, Windows version of MapperGUI is being tested with Python 2.3; I can't build a binary dist for Python 2.4. Beta testers, if you have the .NET 1.1 SDK and want to build the extension libs for the Windows version of MapperGUI 2.99 using Python 2.4, go for it! I just can't do it or test it myself, so my binary distros will be Python 2.3 based.

2) On Windows, wxPython 2.6.1.0-ansi with Python 2.3 has some flaked-out sizing bugs on the notetab controls, and looks like crap. Don't use wxPython 2.6.1.0 with Python 2.3 on Windows 98 with MapperGUI 2.99-beta. I have no idea how some other combo, like wxPython 2.6.1.0 with Python 2.4 on Windows XP, might work. Can't test it either, for reasons mentioned above. I'm testing with wxPython 2.5.3.1, which is the version I happened to have installed for the last while. It looks fine. If you find some earlier or later version of wxPython that doesn't turn into a pumpkin on the notetab controls, I'd like to know about it. If everything works peachy-keen on Windows XP, I'd like to know about it.

3) PIL 1.1.5 seems to work okay in both Windows and Linux with whatever version of Python & wxPython.

4) Using the latest everything on Linux (Python 2.4.1, wxPython-2.6.1.0, PIL 1.1.5) works fine. Looks good, builds extension libs okay, etc. I like Linux.

View this post on my blog

dragoness_e: (Default)
Okay, once I scrub out a few obvious bugs discovered during the last bit of alpha testing, I'll need some beta testers for MapperGUI 2.99b.

Requirements for beta testing:


  1. Python 2.3.4 or later installed

  2. PIL installed

  3. wxPython installed, plus whatever wxPython needs

  4. Must be able to manage without correct or coherent documentation

  5. Must be able to manage your own Python set-up.



Note that release version (for Windows) will have somewhat less stringent requirements, if I ever get py2exe properly integrated. Linux users get to manage Python libs themselves, as always. Beta code is subject to change and mutilation. It may eat your data, so work with a copy or backup of your existing stuff. (It doesn't, as far as I know, but I might manage to introduce an interesting new bug in the course of fixing/updating others).

What you will be testing will not have all the features of the release version; but I need to make sure that the core features are rock-solid. Oh, and I'm doing a last-minute change to how mapper.py is called that will probably screw up everything anyway, and we'll start over from square one with 3.00.01-beta..

If you are interested, e-mail me.

View this post on my blog

dragoness_e: (Default)
The MapperGUI overhaul is progressing apace. I've got most of the basic configuration dialogs done and working. What remains to be done: captions, install procedure, importing old ini-files, making dungeons work, various add-ons, actual help files. I also have some screenshots for your perusal.

Read more... )
dragoness_e: (Default)
Following the structure of a previous post, here's what's happened so far:

  • Structural Improvements - I've re-organized both the GUI and mapper itself along more modular lines. I've created proper __init__.py packages.  I will continue to do so with the overhaul.

  • Installation improvements - 'python setup.py build' and 'python setup.py install' will work when the next version goes out. I've already determined that distutils.py will properly build an extension library (using Visual C++ under Windows/gcc under Linux) without impertinent suggestions from me. Turns out I don't need a custom Makefile, I just need to give the right arguments to bdist_win...

  • Switch to a more capable GUI toolkit - Done that. I'm re-writing MapperGUI using wxPython instead of TkInter.  The wxPython toolkit is enormously more capable.

  • Overhaul the interface - I am in the process of doing that with the re-write using wxPython.  I will be using a notetab-type control for the mapper settings, and MapperGUI's own settings will be tweakable through a preferences dialog.  A lot of stuff that was hard-coded before, such as the location and name of mapper.py, the name of the intermediate output files, the default output directory, the command-line arguments for mapper, etc, etc, etc, will be configurable. In theory, you could drop in a different command-line driven mapper program as the backend. In actuality, it would have to take very similar arguments and settings, but, oh well. The new settings file will be in standard INI-file format (for now).

  • Overhaul the Caption Editor - I'm still just thinking nice thoughts about this, but it will be addressed after I get the basic re-write in order.

  • Hook in additional utilities - some of this is being built in already, as they are side results from processing DAOC game data files just to load the menus and draw the maps. Look for a 'Tools' or similar menu option in the versions to come.

  • Draw dungeons and Cities - I'm loading them into the menu, but disabled for now, as the capability to draw them is not going to be addressed until the basic re-write is done.  At least you can see their names and wonder what the heck some of them are for.

  • Update Help System - wxPython supports a beautiful HTML help system in both Windows and Linux. I'm using it. I have the framework working, but need to actually write some new help files (For testing purposes, I just cut and pasted from the relevant pages on Rath Nathrach)

...and there you have it. Testing this sucker is going to be a whole 'nother issue.  If I put a public beta version up, I'll need to make very clear that it is beta code, and likely to be buggy; I don't want people thinking it sucks because it doesn't work right when it isn't even finished testing.
dragoness_e: (Default)
One other candidate for a 'more capable' cross-platform GUI package is Tix.  The Python interface comes as a standard part of the Python library, but you have to install the Tix shared libs yourself.   One pro, one con.  It's an extension to Tk (and thus TkInter), so uses the same methodology as the existing MapperGUI controls. Another pro. However, it doesn't offer that many more new controls; notably, no help subsystem or HTML/RTF browser that I could use to build one. Another con.  Finally, Tix is as slow as mud on Windows Python... maybe it's that 'interpreted code invoking another interpreter to interpret code' thing. Another big con.

So..

  • Qt + PyQt:  Fast (if Kort's Spellcrafter is any indication), but working Windows version hard to get hold of.  I haven't gotten newer versions to run succesfully on Windows 98.  Not a good choice for cross-platform use.
  • WxPython: Fast, works on both Windows and Linux, very rich set of controls and widgets. May be somewhat complex to install; hopefully py2exe can help me package it all up into one installation package for end users. May be very complex for programmer to switch to--or not, as is structurally similar to MFC, which I have programmed with before.
  • Tix: Slow, works on both Windows and Linux, small set of controls and widgets. Very complex to install, as requires re-compiling Tcl, Tk and Tix from source--there are NO binary distributions available.  Only feasible on Windows side if py2exe can package up all the necessaries for end users.  Structurally similar to TkInter, which is already used in MapperGUI--but I'm not that familiar with it.
As you may have guessed, so far I'm leaning toward WxPython for cross-platform use.
dragoness_e: (Default)
To everyone who wanted to know if I can make it work with Catacombs: yes, DAOC MapperGUI will render Classic through TOA zones from Catacombs just like it did with the TOA client. Nothing has changed there. However, it will not render dungeon and city zones any better than it ever did, which is to say, not at all. Unfortunately, ALL of the new Catacombs zones are "dungeon" and "city" zones.

I am working on some improvements to DAOC MapperGUI. When I took over maintenance of the program from the original author.... well, as a Python programmer, I'm a great C/C++ coder. It turns out I knew only a little less about Python than the original author of the GUI interface--there's a lot that can be improved using really nifty Python features I knew nothing about before, but have been learning about from studying the code of Python coders who know what they are doing. Coders like Kort of Kort's Spellcraft Calculator fame.

Here's what I have in mind:


Read more... )

Profile

dragoness_e: (Default)
Dragoness Eclectic

June 2025

S M T W T F S
1234567
8910 11121314
15161718192021
22232425262728
2930     

Syndicate

RSS Atom

Tags

Style Credit

Expand Cut Tags

No cut tags
Page generated Jul. 5th, 2025 12:54 am
Powered by Dreamwidth Studios