Author Topic: DLL SDK  (Read 2128 times)

Offline Leviathan

  • Hero Member
  • *****
  • Posts: 4055
DLL SDK
« on: February 22, 2005, 03:39:38 AM »
Hacker, Hooman please talk here about updateing the SDK :)

Offline Hooman

  • Administrator
  • Hero Member
  • *****
  • Posts: 4954
DLL SDK
« Reply #1 on: February 22, 2005, 07:59:11 AM »
I've got Eddy's header file. I'll incorporate the changes soon. I'll probably also be considering breaking up the header file into a number of smaller ones. Having one huge header file can seem a bit daunting, plus it's highly convenient to have a window open to the map_id enum and another open at whatever class you're working with.

Once a new DLL SDK header is ready to be posted, I'd like to start working on a step by step tutorial for how to use it. Then even people with little to no programming experience can at least make some sense of it. They'll need a copy of MSVC 6 though.
 

Offline Leviathan

  • Hero Member
  • *****
  • Posts: 4055
DLL SDK
« Reply #2 on: February 26, 2005, 12:17:04 PM »
Hooman has worked hard 2 get the new SDK made :)
just need hacker to look over it now..

I hope it makes life easyer :)

Offline Hooman

  • Administrator
  • Hero Member
  • *****
  • Posts: 4954
DLL SDK
« Reply #3 on: February 26, 2005, 01:04:43 PM »
It looks like it's largely ready for people to start taking a peek at it. It's still got two slight issues I'd like to resolve before having an official release for it. One is a compiler warning for the empty/blank template project. Seems kinda unprofessional and I don't really want to alarm people who are new to C++. The other issue is a name collision between two new added enums. We'll probably handle it with some kind of namespace.

Anyways, the project has been reorganized a fair bit. I originally figured I'd just be collecting all the new info from people, but I guess I got a little carried away reorganising it. I also added lots of comments so people new to this would have a better idea what's going on. It's in a state where I can start giving people advanced copies of the update, but be aware it's not official yet and probably needs a little more tweaking, so you'd have to redownload it once it becomes official. Aside from the new organization, there's nothing new other than a few filled in details, but hopefully it'll be easier to read/understand now.


It's surprising how much you realize you've forgotten and really needs to be written down once you start trying to comment something like that.   :blink:

 

Offline Leviathan

  • Hero Member
  • *****
  • Posts: 4055
DLL SDK
« Reply #4 on: February 26, 2005, 01:44:26 PM »
looking good. whats the helper files for? y named helper? could they be someting better?

// Note: The standard level DLLs released by Sierra leave this function
Id say Dyanmix as they made the game.

also id add a coment at the top of each file to give the file its name, like in BaseData it would just say // Base Data Filelooking good. whats the helper files for? y named helper? could they be someting better?

i think in multitek and in TechIDs we should rename the Group's to have the number like 12 then the roman numaral in brackets (VIII)

in the BaseData maybe a good way to add mines inside the buildingSet like so there off set is to add a mineSet for each base, then mines could be added with the offset etc and would move with the base when StartLocation cords r edited :)
just add this on the end of BaseInfo
{ autosize(buildingSet), autosize(tubeSet), autosize(wallSet), autosize(unitSet), autosize(mineSet) },
« Last Edit: February 26, 2005, 02:35:11 PM by Leviathan »

Offline Eddy-B

  • Hero Member
  • *****
  • Posts: 1186
    • http://www.eddy-b.com
DLL SDK
« Reply #5 on: February 27, 2005, 06:42:30 AM »
Looking forward to the pre-release :)

I have also created a OP2extra fileset with some extra functions that didn't belong in the helper file. It mainly contains procedures for saving/retrieving mission-data, as i've used in renegades. This is only useful in campaign-mode of course.

But it also contains some other functions that could prove useful:
bool InRect(LOCATION loc,MAP_RECT rect);
bool InRect(Unit u,MAP_RECT rect);

Also i've created a file named "mapstring.cpp" which contains all map_id's in string-format. "Why ?" u might ask.. well it saved a lot of time in debugging my missions if i can have the DLL display a unit name, rather then a number.. which i'd have to look up in the header again. It's nothing more then a copy of the map_id structure with every item put in a "string";


Good work so far!  (thumbsup)  
Rule #1:  Eddy is always right
Rule #2: If you think he's wrong, see rule #1
--------------------

Outpost : Renegades - Eddy-B.com - Electronics Pit[/siz

Offline Leviathan

  • Hero Member
  • *****
  • Posts: 4055
DLL SDK
« Reply #6 on: February 27, 2005, 05:59:20 PM »
The saviing thing of Eddy-B's is great and could be included for single player maps that people make? not sure..

Should include into on mutl and single maps. Like how to start writeing them.

make mineSet beaconSet.  

Offline Hooman

  • Administrator
  • Hero Member
  • *****
  • Posts: 4954
DLL SDK
« Reply #7 on: February 27, 2005, 09:26:37 PM »
I'll likely add the mineSet to the base layouts exactly as you've mentioned. That was an edit I was planning on but forgot about.

Changing the comments for the tech ID enum to make the level easier to read sounds good.

I can't really think of a better name for the OP2Helper stuff. There is no real set criterion for what functions go into that set of files. Like the main header files, it's being broken up into seperate sections. I'd like to have more added someday but for the moment I can't think what extra functionality we really need. (Probably some AI related stuff will find it's way in there someday.) The idea behind the helper files was just a set of functions, which you're not required to use, that can make it easier to make levels. They should be general enough that many levels can make use of them without any edits to them. If we find we have more common needs then we should be throwing more functions in there to handle them. I kinda want to keep one generic header file that includes all the other ones as they are added. That way you only need to worry about including that one file to make use of anything in the helper section. I would like to sectionalize things a little so you can also pick and choose what sections to include, if so desired.

The InitResources I sometimes question being in there, but it is very useful for testing. I think what I should do is extend the idea to setup resources for different game types. Multiplayer starting resources seems like the most important.

As for Eddy's code, that might be a good candidate to stick in there. I don't know though since I've never seen it and don't know exactly what it does, but it sounds like it may be useful generic code for making campaign missions. Of couse I'd like code to be largely stable before being placed in the helper files and I'm wondering about that. Is it generic enough that it won't need changes or does it just save whatever seemed useful at the time? Certainly the idea seems like a good one.

Levi: I think the idea behind that code was to save data while switching from one mission to the next. I can't see it having any real use outside of that. Save game files already have a system for saving DLL specific data to saved game files. Granted, it is a bit lacking in some ways so this may be useful, but there is still the issue of the level not being informed when a game is saved or loaded.

That mapstring idea also might be nice to include in the helper section.

A few enums will have further name changes. I think prefixes need to be added to names in the enums to prevent naming collisions. That is currently an issue with two enums in the project.

I'm also slightly tempted to throw the techID enum into the map_id enum since the wreckage function implies the techIDs were defined in the map_id enum. However I'd rather not do this since many people seem to like editing the techtree and those values won't necessarily be valid values for a new techtree. There can also be new techs added that aren't listed in the enum. I'd say we just stick with a new enum and type cast for that one function. Mind you, there is a similar issue with the SongIds enum and repacking the music file. But I'd suggest leaving the SongIds enum as is. Repacking that file is a global effect whereas the tech trees can be renamed for a more local effect. Plus, I don't want the SongIds enum to be left empty since it is exported by Outpost2.exe. Anyways, if we really wanted to add more songs, we could always add them at the end of the file. (Oh, and the map_id enum is huge enough as it is, and doesn't need to be bigger from merging it with another huge enum.)