March Beta Release in Test

[Jiminimonka]

Extensions = RISK

That is what I was about to type

[SilentRuin]

Extensions = RISK

True. For people who use them for sure. But I grow jaded at the utter disregard of extension code already stable and out there where FGU just rewrites stuff with no documentation on what was done or how to navigate the changes. They just do them without a care in the world. For example...

record_npc.xml was changed

Let's say you were doing something super simple and adding your own text field so it could optionally be expanded for parsing links into text in the main_creature page.

<windowclass ruleset="5E" name="npc" merge="join">
<script file="campaign/scripts/npc.lua" />
<sheetdata>
<subwindow_record name="subwin_text" insertafter="main_creature">
<class>other_tab</class>
</subwindow_record>
</sheetdata>
</windowclass>


Well now, main_creature no longer exists. In fact, the tab for this has not only been renamed but done in a completely different way where you can't even add something before the named "text" field because its been obfuscated and broken apart into several different areas. In fact, the main tab itself has apparently completely lost the previous <ft_record name="text"> I was trying to insert before and I still have yet to find it but suspect after 30 minutes of looking that its some how indirectly being done through some of these record templates - possibly.

So while Extension = RISK - rewriting chunks of code that extensions are inserted into with NO direction on how to understand where the previous fields and such have gone (as they also tend to rename stuff for some insane reason instead of preserving the names and just changing what they do) - well...

I've ranted enough. This is going to really suck. I want to have a stable platform where things I hook into are recognized and preserved or at least given direction on understanding the functionality hooks that were lost.

[Jiminimonka]

I've ranted enough. This is going to really suck. I want to have a stable platform where things I hook into are recognized and preserved or at least given direction on understanding the functionality hooks that were lost.

I understand your point. I think they are working on it, this is a major improvement to FGU, but Smiteworks has to iron out 20 years of FGC wrinkles and its getting smoother all the time.

[damned]

I understand your point. I think they are working on it, this is a major improvement to FGU, but Smiteworks has to iron out 20 years of FGC wrinkles and its getting smoother all the time.

Many of these wrinkles provide no change to the UI (excluding the broken extensions and rulesets) or User Experience - particularly to Windows as opposed to Images where functionality is being added. They require substantial time for devs to relearn changes and reimplement code to be at the same point of function as they were prior to the update. Significant time invested and no benefit to dev or to end user.

I put out about 10 rulesets over 2021 and 2022.
I did not release one new ruleset in the last 12 months.
I made plenty of new rulesets but have not shared them.

I am completely frustrated by the whole process.
Rather than these changes making things easier for developers I think the reality is completely opposite.
Yes the new code is smarter and cleverer - but much of it doesnt add any functionality - but breaks everyone elses code.

I love this platform, I enjoy coding for it, I like making new systems available for other people to use, but having to rewrite stuff all the time is no longer fun or worth my time.

[SilentRuin]

Many of these wrinkles provide no change to the UI (excluding the broken extensions and rulesets) or User Experience - particularly to Windows as opposed to Images where functionality is being added. They require substantial time for devs to relearn changes and reimplement code to be at the same point of function as they were prior to the update. Significant time invested and no benefit to dev or to end user.

I put out about 10 rulesets over 2021 and 2022.
I did not release one new ruleset in the last 12 months.
I made plenty of new rulesets but have not shared them.

I am completely frustrated by the whole process.
Rather than these changes making things easier for developers I think the reality is completely opposite.
Yes the new code is smarter and cleverer - but much of it doesnt add any functionality - but breaks everyone elses code.

I love this platform, I enjoy coding for it, I like making new systems available for other people to use, but having to rewrite stuff all the time is no longer fun or worth my time.

100% agreed. Though I use my extensions so am forced to keep trying to get them to work after updates. 5 hours in and I'm still not past porting the first extension. Keeps coming up with something new - toolbar - then npc sheet - now ct... it seems one step forward two steps back.

[Moon Wizard]

I have to disagree that they provide no benefit to the UI or user experience. In fact, I've received several mentions that the UI experience is improving through the changes that are being implemented as part of these changes to standardizing the templates, which allows us to standardize capabilities across multiple windows.

I have offered to all developers (but especially ruleset developers) to assist with the porting efforts, in order to answer questions and help with implementation. Most of them take me up on this offer, and I can help refactor the code to work with the new templates, usually while cutting out a lot of extra definitions no longer needed. Plus, setting up new record types is much faster, with less code duplication.

Specifically for the "tabbed" record sheets, I implemented a tab manager script which pulls the tab data directly from the windowclass XML data. Let me know if you have any questions about it.

Regards,
JPG

[Jiminimonka]

Better documentation would be good and maybe giving devs a little more time too. The improvements are good for FG (especially for those who complain about the UI) - maybe some more information on changes ahead of time.

I noficed character sheet tabbing is faster now. Used to be 1 or 2 second delay switching between tabs.

[SilentRuin]

Wow. I've spent 2 days already and only on 2nd extension. I've spent uncounted hours trying to reverse engineer the toolbar now and had to trial and error my way into a solution for adding my on map toolbar button - and then intercepting the press of an existing one. I'll give you a hint... I came up with this disaster to hook into the call back for a button.

	local Button = ToolbarManager.getButton("image_target_select");
	saveonToolbarTargetSelectValueChanged = Button.fnOnValueChange;
	Button.fnOnValueChange = onToolbarTargetSelectValueChanged;

Knowing nothing about any of this new toolbar stuff you can imagine how long and how many tries it took to trial and error my way into that. Maybe all of you are just smarter - but for me - this is the perfect example of how complex and mind boggling it is to "guess" your way into doing something that was working fine before the update.

Obviously I'm not done yet with this toolbar stuff as I will have to figure out how to prevent the other calls from processing if mine does (old world it was message based for button press and you could just return true or false to let it know if it needed to process the other stuff - now I'll just have to call or not call the function I'm overriding).

[Moon Wizard]

After getting initial information from @SilentRuin, I just reordered some of the toolbar button initialization to happen later in the initialization process. The new code is simpler. (See below)

For anybody adding buttons to the toolbar, see the imagewindow_toolbar window class and ImageManager script before changing anything. I've noted that in the Update notes for developers as well.

function onInit()
	...
	registerToolbarUpdates();
end

function registerToolbarUpdates()
	saveonToolbarTargetSelectValueChanged = ImageManager.onToolbarTargetSelectValueChanged;
	ImageManager.onToolbarTargetSelectValueChanged = onToolbarTargetSelectValueChanged;

	ToolbarManager.registerButton("image_toolbar_button_lastptrdata_clear", 
		{ 
			sType = "action",
			sIcon = "tool_lastptrdata_clear",
			sTooltipRes = "image_tooltip_toolbarlastptrdata_clear",
			fnActivate = onToolbarLastptrdataClearPressed,
		});	
end

Regards,
JPG

[SilentRuin]

After getting initial information from @SilentRuin, I just reordered some of the toolbar button initialization to happen later in the initialization process. The new code is simpler. (See below)

For anybody adding buttons to the toolbar, see the imagewindow_toolbar window class and ImageManager script before changing anything. I've noted that in the Update notes for developers as well.

function onInit()
	...
	registerToolbarUpdates();
end

function registerToolbarUpdates()
	saveonToolbarTargetSelectValueChanged = ImageManager.onToolbarTargetSelectValueChanged;
	ImageManager.onToolbarTargetSelectValueChanged = onToolbarTargetSelectValueChanged;

	ToolbarManager.registerButton("image_toolbar_button_lastptrdata_clear", 
		{ 
			sType = "action",
			sIcon = "tool_lastptrdata_clear",
			sTooltipRes = "image_tooltip_toolbarlastptrdata_clear",
			fnActivate = onToolbarLastptrdataClearPressed,
		});	
end

Regards,
JPG

Replaced my workaround with this - and it works.