Patching extra functionality into <gamemd.exe>

[jonwil]

after investigating a lot of things and figuring out what I can and cant fix, I am going to do these 4 things next I think:
Implement TiberiumToSpawn=
Look for the mouse cursor stuff
Make new overlays possible (including abillity to specify them as bridges etc, perhaps an IsBridge tag to indicate high bridges)
plus Make new bridges possible (i.e. bridge end settings in the theater ini files etc)

[Blade]

How will the game know what overlay to draw when it repairs a bridge unless you either hardcode it into the new bridge end settings (eg train bridge uses train bridge overlay) or somehow have a system that tells the bridge heads what overlay to use or tell the overlay what bridge heads to associate with.

[pd]

I tried to enable tank bunker for hovers and non-powered units.

The "enter" mouse cursor displayed, the unit moved towards the bunker.
But once the it reached the building, it stopped.

So there has to be more avoiding that hovers can enter a bunker.
No idea what or where it is thought :\

[Bobingabout]

i like that, desirable features would include:
SensorSight= not automaticly creating sensors
Sensors=yes
Cloakable=yes
CloakGenerator=yes
CloakRadiusInCells=12; is this 10? or is the limit larger?

CloakType=Navel(default) or Cloak(land)
SensorType=Navel(default),Cloak; array type to allow units to detect both.

possibly the ability to add more for cloaks of different types (IE in startrek enterprise, they need different cloaking sensors to be able to detect sulaban cellships, romulan mines, and romulan ships)

and cloaking sound definable on the unit/building and use the 1 listed in [general] as a default.

all these tags being able to work on buildings, cloakgen doesn't need to, but would be nice if it also worked on units... also, aircraft seem to hate this, and hover units don't cloak, unless they land, by either repairing on repair pad, or in case of robots, deactivating.

[jonwil]

Here is all the functions and data locations I have regarding overlays and bridges, posting them here so that we can keep track of them
005FC380 is CreateOverlayClass (creates an OverlayClass from an OverlayTypeClass)
005FD2E0 is ReadOverlayData (function to read the overlay data from a map file, unpack it and do stuff like creating all fhe OverlayClasses
005FE250 is CreateOverlayTypeClass (createa an overlay type class)
005FE620 is LoadOverlayShps (loads the graphic shp files for overlays)
005FE770 is CreateOverlayType (which is what reads the data in from the ini file for an overlay entry)
00568E40 is RepairHutRepairConcreteBridge which is the code for the bridge repair hut when used on concrete bridges
00569760 is RepairHutRepairWoodBridge which is the code for the bridge repair hut when used on wood bridges
00587180 is BridgeWarheadStuff which is used for making bridges blow up (I think)
005FD4D7 is BridgeOverlayStuff which is one of the bridge related subroutines
0073F1D5 is BridgeOverlayStuff2 which is one of the bridge related subroutines
0048A0A5 is BridgeOverlayStuff3 which is one of the bridge related subroutines
005FC570 is BridgeOverlayStuff4 which is one of the bridge related subroutines
00489F07 is BridgeOverlayStuff5 which is one of the bridge related subroutines
0056703E is BridgeOverlayStuff6 which is one of the bridge related subroutines
0047BE89 is PossibleBridgeOverlayStuff7 which might be one of the bridge related subroutines
0047C0AE is PossibleBridgeOverlayStuff8 which might be one of the bridge related subroutines
These are where the data from the relavent theater ini keywords are stored
00AA0740 is BridgeTopRight2
00AA0E28 is BridgeSetStartTile
00AA0E38 is BridgeBottomRight2
00AA1028 is BridgeMiddle2
00AA1130 is BridgeTopLeft2
00AA1540 is BridgeBottomLeft2
00AA1548 is BridgeTopRight1
00ABAD1C is WoodBridgeSetStartTile
00ABAD30 is BridgeMiddle1
00ABC1D0 is BridgeBottomLeft1
00ABC1E8 is BridgeBottomRight1
00ABC2B4 is BridgeTopLeft1

[pd]

Hm...
As you (jonwil) know, I'm working on my huge table.
I'm just wondering if I should include such information as well?

[~Guest~]

i thought your table was for tags? these are functions, but if you doing those too, go ahead and add them

[pd]

I'll see.

Anyway, good news for everybody: I got the mouse frames!

[pd]

Erm, sorry for the double-post, just a few news:

I overworked a lot of code now to prepare the implementation of custom mouse pointers.
Yep, I understood how the mouse pointers work and I think I'm able to make them customizable.
Though, it's going to be the most feasible thing I've ever done, so wish me luck

I planned to build up the stuff like this:
ActionName=SF,NoF,I,MMF
SF = starting frame of the mouse pointer in mouse.sha
NoF = number of frames, for animations. set them to 1 would mean no animation.
I = animation interval, in frames
MMF = minimap frame of the pointer in mouse.sha, set to -1 would mean that there is no minimap pointer.

ActionName would be the name you enter for the Action= tag for superweapons then.

Example:

Code:

[MousePointers]
NewParaDrop=260,10,4,517;for a cloned ParaDrop action

[SuperWeapon]
...
Action=NewParaDrop

The code I've overworked includes a few fixes of bugs which could have been reasons for Internal Errors (not sure about that).

Besides, note that I changed the tag names "Spyplane=" and "SpyplanesNum=" to SpyPlane= and SpyPlanesNum=, to be correct.

I will inform you about new stuff as soon as there is some

[Renegade]

That...sounds pretty fucking l33t.
Although I have one question: If you're this far...how hard would it be to make new mouse cursors callable from weapons, like C4 or the Boris-cursor?

[CannisRabidus]

...And, to add an alternate cursor for the new cursors, to indicate weapon out of range?

[Bobingabout]

lol...

some good points there though.


@ren do you mean create new weapons with costom cursers, or just edit the existing ones.

@PD remember, every action can have upto 4 possible cursers:
Can do it
Can't do it
Can do it MiniMap
Can't do it MiniMap

some things use an attackmove, but i think this is a seperate action...

but imo, you should have a list to create actions, then another list to be able to edit cursers, like an array system

[Actions]
0=newpara1
1=newpara2
2=newspyplane

[newpara1]
AttackMouse=blah blah blah
InvalidMouse=Blah Blah Blah

and so on. this way you can edit existing actions if you know their name. also, tags should be unique, so if you add the action to be the same name as the superweapon, you can add these tags to the superweapon itself.

*remember crazy things, you can create an infantry, building and a (SHP based)tank with the same codename, and still have 3 seperate objects, but they share the [***] listing, so are resticted to same health and so on. infact, it is possible to create animtoinfantry to a units codename if you add the apropriate tags, just might act strange.

[Speeder]

I see that custom cursors for superweapons are near... What about custom cursors for weapons? I think that bobing's concept is best, it could be also used for standard weapons

[Renegade]

I was referring to mouse cursors attached to/activated by flags like SabotageCursor=yes or MigAttackCursor=yes.

[CannisRabidus]

I was referring to mouse cursors attached to/activated by flags like SabotageCursor=yes or? MigAttackCursor=yes.

Ahem. I said this on the last page:

10.Mouse cursor stuff (e.g. caryall logic sequences, heal action sequences, custom cursors for custom actions etc)

Need a [Cursors] list. Then weapons can use CursorIndex=N, which refers to a cursor on the list. This would be the most versatile, IMO.