|
Members in Shoutbox
None.
Shoutbox Search
Shoutbox Commands
/w [name] > Whisper
/r > Reply to last whisper /me > Marks as action Shoutbox Information
Moderators may delete any and all shouts at will.
|
Global Shoutbox
Please log in to shout.
[2016-6-17. : 11:58 pm] KYSXD -- FaRTy1billionFaRTy1billion shouted: cool, weapons code so far already has if weaponID != 130 instead of < 130 xD ![]() [2016-6-17. : 11:56 pm] O)FaRTy1billion[MM] -- cool, weapons code so far already has if weaponID != 130 instead of < 130 xD[2016-6-17. : 11:47 pm] O)FaRTy1billion[MM] -- jjf28jjf28 shouted: add eud enabler to the plugin imo EUDEnabler is already a plugin, and doesn't interfere with it other than the death table being in random memory lol[2016-6-17. : 9:50 pm] O)FaRTy1billion[MM] -- but I can worry about that when I get there The most important part is getting the plugin working[2016-6-17. : 9:24 pm] O)FaRTy1billion[MM] -- Looks like I'll have to add some initialization code anyway[2016-6-17. : 9:23 pm] O)FaRTy1billion[MM] -- the only problem I can foresee is with like death tables, since there's not a pointer it since it's just static memory (and also where I moved the button structs so FireGraft wouldn't break). ;o[2016-6-17. : 9:21 pm] poiuy_qwert -- cool, good luck. if you do find a way I'll be interested to know[2016-6-17. : 9:19 pm] O)FaRTy1billion[MM] -- If I can do it my way, it is the lazier option that doesn't require me to learn gptp and saves users the headache of porting ![]() [2016-6-17. : 9:18 pm] poiuy_qwert -- well hopefully there is. I still think making a version of GPTP that isn't backwards compatible is the better option, though obviously more work[2016-6-17. : 9:14 pm] O)FaRTy1billion[MM] -- poiuy_qwertpoiuy_qwert shouted: FaRTy1billion FaRTy1billion You still don't explain how I can recompile without all my code breaking because of your changes. How are you changing a type* to a type** without me changing any of my code? Because if I use a template class or something I can make it transparent ![]() [2016-6-17. : 9:14 pm] KYSXD -- FaRTy1billionFaRTy1billion shouted: I don't think wMode uses dat files Oh, just the... oh!... i get it. ![]() [2016-6-17. : 9:13 pm] poiuy_qwert -- FaRTy1billionFaRTy1billion shouted: which is why you recompile FaRTy1billionFaRTy1billion shouted: get source, replace header file, recompile, and now it reads the pointer instead of copying it You still don't explain how I can recompile without all my code breaking because of your changes. How are you changing a type* to a type** without me changing any of my code?[2016-6-17. : 9:12 pm] O)FaRTy1billion[MM] -- poiuy_qwertpoiuy_qwert shouted: FaRTy1billion Thats a minor change to GPTP that doesn't affect plugins I don't want to completely change gptp[2016-6-17. : 9:12 pm] KYSXD -- Just one question about this, if i load wMode at Plugin::InitializePlugin(), the poiuy_qwert idea: poiuy_qwertpoiuy_qwert shouted: another option is not loading those pointers when the plugin is initialized, but when the game starts. that could have other problems if plugins are expecting it to be loaded before then, but I doubt any plugins do would me a trouble for my code?[2016-6-17. : 9:11 pm] O)FaRTy1billion[MM] -- get source, replace header file, recompile, and now it reads the pointer instead of copying it[2016-6-17. : 9:08 pm] poiuy_qwert -- FaRTy1billionFaRTy1billion shouted: poiuy_qwert because if I do it right it will change how the memory is accessed by the code ? if you are changing the way stuff is accessed then the plugins that are accessing that stuff have to change[2016-6-17. : 9:07 pm] poiuy_qwert -- FaRTy1billionFaRTy1billion shouted: poiuy_qwert It is a problem because that would require a complete overhaul of how gptp loads them, because they're just constants in a header so they're loaded as soon as the plugin is Thats a minor change to GPTP that doesn't affect plugins[2016-6-17. : 9:06 pm] O)FaRTy1billion[MM] -- poiuy_qwertpoiuy_qwert shouted: FaRTy1billion I still don't see how you can only update the header and not require the plugin author to update their code because if I do it right it will change how the memory is accessed by the code[2016-6-17. : 9:06 pm] O)FaRTy1billion[MM] -- poiuy_qwertpoiuy_qwert shouted: FaRTy1billion Thats why I was saying to update GPTP like: poiuy_qwert It is a problem because that would require a complete overhaul of how gptp loads them, because they're just constants in a header so they're loaded as soon as the plugin is[2016-6-17. : 9:04 pm] poiuy_qwert -- FaRTy1billionFaRTy1billion shouted: In either case, providing the modified header file to recompile with will fix the issue. I still don't see how you can only update the header and not require the plugin author to update their code![]() [2016-6-17. : 9:04 pm] poiuy_qwert -- FaRTy1billionFaRTy1billion shouted: if they get the pointer from the dat load struct after my plugin has changed it, everything will work fine. otherwise, everything will be null Thats why I was saying to update GPTP like: poiuy_qwert![]() poiuy_qwert shouted: another option is not loading those pointers when the plugin is initialized, but when the game starts. that could have other problems if plugins are expecting it to be loaded before then, but I doubt any plugins do [2016-6-17. : 9:03 pm] O)FaRTy1billion[MM] -- "//From buttons.cpp BUTTON* const button = 0; //??? BUTTON_SET* const buttonSet = 0; //???" why are these 0? Do they not have the pointer?[2016-6-17. : 9:02 pm] O)FaRTy1billion[MM] -- In either case, providing the modified header file to recompile with will fix the issue. ![]() [2016-6-17. : 9:01 pm] O)FaRTy1billion[MM] -- also I'm not sure if plugins are loaded than ran, or if they're all loaded then in a separate step all ran. If the latter is true, then existing GPTP plugins won't work[2016-6-17. : 9:00 pm] O)FaRTy1billion[MM] -- also if they read any of the unit tables or button tables that I've relocated that will cause problems[2016-6-17. : 9:00 pm] O)FaRTy1billion[MM] -- if they get the pointer from the dat load struct after my plugin has changed it, everything will work fine. otherwise, everything will be null ![]() [2016-6-17. : 8:59 pm] poiuy_qwert -- recompiling is fine, its that they would have to change code in the plugin if you change the way the dat files are accessed[2016-6-17. : 8:58 pm] O)FaRTy1billion[MM] -- any existing gptp plugin won't work if it is loaded first[2016-6-17. : 8:57 pm] O)FaRTy1billion[MM] -- any existing gptp plugin that uses dat files won't work without recompiling, I'm just trying to make it as small of a change as possible (changing only a header)[2016-6-17. : 8:57 pm] poiuy_qwert -- if you don't care about backwards compatibility then this whole conversation was pointless ;P[2016-6-17. : 8:56 pm] poiuy_qwert -- but you can change that is what I'm saying. that would make it so existing plugins still work without any code changes and it doesn't matter if dat expander is loaded second[2016-6-17. : 8:56 pm] O)FaRTy1billion[MM] -- a really tiny template class seems like it'll probably be the easiest and cleanest[2016-6-17. : 8:55 pm] O)FaRTy1billion[MM] -- GPTP they are loaded when they are defined, because they are consts[2016-6-17. : 8:54 pm] poiuy_qwert -- another option is not loading those pointers when the plugin is initialized, but when the game starts. that could have other problems if plugins are expecting it to be loaded before then, but I doubt any plugins do[2016-6-17. : 8:53 pm] O)FaRTy1billion[MM] -- poiuy_qwertpoiuy_qwert shouted: I was thinking there may be some crazy way with overloading the dereference operator or something, but I feel like it would just be better to make a new version of GPTP that isn't backwards compatible or just ensure that my plugin is loaded first xD![]() [2016-6-17. : 8:52 pm] O)FaRTy1billion[MM] -- I guess I could do like a template class or something that does that, but that might be ugly ![]() [2016-6-17. : 8:52 pm] poiuy_qwert -- I was thinking there may be some crazy way with overloading the dereference operator or something, but I feel like it would just be better to make a new version of GPTP that isn't backwards compatible ![]() [2016-6-17. : 8:50 pm] O)FaRTy1billion[MM] -- It is already a pointer to an array, so I need a pointer to a pointer to an array .. and apparently you can't without doing like (*test)[id][2016-6-17. : 8:47 pm] poiuy_qwert -- you need something like "int someArray[5] = {1,2,3,4,5}; int* arrayLocation = &someArray", then get access to someArray but only using arrayLocation[2016-6-17. : 8:43 pm] poiuy_qwert -- I dont think that is comparable, pretty sure that is what GPTP is doing right now[2016-6-17. : 8:40 pm] O)FaRTy1billion[MM] -- the ** was unnecessary. http://pastebin.com/ZteG2DqL works perfectly[2016-6-17. : 8:38 pm] O)FaRTy1billion[MM] -- All the code would be the same, all that's different is the declaration |