Ship Interior Hook - A Proof of Concept

[alterecco]

Hello Prophet,

Thanks for taking the time to mull this over.

So, for starters, if you want to try the current version you can get it from
here

This is the version i am now working on, and it includes a rather large mod
that shows it's use. I will be posting a separate topic on this mod, so for now let me just go over what has changed.

The way a hook is defined is now through an item. As a concept i have dubbed them advertisers. Let me show you its syntax

Code: Select all

<ItemType UNID="&it-DSAdvertiser;"
	name=			"DockScreen Advertiser"
	frequency=		"notrandom"
	modifiers=		"ScreenHook; ShipInterior; CannotOrder; NotForSale;"
	>
	<Image imageID="&rsItems1;" imageX="0" imageY="288" imageWidth="96" imageHeight="96"/>

	<StaticData>
		<HookName>"DockscreenFrameworks"</HookName>
		<HookText>"Although scared, you can't help but look."</HookText>
		<HookScreen>"&dsSomePlotThatIs;"</HookScreen>
	</StaticData>
</ItemType>

This Advertiser is about as simple as it gets. The main points of interest are the modifiers and the <StaticData>. Lets start with the modifiers.

CannotOrder and NotForSale are required, since this item should never be in circulation (you don't want to buy a DSAvertiser!). What actually defines this item as an Advertiser is the "ScreenHook;" modifier. The "ShipInterior;" is an example of a hook that is being advertised. You can have any (sane) amount of hooks advertised in an item. Moving on to <StaticData>

In the <StaticData> we define the appearance and actions of this hook. There are quite a few fields that can be defined here, and they can all take functions. The advertiser above sets a title, subtitle and a target dockscreen. That is all it takes. Any screen that publishes "ShipInterior" hooks, will include this advertiser. Speaking of publishers, lets mention them.

A publisher is a screen that displays certain advertised hooks.
As an example, the overridden ShipInterior screen, publishes "ShipInterior" and "TerminalService" hooks. The hook screen itself has been abstracted away completely, so it is defined by the action that invokes it. As an example here is the action in the ShipInterior that invokes that screen.

Code: Select all

<Action name="External Interface" key="E">
	(block Nil
		(dsf_RunScreenHook 
			"&dsShipInterior;" 
			"Default" 
			'("+ShipInterior;" "+TerminalService;")
			"External Interface"
			"You feel a buzz as you hook into your External Interface")
	)
</Action>

Quite simple, this function sets up the necessary data for the Publisher screen. The arguments are: prevScreen, prevPane, hookList, screenName, paneDesc.
prevScreen, prevPane, paneDesc are optional and can be Nil (or left out in case ot paneDesc).

Off the top of my head, that is all there is too it. Try out the mod from the link above, and let me know if it makes any sense. It completely replaces the previous DockScreenHook files, so they shouldn't be played at the same time.

-------------------

So, I would like to comment some on the points you talk about.

The fact that this mod is *trying* to be "all-encompassing" is indeed it's biggest problem. Apart from the fact that I will use it myself, there is little point in releasing it as a framework if it doesn't suit people's needs. A game can only support so many mutually exclusive frameworks.

I have thought hard about the needs for building DS centric mods, and to this end I have built a DS Framework, that sits as an abstraction on top of the DS xml. Again, more about this in another post. You will find the framework included in the link above. The DSHook and the DSFramework will end up being one (almost are as we speak).

I have actually moved away from the randomized action naming. Not so much because I don't like it, but because for the ShipInterior screen (the only one i am working with at the moment) it became annoying and impractical.
It has actually been removed completely, and would have to be re-structured to work at the current moment.

On the idea of multiple actions, I kind of like it. My main problem with it is that having 8 or 9 actions on a DS, is more confusing than helpful (especially if they have randomized naming). As a solution to the 80000 hooks (that would be the day!) problem, I propose a filter. Eg. When a HookPublisher is set to show over a set amount of hooks, the default screen has a TextInput and a Filter action. This filter action shows only hooks with names matching the filter text. Then it would be quite simple to drill down to the required screen. (We could make something snazzy to avoid having to use the mouse).

Other than that, I don't think the ShipInterior DockScreen is mean't for combat lookups. A usable item with an Invoke Key is more suitable for that.
(and yes, an <Invoke key="B"> action *can* bring up a DS, almost every time )

So, enough about DockScreens for now. Look forward for you comments.

Have fun .]

[Prophet]

Your dsf is coming along very nicely. I have the G.O.D. mod and framework and it's working great. I haven't had any problems with it.

I would like to access the dsf from a station to create a more dynamic trade system and only be available when docked rather than from the ship interior. The funcionality of the dsf could allow for more complex pricing of commodities through functions to evalute supply/demand throughout the system, take into consideration the player's Korolov rank for product availability. Provide black-market goods if the player has the ID...

I haven't started on this project yet, I was having too much fun in Battlezone! Just got myself Notepad++ and Wings3D so I will be tackling the tradestation soon. Any suggestions would be appreciated and I'll keep you updated as to how the dsf is working for me.

Thanks.

[alterecco]

I would like to access the dsf from a station to create a more dynamic trade system and only be available when docked rather than from the ship interior.

Hi Prophet,

Thanks for trying this out. Look forward for your feedback.

At the moment i have not given much more thought as to how the screen hook part of DSF should develop. The description from the previous posts is still pretty much valid, the only thing that has changed, is the randomized naming, and the syntax for building the override screen. Other than that it's pretty much the same.

If you have full control over the makeup of the station though, then the easiest way to build the entire stations screens with DSF is illustrated by this example. Now that station is not utilizing the ScreenHook aspect, but just the base DSF. (i hope that made sense)

Code: Select all

	<StationType UNID="&stZoneManager;"
		dockScreen=		"Main"
                .......
		>
                ........
		<DockScreens>
			<Main>
				<OnInit>(dsf_ShowDockScreen scrZoneManager)</OnInit>
			</Main>
		</DockScreens>
	</StationType>

Irrelevant stuff replaced with ......

That is how easy it is.

I will be posting more on the framework after having rolled out the next BattleZone update.

I *do* hope you are using the version of DSF that is on xelerus btw. Quite a few things have changed. It will be the template for future versions, and I will try to keep breakage to a minimum (for my own sake mostly )

Feel free to ask any questions. They might shed light on an aspect i hadn't pondered yet

.]

[Prophet]

Thanks for the quick reply.
I'm using the current DSF. Replaced all the old stuff when I downloaded Battlezone and the GOD MOD.

I found an alternate way to get into the dsf. rather than on <Initialize> I built a single DS into the station with:

Code: Select all

<action> 
(dsf_ShowDockScreen MerchantEmporium)

This shows a picture of the station and some simple flavour text in the pane before I get into the hard stuff.

One question I do have is whether I can build an inventory dynamically within the DSF globals and not have to physically insert them into the station.
Did that make sense?
A normal station has tables/lists hardcoded and the items are all chosen when the station is created. Can a customPicker sell the player items that are not inside the station?
I'm not sure if you have these answers. I have my station started and will continue to fiddle with it.

[alterecco]

I found an alternate way to get into the dsf. rather than on <Initialize> I built a single DS into the station with:

Code: Select all

<action> 
(dsf_ShowDockScreen MerchantEmporium)

Yes, that would be an alternative, although that leaves you with one more step before you enter the framework screens. Of course, that may be a better solution in some cases. They both work, for sure, and there are probably others as well.

One question I do have is whether I can build an inventory dynamically within the DSF globals and not have to physically insert them into the station.

This can be done, but is not really a good solution. I fiddled with the same issue myself in building the item browser for the G.O.D mod. In the first attempt i built a customPicker screen, that displayed the items (that can be done without problems), but the problem is that the amount of information we can get from an item is very limited. It certainly doesn't match the information a player is used to from a normal inventory list.

The solution i came up with in the god mod, is a bit insane, but since it is a modding tool and not a "play" mod, i figured it was worth it. Basically, when you enter the item browser screen, we do a snapshot of the players current uninstalled inventory, removes it, and replace it with the items we want to browse. We then display the standard player itemPicker screen. Most importantly, we make sure that all paths away from the browser screen restore the inventory to the correct state. It is foolproof, unless the user crashes, or Alt+F4's in the browser screen. There is a workaround i will be trying for the next release, but I'm not sure it's perfect either.

Long story short: yes, it is possible to build an item browser in a customPicker screen, but if you want full item information, you will have to use a player or station itemPicker screen. Selling or buying should be quite easy to build in either case. For an example of the itemPicker screen, you can look at the god mod at around line 272 - that is where the itemType Browser starts.

.]

[Prophet]

I discovered that the itempicker draws it's lists from stations or the player and has alot of code hidden in the trascendence.xml for generating max# you can fit and afford etc. and realized that to produce a buy list dynamically would have to rewrite all that code in the dsf or just work with the vanilla buy/sell mode. I don't think this is a valid project for the dsf at this time as it is not (yet?) built for this. It works, but it takes longer. I'm gonna try some other approaches.

[alterecco]

I don't think this is a valid project for the dsf at this time as it is not (yet?) built for this.

I have been thinking about redoing the buy/sell screens in DSF. It is absolutely not a problem, most of the logic from the current buy sell screens can be ported directly. They could even be augmented to provide more functionality and feddback quite easily. It is in many ways *exactly* what DSF was built for. Creating complex screens with minimal configuration.

The itemPicker screen type is a built in screen type which provides a convenient way of browsing items on a ship or on a station. It in itself, has nothing to do with the buy/sell screens, other than it is the type being used to show the items.

[Prophet]

I'm currently building a Factory station using the DSF. I have an ItemPicker screen but am having difficulty setting variables from the selected item.

Code: Select all

		(eq screen "Mount");;;;Mount Selector
			(list
				'screenName	"Available Mounts"
				'paneDesc	"Please select one of your mounts to use."
				'screenType	"ItemPickerPlayer"
				'itemFilter	"*NU +Mount"
				'actions (list
					(list
						'name	'("Select" 'S)
						'runFunc	'(block Nil
						(setq rMount (scrGetItem gScreen))
				(dsf_ShowDockScreen (dsFactory 'Initial))
									)
					)
				)
			)

What code should I put into 'runFunc to store the unid of the item for use later (other functions on another screen)?

I can see now how much easier the dsf is to build Dockscreens with. It's just taking ME longer to write, but I'm learning fast.

[alterecco]

Hi Prophet,

Code: Select all

'runFunc	'(block Nil
  (setq rMount (scrGetItem gScreen))
  (dsf_ShowDockScreen (dsFactory 'Initial))
)

There are three ways i can see of solving that, which depends on the use case.
If the screen where you need to access that item is going to be show in the same DSF "session" or if you nee to access the item in a completely different screen, or you need the variable to be around after save/restarts.

The first use case might require a little explanation. The first time you show a DS, a ScreenState variable will be created, wherein values can be store for later retrieval. When you exit that screen, it will be cleared. No matter how many screens you navigate between, as long as you have not exited or overwritten the value, you can access it.

So, in the example above you could do something like:

Code: Select all

(dsf_SetScreenState 'rMount (scrGetItem gScreen))

Then in another screen, you can do:

Code: Select all

(setq chosenItem (dsf_GetScreenState 'rMount))

or:

Code: Select all

(setq chosenItem (dsf_RemoveScreenState 'rMount))

This allows you to easily pass values between screens, without polluting the global variable namespace.

Now, if you need to access it in a completely different screen, then you are basically already doing the right thing. The variable rMount that you set should be available anywhere.

If you need the variable to stick around, then you must write it to the ship or another spaceObject. Then you can access it anywhere, including inside a DS.

I really hope i didn't completely miss what you were asking for. Also, for quicker answers, try dropping in on IRC.

I can see now how much easier the dsf is to build Dockscreens with.

I would be really pleased if that is the case.

I realize it can be confusing to get used to a syntax developed by someone else, so i really hope it's not too unintuitive. I don't know if you looked at the DSFWalkAbout.xml? If you did, i would appreciate a comment on it. Was it too much? Would a short reference be more usefull? That kind of thing

.]

[Prophet]

Hi alterecco,
Thanks for the quick reply, it will be very helpful.

I have your DSFWalkthrough and have been referencing it as well as the GODmod for help/ideas. The quick tuto was put together well and was easy to follow. The reference was very helpful as well. I have no experience writing code besides fiddling around in NeverWinter Nights so if I could understand it I'm sure someone with at least a foundation would have no problem understanding it. I think when you decide to officially release the DSF a simple, concise reference would be more useful than the tuto and preamble. In my case, I wasn't accessing the DSF through the ShipInterior so the Advertiser wasn't relevant and that is really only one small use for the Framework.

I have been thinking of my next project for the DSF. An advertiser that can be bought, then accesed through the ShipInterior. A CustomPicker list of random Missions, like an online/virtual Classified Ads. But that's for another day...

Thanks for the help. If I have more questions I'll try to find you on IRC.