[icecoldduke]

Master O, on 12 June 2017 - 08:01 AM, said:

Icecoldduke, is Shadow Warrior itself basically working now? Or are you putting that off solely to work on the above scripting system?

I wanted to open up the discussion because I'm frankly tired of reading about the Robman/DK craziness. In terms of development I plan doing bug fixes when I have a decent amount of time in one sitting to work on the project, and scripting when I have small amounts of time to work on the project. It gives a good balance on me so I can have fun stuff to work on and nitty gritty shit as well.

[Danukem]

icecoldduke, on 12 June 2017 - 07:22 AM, said:

Let me know your thoughts on this roadmap and any concerns you guys have with the new scripting system. Also let me know of ideas you guys have for things you would like to do in level scripting.

Ideally, the scripting system should have access to pretty much every aspect of the game. This is true in EDuke32, although it took a while to get there. Looking at your goals, it seems like the scripting in your SW port would be much more limited than EDuke32 as it currently stands. A lot of what we do when writing script involves creating new effects, often similar to the ones that are hardcoded (this can involve causing sectors to move up or down or rotate in response to something an actor does, changing shade values on walls, or any number of other things). This can be done via custom actors as long as we have read and write access to all the game structures that we need.

[icecoldduke]

Trooper Dan, on 12 June 2017 - 10:43 AM, said:

Ideally, the scripting system should have access to pretty much every aspect of the game. This is true in EDuke32, although it took a while to get there. Looking at your goals, it seems like the scripting in your SW port would be much more limited than EDuke32 as it currently stands. A lot of what we do when writing script involves creating new effects, often similar to the ones that are hardcoded (this can involve causing sectors to move up or down or rotate in response to something an actor does, changing shade values on walls, or any number of other things). This can be done via custom actors as long as we have read and write access to all the game structures that we need.

That sounds like the kinda of stuff I want to expose to the level scripts. Here are some of the items I want to expose to the level scripts:

• Moving sectors.
  
• Moving floors and ceilings
  
• Spawning Actors
  
• Killing Actors
  
• Changing shade of the sector
  
• Playing Sounds
  
• Change sprite/sector/wall palettes.
  
• Hurt the player(done).
  
• Heal the player

[Danukem]

^Also anything to do with sprites, including all members of the sprite structure. And the player structure. The more the better. Believe me, we have made good use of all this stuff in the EDuke32 community.

[Ninjakitty]

icecoldduke, on 11 June 2017 - 09:32 PM, said:

Zip up your folder and upload it someplace so I can take a look.

It took SO LONG to upload
But, here ya go! https://www.dropbox..../trunk.rar?dl=0

[Mark]

Yeah, Dropbox is always a slow upload.

[Ninjakitty]

Mark., on 12 June 2017 - 12:41 PM, said:

Yeah, Dropbox is always a slow upload.

Oh, I thought it was just my internet being slow like normal, LOL

[Kyanos]

icecoldduke, on 06 June 2017 - 10:53 AM, said:

If want I can host the HRP, and if you still have those assets I would love for them to be in the HRP.

I was browsing the SW HRP commit log and it's all Hendricks, I was thinking about adding the highpal stuff there where it's needed, but I don't want to step on any toes as that HRP is made for SWP I believe so maybe you should host one for this.

[icecoldduke]

I added "playsoundatsprite" function that will play audio at a sprite(obviously). I have expanded the scripttest example function to the following:

-- map_scripttest.lua - this map shows off the new scripting system in shadow warrior.
--

#include swdata/scripts/user.lua

function stagscript_function0(myspriteid, mysectorid)
	local playersector = getplayersector(0);
	if mysectorid == playersector then
		if(getlocalvar(myspriteid, 0) == 0) then -- Only execute the print message if we just entered the sector.
			if getlocalvar(myspriteid, 1) == 0 then
				displaymessage("Get out of my sector!!")
				setlocalvar(myspriteid, 0, 1) -- Signal that we are now in our sector.
				playsoundatsprite(DIGI_TINYDICK, myspriteid)
			else 
				displaymessage("Why the hell do you keep coming in my sector!!")
				setlocalvar(myspriteid, 0, 1) -- Signal that we are now in our sector.
				hurtplayer(0, 30)
				playsoundatsprite(DIGI_WARNING, myspriteid)
				playsoundatsprite(DIGI_HURTBAD1, myspriteid)
			end
		end
	else 
		if getlocalvar(myspriteid, 0) == 1 then
			setlocalvar(myspriteid, 1, 1)  -- Signal that we have entered the sector at least once.
			setlocalvar(myspriteid, 0, 0)  -- Signal that we have left the sector.
		end
	end
end

Ninjakitty, on 12 June 2017 - 12:40 PM, said:

It took SO LONG to upload
But, here ya go! https://www.dropbox..../trunk.rar?dl=0

I will take a look thanks!

[Kyanos]

Can you make an autoload system for this like EDuke32, currently sw.def gets rewritten to make the HRP work.

I'd want something that would load an HRP like this .zip

https://drive.google...iew?usp=sharing

[icecoldduke]

Drek, on 12 June 2017 - 04:36 PM, said:

Can you make an autoload system for this like EDuke32, currently sw.def gets rewritten to make the HRP work.

I'd want something that would load an HRP like this .zip

https://drive.google...iew?usp=sharing

Yes the autoload system is on my todo list .

[icecoldduke]

In the branch I fixed a bug where new maps created in swmapster would not display visibility fog in game. In Shadow Warrior the visibility fog distance is stored in sector[0].extra, and mapster sets extra to -1, so the game would not render any visibility fog. If you sync to the latest changelist the issue is fixed, if you have a map that has this bug please set your sector 0 extra to 512. If you are waiting for a binary, the fix will be in the next patch.

[Hendricks266]

This is why you shouldn't use Duke's astub.c.

[icecoldduke]

Hendricks266, on 12 June 2017 - 07:50 PM, said:

This is why you shouldn't use Duke's astub.c.

I disagree . Either I port over all of swbuild's changes to mapster or I port swbuild to eduke32 then port all of mapsters changes to swmapster. I figure porting swbuilds changes to swmapster makes the most sense.

Also if you guys have a newboard.map in your save directory please delete it.

[icecoldduke]

Ninjakitty, on 12 June 2017 - 12:49 PM, said:

...

Try again at head revision and see if it the latest CL I committed fixes the issue for you.

[icecoldduke]

I have also committed to the branch a new lua function for setting sector shade called setsectorlightintensity(based on existing code in light.cpp but modified for our purposes) with a example in scripttest.map and map_scripttest.lua on how to use it.

Here is the relevant code.

function stagscript_function1(myspriteid, mysectorid)
	local currentintensity = getlocalvar(myspriteid, 0);
	if currentintensity >= 20 then
		currentintensity = 0
	end
	setsectorlightintensity(mysectorid, currentintensity, 1, 3, 1, 1, 1)
	currentintensity = currentintensity + 0.02 -- todo scale by delta time.
	setlocalvar(myspriteid, 0, currentintensity)
end

[Forge]

icecoldduke, on 12 June 2017 - 04:45 PM, said:

Yes the autoload system is on my todo list .

The grp file 'search' system needs to be implemented as well so grp files don't have to be dropped into the base directory in order to play them - Doing this creates weird behavior and/or conflicts with art, sounds, etc.

Twin Dragon - all those hentai(?) women are missing. Other random things are either missing or replaced with items from the base game. Things behave weird
like this key that can only be seen from one direction

 swcp0000.jpg (116.31K)
Number of downloads: 8  swcp0001.jpg (119.22K)
Number of downloads: 8

[icecoldduke]

Forge, on 13 June 2017 - 07:00 AM, said:

The grp file 'search' system needs to be implemented as well so grp files don't have to be dropped into the base directory in order to play them - Doing this creates weird behavior and/or conflicts with art, sounds, etc.

Twin Dragon - all those hentai(?) women are missing. Other random things are either missing or replaced with items from the base game. Things behave weird
like this key that can only be seen from one direction

swcp0000.jpg swcp0001.jpg

I have verified that at least some Twin Dragon assets are being loaded into the game. If you try and play the first level of Twin Dragon in base game mode there are a whole bunch of floors missing. Likewise all the floors are rendered correctly when you load the first level of Twin Dragon in Twin Dragon game mode. Can you create a savegame by the girl in the shower where she is missing? I'll try and look at this when I get home tonight.

As far as the card not rotating towards you, does this happen in Polymost, Polymer or both?

[Forge]

icecoldduke, on 13 June 2017 - 07:03 AM, said:

I have verified that at least some Twin Dragon assets are being loaded into the game. If you try and play the first level of Twin Dragon in base game mode there are a whole bunch of floors missing. Likewise all the floors are rendered correctly when you load the first level of Twin Dragon in Twin Dragon game mode. Can you create a savegame by the girl in the shower where she is missing? I'll try and look at this when I get home tonight.

As far as the card not rotating towards you, does this happen in Polymost, Polymer or both?

the card behaves the same in polymost and polymer

as for the woman art not showing up - i figured that out.
They will only appear if the difficulty is "who wants wang" or "no pain no gain"
they don't show up under "i have no fear" - which is what I've been using. (or tiny grasshopper)

[icecoldduke]

Forge, on 13 June 2017 - 08:00 AM, said:

as for the woman art not showing up - i figured that out.
They will only appear if the difficulty is "who wants wang" or "no pain no gain"
they don't show up under "i have no fear" - which is what I've been using. (or tiny grasshopper)

So is this a bug or is it by design?

[Ninjakitty]

icecoldduke, on 13 June 2017 - 05:04 AM, said:

Try again at head revision and see if it the latest CL I committed fixes the issue for you.

The latest Github build works great
I forgot, how do you make demos again?

[Forge]

icecoldduke, on 13 June 2017 - 10:41 AM, said:

So is this a bug or is it by design?

design. it does the same thing in the dos version.
it's the steam redux version that is wrong and has those sprites show up no matter what difficulty is selected.

[Hendricks266]

Isn't there a similar bug also in the original game where the bosses in Wanton Destruction don't spawn on the lower difficulty levels?

[Forge]

Hendricks266, on 13 June 2017 - 01:39 PM, said:

Isn't there a similar bug also in the original game where the bosses in Wanton Destruction don't spawn on the lower difficulty levels?

I didn't encounter that with this port & using the steam wt.grp file, but I can install the dos version and check if you'd like.

[Ninjakitty]

It seems like the map makers just forgot to complete the difficulty settings for some NPCs.
If you don't set the difficulty level for an NPC, then by default, it will only spawn on who wants wang or higher.

Maps also had bugs like secret area triggers being put too far back into the wall. I think the Classic Redux had these bugs fixed after people started talking about them on its community hub.

[Forge]

i guess 'wrong' isn't the correct term.
'not the same as the dos version' would be the proper way to state it.

[icecoldduke]

In the branch I exported all of conpic.h(all the weapon tile defines) to https://github.com/j...ripts/panel.lua so you can now change the tiles of the first person weapon tiles. I have also exported names.h and names2.h https://github.com/j...ripts/names.lua but that is not hooked up yet.

I have also discovered a bug where if you shoot the nuclear bomb the rocket launcher sounds will be bugged until you change the weapon. I have added this to my todo list and it will be fixed.

[Hendricks266]

You can't simultaneously slap together a public-facing scripting API in dire need of proper speccing while encouraging modders to make stuff with it. I recommend labeling your Lua API a proof of concept or public experiment, because there's no way I'm supporting huge lists of hardcoded constant IDs. (They're not the only problem.)

There are absolutely no shortcuts to doing this right, and your experience in AAA development has not prepared you for the task.

[Hank]

I think LUA support is like four or five days old.
I also think no one is modding yet, except me doing textures.
As for the best way to implement LUA - you guys fight it out, let's have the best there can be.

[Mark]

I'm confused now. I was under the impression that ICD's SW is his own project and that Hendricks will be working on VoidSW. So why is Hendricks worried about having to support ( bug fix ) ICD's project? Or does Hendricks mean he doesn't like the way something is being handled by using the phrase "not support it"?