My question and progress thread

[c0mputer-fr0d]

here is the result of the first pieces of code I wrote for tdm. I know this is very simple for you guys but it took me a few days to figure this out lol. It was a good way for me to start understanding the scripting language and the way you guys have the scripts laid out.

I haven't got the hover action or click action working yet, not sure why.

Edited June 26, 2015 by c0mputer-fr0d

[SeriousToni]

Nice to see you diving into the code

 

EDIT: Maybe you can make this thread more valuable by posting your progress on the MP matter in here later.

Edited June 26, 2015 by SeriousToni

[c0mputer-fr0d]

that's the plan! I will also invariably be asking for help here too probably.

[161803398874989]

Have you thought about just making one thread for all your things?

Edited June 26, 2015 by 161803398874989

[c0mputer-fr0d]

No, but now I will. Makes a lot more sense to do that.

[SeriousToni]

Have you thought about just making one thread for all your things?

 

Yeah that was my point too. It's easier for us to follow your progress and questions in one thread, like this one. Many users here have their own thread created (mostly for DR questions). Can you still change the topic title btw or is this not possible any more?

Edited June 26, 2015 by SeriousToni

[Springheel]

Not to put too fine a point on it, but the difficulty of adding a line to a gui and actually coding multiplayer is akin to the difference between learning how to identify a hammer and actually building a house.

 

Just make sure you have realistic goals.

[demagogue]

It was something fun for him to do anyway.

 

IMO, before we even get to working on multiplayer, the first task is just to identify and organize all the work that has to be done & document it in the wiki, along with a primer in how multiplayer even works in id4, what's still in there, what's been stripped out, etc. That's a more achievable near-term goal, and something that would probably be most valuable for us in the long run. Then we can get to talking about how different tasks might be approached, and what kind of time-scales we're talking about, imagining some future team of people motivated to do it (probably not the regular team which is already busy enough maintaining the mod).

 

To use Spring's analogy, the first thing an individual can practically do right now is work on a blueprint for the house, or guidance in how to go about making a blueprint.

[motorsep]

.. along with a primer in how multiplayer even works in id4 ..

 

There ya go: http://mrelusive.com/publications/papers/The-DOOM-III-Network-Architecture.pdf

[c0mputer-fr0d]

I actually have started to put all the netcode from the two games (it's spread across so many files) in separate folders so I can see what has been stripped out and what data needs to be sent in tdm that didn't exist in doom , like light gem values and loot . What I wish I could figure out right now is just how to send player entity updates between two people, this is like my biggest goal right now. What you guys are saying is very true, last time I tried to work on this I had unrealistic goals and didn't get anything done. What you guys have proposed sounds much better.

[demagogue]

The quickest way to see what data each game needs IMO is to compare the save game code, which saves the value of every variable the world uses to run, many of which the client systems will need from/send to each other.

 

One issue IIRC is that a lot of events are coded to occur on player1. So those systems would have to be re-coded to assume multiple players, and data coming in for them. But that's a later task maybe. For now start small like you are. Be great just to get player characters spawned together in a shared map. Maybe even strip out incompatible functions to get there, to fix & add them back one by one later.

[c0mputer-fr0d]

making a chart of the program flow when a multiplayer game gets started, I wish I could get my hands on the original doom 3 scripts to help me trace program flow when a user starts a mp game. I'm making pretty big bounds in my understanding though.

Edited June 29, 2015 by c0mputer-fr0d

[SteveL]

It's a big code base. TDM has about 650 lines of code in the main projects, not including comments and whitespace. Fortunately it's very modular so it's fairly easy to find stuff once you get used to the modules.

 

You can download the original doom3 or the BFG edition source code easily enough. Or is it specifically the scripts you need? I'm not sure off-hand whether they are included but it's worth looking.

[c0mputer-fr0d]

I was thinking if I had the doom 3 gui script for the multiplayer menu in doom 3 I could trace things a little easier.

I'd like to be able see what happens right when a user in a doom 3 lobby starts the mp game and everything after that so I can get how the program is flowing.

Edited June 29, 2015 by c0mputer-fr0d

[SteveL]

I just checked my copy of BFG to see if I could get at the scripts, but I can't, unless someone here knows how to open one of its '.resources' archives. 7zip doesn't know how.

 

Is the code you need to see definitely in the script files? I think you can step through the BFG c++ code in a debugger, as long as you have a copy of the game resources to go with the released code.

 

For that matter, you could use the released code to open and unpack the .resources files if you're really determined

[motorsep]

BFG has no gui scripts. It uses SWF (Flash).

 

Entire multiplayer stuff is tied to Steam and is ripped out of the source code release due to license.

[c0mputer-fr0d]

bummer I guess I need to go buy the original doom 3 if I can find it

[c0mputer-fr0d]

does anyone know where I might find the variables that get loaded in from the settings? more specifically , the controls?

[motorsep]

bummer I guess I need to go buy the original doom 3 if I can find it

 

 

You don't need to go too far - get on Steam and get Doom 3 + RoE bundle for $12 (less when on sale).

Edited July 6, 2015 by motorsep

[c0mputer-fr0d]

will do if it comes with the original scripts it could help me a lot. I did find the file I was looking for, all the settings variables are in the appropriately named "SysCvars.cpp"

[Bikerdude]

This thread probably needs moving as it isn't really related to DR per se.

[demagogue]

While we're at it, this is a good time to recall that coop stealth is like the greatest thing ever.

 

Coop pew-pew is fine and all, but exploring a mysterious mansion together and discovering its terrible secrets with someone is fun beyond words, while also helping each other stealth past areas (if you have help, no excuse not to shoot for ghosting).

[c0mputer-fr0d]

I will tell springheel or someone to move this but I would like to post one more thing before it gets moved.

 

http://postimg.org/image/tcb4a1gnp/

 

I made an auto use feature but I haven't recompiled the game yet so I don't know if it works.

I don't know how to branch on svn yet I always have issues with version control systems, but I will find out how right now.

If anyone could help me with this , this will be my first real contribution to you guys and it's a very handy game mechanic to have.

 

I just added a new Cvar to the SysCvars called "tdm_item_auto_use" , and then in the item selection I just put

an if

if (cvarSystem->GetCVarBool("tdm_item_auto_use"))
		{
			curItemEnt->Activate(this);
		}

if this isn't the right way to do this let me know , or if I missed a step. Edited July 7, 2015 by c0mputer-fr0d

[SteveL]

That looks ok syntactically but where did you put it? In idPlayer::Think, or the inventory switch code, or elsewhere? Ah I see you already answered that. I see a potential problem or two though. Players might get unexpected events when scrolling through the inventory, and there are plenty of maps out there with custom inventory items, and we can't predict what would happen in all those spots :-\

[c0mputer-fr0d]

oh you're right I need to do it only if they pressed a key and not just item scrolled I don't know why I thought I was being smart