SW version 3.3

[phantomwhale]

Ah ha - that's no graphics card bug.

SW v3.3 has introduced the adjustable size chat window - and now by default it will try to expand to fit a bigger screen. The extension may not have been correctly encoded to work with an adjustable size (before the chat window was fixed dimensions).

The workaround here is to right-click the chat window, unlock it, resize it until it looks "normal", and then lock it again (e.g. back to v3.2 functionality for now)

The fix is to actually adjust the extension to resize the image correctly - I'll nudge the author (doswelk) who should hopefully be able to get a fix arranged.

[Doswelk]

I thought I'd fixed that (I'm away from home until tomorrow), can you check the extension in the dropbox for me please PW?

Looking at the themes I do have on me I suspect all you need to do is change the graphics_frames.xml chatbox entry to:

	<framedef name="chatbox">
		<bitmap file="graphics/frames/chatbox.png" />
		<topleft rect="0,0,150,150" />
		<top rect="150,0,200,150" />
		<topright rect="350,0,91,150" />
		<left rect="0,150,150,200" />
		<middle rect="150,150,200,200" />
		<right rect="350,150,91,200" />
		<bottomleft rect="0,350,150,215" />
		<bottom rect="150,350,200,215" />
		<bottomright rect="350,350,91,215" />
	</framedef>

[phantomwhale]

I had a fixed copy in my local code share, but the shared version didn't seem to have that fix ?! I've added the fix in properly now, and uploaded it back into the share (as "fixed-again")

Anyone using this can either wait for Doswelk to submit this to Smiteworks as a patch, or if daring can open up the Sundered Skies theme (.ext) file with a zip program (I like 7-zip) and then edit the graphics/graphics-frames.xml file to contain the above code snippet instead of the existing one for the "chatbox" element. It's right at the top of that file.

[jwarlander]

I had a fixed copy in my local code share, but the shared version didn't seem to have that fix ?! I've added the fix in properly now, and uploaded it back into the share (as "fixed-again")

Hehe.. Git or Mercurial are great tools for version control.. Dropbox etc, perhaps not so much

Anyone using this can either wait for Doswelk to submit this to Smiteworks as a patch, or if daring can open up the Sundered Skies theme (.ext) file with a zip program (I like 7-zip) and then edit the graphics/graphics-frames.xml file to contain the above code snippet instead of the existing one for the "chatbox" element. It's right at the top of that file.

I went ahead and fixed the XML.. Seems to work great! *ponders* Now what else can be done in there, huh? Looks interesting!

Thanks

[phantomwhale]

Glad you could fix it

In my defence, all the Savage Worlds code I manage is in Git (tagged and branched) - I'd drown without it ! When it comes to collaborating with others, we've used Dropbox to share the artefacts (.ext and .pak files), but I keep a local Git copy of the source code for my own reference.

Happy to collaborate with other devs using Git, but only if they are comfortable using the tooling, of course.

[Ikael]

Hmmmm - are you sure ?

I thought I coded this to register the revert menu option when any elements of the module have been changed ? (e.g. so on load, or after a revert, the menu option should vanish, but as soon as you adjust any part of the module, the menu should reappear ?)

Nevermind, I found the part of code where it's registered and it looks fine

Another thing that I have had hard time is client-side options: the radiogroup setReadOnly doesn't work at all and client is able to set values to any options even if they are non-local. I suspect that utility_options.xml's option_entry_radio setReadOnly is never invoking the correct custom setReadOnly implemention in the template_radiogroup.lua, instead it's invoking windowclasse's setReadOnly and thus has no real effect on custom windowclasses. By replacing setReadOnly with setEnabled (reverse boolean value) I get the wanted effect but in that case radiogroups own readonly checking is skipped totally.

[phantomwhale]

Thanks for highlighting that - will probably give that some more love in SWEX 3.4 (and probably move over to a 4E style menu instead)

Right now, I believe if clients set options in the menu that are not client options, they are simply ignored (and reset when the menu is reopened). So whilst it's not great, I don't think it's worth me doing a last minute patch.

[grapper]

Expect you'll see SWEX 3.3 + extension updates first (via the FGII automatic updates button) and then SWD (which requires SWEX 3.3) should hit the stores a few days later - to ensure people have had a chance to upgrade SWEX and to avoid most of those inevitable version compatibility support requests !

Any word on the SWD module? Or is it in the store and I missed it? I started a space campaign a couple weeks ago and I am really looking forward to having the chase tool for spaceship combat.

[phantomwhale]

Waiting on two things - firstly a small patch to ensure FG v2.9.2 compatibility, and secondly trying to sort out pricing. Think it'll be a very good price. But nothing set in stone yet.

[heyhogan]

Is 3.3 suppose to have the chase tool? Also, I take it from other comments that the .58 extension from ikael does not work with 3.3? I am getting all sort of errors with it turned on now that I am running 3.3