Summoner/Carrier Mod

[Styro]

Good call. I can probably also tag the wreck with the UNID of the ship it came from at the same time.

[Styro]

Well, this OnObjDocked stuff does not seem to work and has started to make Transcendence unstable.

My best guess from reading through the code is that OnObjectDocked is meant to be fired on a station when an object it is has registered docks with it. So a Commonwealth station will register the player when a mission starts and OnObjectDocked will fire when the player docks with that station.

I cannot find a way to trigger an event on the ship when docking happens. So I will probably just have to come up with some other method for learning new ships.

[Prophet]

How about having a special type of ship that the mothership can spawn that will auto scan wrecks. Each wreck will add to the knowledge of that ship design and once you achieve enough scanXP, you learn a new ship type?

[alterecco]

Sorry, I did not really come with a useful answer. Using OnObjDocked is a bit tricky. I posted here some sample of what I use myself. I call it dockscreen interception, and it works quite well

http://transcendence.pastebin.com/pR6aYdMV

[Styro]

Interesting... So if the criteria are met that will open up the dsScreenWhereILearnNewShips screen when the player docks with something? Supposing that it fires when I dock with a wreck and the criteria are met. Does the normal Loot screen still show at some point, or would I have to dock again with the wreck?

I have in the mean time just implemented an auto-scanner which just displays a message that wrecks are being scanned by the carrier ship.

But my main problem is that I seem still have instability problems. Transcendence still freezes on me occasionally. I'll have to spend some time trying to figure out what I have messed up.

[alterecco]

If the criteria are met you can redirect to whichever dockscreen you want. The normal loot screen would be completely bypassed and it would be up to you to provide access to it.

Another solution would actually be to override the dsLoot screen, as it is only used when the player docks with a wreck. You could then customize it to your hearts content.

Scanning the system frequently and registering for events with a lot of ships is not without problems. I have recently run in to the same issues, and I did not have time to look into it. My suggestion would be to avoid it if at all possible.

If T freezes on you it may be because you are getting a lot of output in your Debug.log... usually that is when I experience the game grinding to a complete stop. Or if you have some particularly long running piece of script.

[Styro]

Yes, things get a little choppy when I am trying to do a lot of stuff. I was also writing a lot to the debug log, so hopefully when I comment that stuff out it will be a little smoother.

I did find a few things causing me problems, though. I had a couple variables uninitialized and there was one instance where I ended up in an infinite loop (which is what caused the freezing).

Now I am trying to play-balance the ship learning to see how slowly or quickly things need to happen to keep the challenge there but also make it winnable. Of course you are flying a capital ship so it is certainly winnable, but hopefully the wingmen will still be useful near the end-game.

[Styro]

Well, commenting out the debug log statements got rid of the choppiness. Now it is nice and smooth.

I have run into a strange problem. When I have scanned enough wrecks to learn a new ship, I call shpInstallDevice to install the new launcher, but the call is failing. I tried putting in a call to shpCanInstallDevice to see what the problem is, but it returns a 0, meaning it should be able to be installed.

Code: Select all

(dbgLog "can install? " (shpCanInstallDevice gSource launcher))
(if (not (shpInstallDevice gSource launcher))
	(dbgLog "install failed"))


02/25/2010 14:25:15	can install? 0
02/25/2010 14:25:15	install failed

I have verified that the variables are set - gSource is my carrier ship and launcher is the new launcher item (misc device). Any ideas?

Here is the code for the launcher in case that is important:

Code: Select all

	<ItemType UNID="&itCentauriRaiderFighter;"
			name=				"Raider launcher"
			level=				"1"
			value=				"0"
			mass=				"0"
			frequency=			"notrandom"
			numberAppearing= 	"1"
			modifiers=			"MajorItem; CarrierLauncher; Fighter1"
			
			description=		"Launch a Raider."
			>

		<Image imageID="&rsCentauriRaiderImage;" imageX="0" imageY="0" imageWidth="48" imageHeight="48"/>

		<MiscellaneousDevice
			powerUse=			"0"
			deviceSlots=		"0"
		/>

		<StaticData>
			<FighterUNID>&scCentauriRaider;</FighterUNID>
		</StaticData>
	</ItemType>

[alterecco]

Yeah, that is a big tricky... You need to add the item to the ship before you can install it. So:

Code: Select all

(objAddItem ship itm)
(shpInstallDevice ship itm)

That should do it.

[Styro]

Heh, it seems so obvious. Yes, that fixed the problem nicely. But of course more have turned up.

I thought I had gotten things mostly working, but once I leave the first system things break down. The log file starts giving me the error "Save file error: Saving reference to object in another system" over and over. And my wingmen bail on me after their first order (just leave the system).

My gut tells me that the error comes from either the enemy ships that I have registered for events in the previous system or the tie between wingmen and carrier. The wingmen leaving is their normal behavior if there were no OnBehavior event setup in their behavior class which fired. But of course all that stuff was working fine in the first system and the normal in-game wingmen do not seem to have any other code I am missing.

This is where the lack of documentation and features is really sucking the fun out of writing this mod. If there were an OnKill or OnDock event I could tap into there would be no need for all this other crazy enemy tagging. If Invoke could open a dockscreen I would not have to try to replicate the fuel use and capacitor recharge that I get from Invoke since I am using a dockscreen.

I would just scrap all this and rewrite it using a few custom ships so I could avoid all the "learning of new ships" stuff, but then I still run into the problem that the player's kills (which determine score and without which you cannot progress in the Arena) still do not count the wingmen because there is either no way to count them or there is no documentation on the function that could be called. And I would still have to figure out why my wingmen link is not surviving through the first gate.

I know it's pretty lame to complain about lack of features and documentation in a free game. But I have been so impressed with the game's polish otherwise that I guess it just took me by surprise.

In any case I will probably come back to this mod when I understand more.

[alterecco]

You have definitely run into some of the pitfalls of T modding. There are many places where it is lacking, or working backwards. There is very little that can not be done, you just need to do some of the bookkeeping yourself. I must say that from what I have been able to determine of your progress you are doing fine :)

Once more, IRC is a nice medium for discussing and troubleshooting specific scripting issues, so feel free to drop by there anytime.

As for the problems you have run in to, I might have some suggestions:

An object such as a ship in T has two representations, a spaceObject and an objectID. The spaceObject is only valid for this one session (so, if you quit and restart the value will be void), and does not carry across systems. ObjectID's can be gotten from spaceObjects and are persistant across the game. They do however not carry over a system either. Have a look at the functions objGetID and objGetObjByID

For the most part I have stopped using spaceObjects and use objId's instead. At least anytime I am even thinking of saving that object for later use. I also do a fair bit of error checking if the object references I use are actually still valid before I begin to assume anything...

Let me make an example

Code: Select all

;; get the current target of a ship.
(setq target (objGetTarget myWingmanShip))
;; target is not a spaceObject pointing to the wingmans target

;; save the target for some reason, but convert it to a objID first
(objSetData myWingmanShip "CurrentTarget" (objGetID target))

;; now, at a later point I want to retrieve that target

;; start by retrieving the data
(setq targetID (objGetData myWingmanShip "CurrentTarget"))

;; now convert it to a spaceObject
(setq target (objGetObjByID targetID))

;; if target is Nil now, then the ship either does no exists any more, or it is existing in another system and therefore "suspended" so to speak
(if (not target)
  (dbgLog "Failed to re-aquire target")
  ;; else do something
)

OK, that example is pretty lame, but I hope it shows the fundamentals of using objID's :)

No doubt T could use more documentation, but in some twisted way finding out what is possible and what is not, and coming up with some hack to do what you want is part of the fun (for some at least)

As for scrapping it and rewriting it with custom ships I think that would be a shame. What you want to do is possible, you just need to handle it properly, which might not actually be a simple task... Pastebin some code, come on IRC or ask your questions here and perhaps there is help to be gotten :)

[Styro]

Well, after taking a break to finish my Barcode Scanner mod, I came back to this.

Using objID worked perfectly! All the wingmen problems were resolved quickly once I went through and replaced the object references with objID refs.

With all that I learned about Dockscreens from the Barcode Scanner mod, I completely revamped the launching mechanism and I think it is quite nice now. It is all controlled from one Carrier Command device from which you can launch fighters, see stats on your launched fighters, and see details on what fighters you have researched and are researching.

I have uploaded a working version of the mod to xelerus. Please take a look and tell me what you think.

http://xelerus.de/index.php?s=mod&id=704

I have only gone through the first couple systems, so in particular I am curious what others think about how it scales in terms of gaining carrier levels, learning new ships, and if the fuel cost for launching is too low or too high.

I have built-in the ability to launch 18 different ships. You start with one (the Hornet Battlepod) and can learn the other 17 from wrecks. It is extremely easy to add additional ships to learn.

[Styro]

I am still getting these errors when I go through a stargate.

Code: Select all

03/03/2010 20:28:59	Save file error: Saving reference to object in another system
03/03/2010 20:28:59	Object being referenced:
03/03/2010 20:28:59	obj class: unknown
obj name: unknown
obj pointer: 338fe00
error obtaining crash info

Any ideas what could be causing them? I thought I had removed all references to specific objects, but obviously something else is still doing that.

The only object-type reference I can find digging through my code is when I call objRegisterForEvents on enemy ships. Do I need to unregister them somehow when leaving the system?

Eventually, my game crashed. I do not know if it is related to those errors or not, but I figured that it would be a good place to start looking. Here is the error I got at crash, but it does not seem to directly tie to anything I recognize. The Antares Heavy 176 is a freighter in KorolovShipping.xml, but probably not one I would be tracking as an enemy.

Code: Select all

03/03/2010 20:31:14	Unable to continue due to program error

program state: updating object behavior
obj class: CShip
obj name: Antares Heavy 176
obj pointer: 9d02208
CStandardShipAI
Order: 2
m_State: 11
m_pDest: none
m_pTarget: none
m_pNavPath: none
game state: in game

[alterecco]

Hmm, it does look like there is one object that you missed. I am not sure though. I would try unregistering when leaving the system also. I recently tried registering a ship for events on all other ships in a system, and it caused the game to crash nastily when entering another system. I did not try unregestering yet, but I can only imagine that it would work. That aside, I think that objSetObjRefData could also cause that crash, so if you use it somewhere, try to switch it out with a objID (i am not sure, but it is maybe worth a try)

[Styro]

Yes, I already got rid of all ObjRefData calls (get and set). I will try to unregister the enemy ships when leaving a system to see if that fixes it. Previously, I had been getting errors when trying to unregister enemy ships, but that was when I was just starting on this mod, so maybe it will go better this time.