Staredit Network > Forums > Modding Discussion > Topic: The GPTP Rises Again!
The GPTP Rises Again!
Apr 3 2015, 8:22 pm
By: A_of-s_t  

Apr 3 2015, 8:22 pm A_of-s_t Post #1

aka idmontie

Hey there modding community!

I've migrated the General Plugin Template Project (GPTP) from Google Code which is being shutdown, to GitHub!

In the process, it was transformed from a SVN project to a Git project, I lost all of the usernames for the commits, and I had to remake the wiki.

What is the GPTP?

It is a General Plugin Template that gives you common structures, functions, and hooks for you to write your own Starcraft Mod in C++. There are plenty of examples and there is lots of documentation in the repo and the wiki (no thanks to me).

From the wiki:

Quote
The General Plugin Template Project (GPTP) is a sample Visual C++ project for creating StarCraft: Brood War mods. GPTP gives mod makers control over numerous aspects of the StarCraft game engine.

GPTP is built as a plugin file (a DLL with a *.qdp extension) that can be loaded with MPQDraft or FireGraft for creating a mod executable file. When the mod executable is run, it calls StarCraft and injects the plugin(s) into the game, at which point the plugin takes over.

GPTP uses hooks to inject and run custom code into StarCraft.exe's memory. From then on, the game will use the injected code for processing units, commands, and events.

The Future of the GPTP

It looks like this project was last worked on a year ago. I will be picking it up and maintaining it. I do have a lot to catch up on though after my 5 year modding hiatus.

If you would like to help me maintain it, please don't hesitate to ask.

If you would like to add new features, fork the repo, make a feature branch, and then submit a pull request to merge it back in! It's way easier to to this in Git and GitHub than it was with SVN and Google Code.

What you can do to help!

If you know the GitHub usernames of the original commmiters, please PM me so I can give them write access to the GitHub repo.

Please help me decipher these autocreated issues made by the GoogleCodeExporter. I'm unsure whether I can close the issues or not since they are all marked with "auto-migrated", which makes me assume that the patches were merged into the code. But I'm no expert in how people use issues with SVN.

EDIT: These issues are uncompleted pull requests that we will need to manually test and merge into master.

If you want to contribute, just PM me your GitHub username and I can give you write access to the repo.

Links
Edit:
Welcome the following to the GPTP team:

Post has been edited 3 time(s), last time on Apr 4 2015, 4:57 am by A_of-s_t.



Personal GitHub
Starcraft GitHub Organization - Feel free to request member status!
TwitchTV

Apr 3 2015, 9:20 pm Sand Wraith Post #2

she/her

Wrt auto-migrated patches:
https://code.google.com/p/gptp/issues/detail?id=31
I examined this issue's *.patch file (it's just plaintext) and compared it to the source code both in the GPTP on Google Code and on the Github. Judging by the appearance of the look syntax of the *.patch file, it would seem to me that the "auto-migrated" issues have not actually been applied to any of the source code files. The lines that seem to have been proposed to be added in the *.patch file have not actually been added to the corresponding file.




Apr 3 2015, 9:23 pm A_of-s_t Post #3

aka idmontie

Ok, so we need to manually merge these pieces of code in then. Git does not have a concept of "Patches", it uses branches instead. I recommend merging in these patches in a new branch (not master).

I think this should be it's own GitHub issue so we can track it's progress. There are a lot of these open patches.

P.S. make sure to accept the GitHub team request.



Personal GitHub
Starcraft GitHub Organization - Feel free to request member status!
TwitchTV

Apr 3 2015, 11:28 pm poiuy_qwert Post #4

PyMS and ProTRG developer

What really needs to be added to GPTP is a centralized hook manager, so that more than one plugin can use the same hooks without interfering. The general concept is that when a user goes to make a hook to their function through the hook manager, instead of adding the hook to that function, it would add the function pointer into an array and actually hook to a function on the manager which would call all the functions in that array. Of course it would be more complicated then it sounds because the plugins are independent dlls and there would have the be some shared interface between them all.

I don't think i'll be able to contribute directly since I'm on a Mac but I can give some ideas and advice.




Apr 3 2015, 11:33 pm A_of-s_t Post #5

aka idmontie

Quote from poiuy_qwert
What really needs to be added to GPTP is a centralized hook manager, so that more than one plugin can use the same hooks without interfering. The general concept is that when a user goes to make a hook to their function through the hook manager, instead of adding the hook to that function, it would add the function pointer into an array and actually hook to a function on the manager which would call all the functions in that array.

Similar to how jQuery handles attaching events? Yeah, that's a good idea. But is there some way to get it to work with FireGraft hooks since FireGraft is not using the manager?

I will definitely make this an issue that we will tackle though. Here is your issue on GitHub.



Personal GitHub
Starcraft GitHub Organization - Feel free to request member status!
TwitchTV

Apr 4 2015, 3:35 am Sand Wraith Post #6

she/her

Quote from A_of-s_t
Quote from poiuy_qwert
What really needs to be added to GPTP is a centralized hook manager, so that more than one plugin can use the same hooks without interfering. The general concept is that when a user goes to make a hook to their function through the hook manager, instead of adding the hook to that function, it would add the function pointer into an array and actually hook to a function on the manager which would call all the functions in that array.

Similar to how jQuery handles attaching events? Yeah, that's a good idea. But is there some way to get it to work with FireGraft hooks since FireGraft is not using the manager?

I will definitely make this an issue that we will tackle though. Here is your issue on GitHub.

I feel like a potential solution is running Firegraft's EXE edits through a Firegraft plug-in that, itself, goes through the proposed plug-in management system.




Options
  Back to forum
Please log in to reply to this topic or to report it.
Members in this topic: None.
[10:32 pm]
RIVE -- :wut: Things you'd never expect to hear.
[07:24 pm]
SiKiN -- What a legend
[07:19 pm]
NudeRaider -- wow good catch demon
[04:20 pm]
SiKiN -- I has problemo http://www.staredit.net/topic/17835/
[03:18 am]
Pr0nogo -- it's always unlogged me after 180 days
[02:59 am]
O)FaRTy1billion[MM] -- wtf why did i have to log in
[2019-6-19. : 8:23 pm]
NudeRaider -- Moose
Moose shouted: it is of higher quality and caliber
jesus you must be really bored to have read that shit. Or ... you actually enjoyed it. AND HAD FUN?!
[2019-6-19. : 8:22 pm]
NudeRaider -- NudeRaider
NudeRaider shouted: lil-Inferno listen here you shit ... :P actually just read some of my comments. Many of them are universal and have nothing to do with mapping vs modding. That just happens to be our example.
tl;dr your priorities are not better than mine
[2019-6-19. : 8:21 pm]
NudeRaider -- lil-Inferno
lil-Inferno shouted: Given your idea of fun is arguing the merits of mapping vs. modding (two completely different things) in a game that's old enough to drink legally, ya, probably
listen here you shit ... :P actually just read some of my comments. Many of them are universal and have nothing to do with mapping vs modding. That just happens to be our example.
[2019-6-19. : 8:18 pm]
lil-Inferno -- Given your idea of fun is arguing the merits of mapping vs. modding (two completely different things) in a game that's old enough to drink legally, ya, probably
Please log in to shout.


Members Online: Roy, jjf28, Brusilov