killingblair

This owns.

It's actually a Sim City remake.

Hello, I tried to checkout the latest DB2 svn revision today, and upon compiling I got this error: Source file 'C:\Code\DB2\Source\Core\ZDoom\StateGoto.cs' could not be opened ('Unspecified error ')Looking at the repositories, it looks like StateGoto.cs isn't in there, yet it's still listed by the .csproj. I removed the file listing from the .csproj, just to see if all instances of the code in that file were removed/moved, and I got this error: The type or namespace name 'StateGoto' could not be found (are you missing a using directive or an assembly reference?) C:\Code\DB2\Source\Core\ZDoom\StateStructure.cs

I don't believe Skulltag's stock maps have the SCRIPTS lump intact, and ACS decompilers leave something to be desired at the moment, so your best bet is to lobby Skulltag to release the SCRIPTS lumps for the maps (if they still have them) or ask the mappers.

...I'll let you sweat it out, look at the examples section at the bottom of that page. It shows you Doom's status bar, complete with inventory goodness. Focus on the "DrawSelectedInventory" part under the "StatusBar Normal" code block, and play around with the numbers.

What's wrong with .NET? Are you on Linux? Are you on Windows 95? If you think 1.68 is terrible on Windows, then God help you trying to emulate it on WINE.

http://zdoom.org/wiki/SBARINFO You'll need to rework the Doom inventory bar a bit in order to not overlap with any of the Doom HUD graphics.

http://zdoom.org/zdkb/actormover.html For interpolation points, low/high bytes are a delicious hack to let you circumvent certain limitations in the ZDoom Doom/Hexen map format...if they still exist. Low byte can be a TID from 0 to 255, and a high byte is your 5th arg * 256. This allows you to use TIDs higher than 255 as interpolation points. If you have low byte and high byte set, both of your args add up, for example: arg 4 (low byte) - 132 arg 5 (high byte) - 5 (5*256)+132 = a TID of 1412 Of course, if you keep the TID count in the map less than 255, you can ignore this crap and only set a low byte, and keep arg 5 at 0. Spend some time with the ZDoom Knowledge Base (be careful though because some of that stuff is outdated) and the ZDoom Wiki and you will know all of ZDoom's secrets in no time.

Make it an ENTER script, so it's guaranteed to run when the player enters the game, not when the map is loading. I had a similar problem a few weeks ago. With the ENTER script, you could give your player a TID and get his angle in one script. This is assuming you need the player TID to be a global value for other scripts:#include "zcommon.acs" #define PlayerTID 2 script 1 ENTER { Thing_ChangeTID(0, PlayerTID); int angle = GetActorAngle(PlayerTID); print(f:angle); /* do whatever you need with the angle here */ } Hope this helps!

From a user standpoint, this is heaven-sent. I come from a rather OOP standpoint, as when I started out, I went straight for C++, and to this day my languages of choice are C# and Java. I would often get frustrated at ACS for its current limitations, lack of expandability, and general clunkyness of the code. I can't wait to adopt ACS++.

Also thanks to our wonderful testing staff for letting us know there's pucks spawning under the scoreboard and getting stuck and thinking it's some sort of elaborate joke that the creators deliberately put in this mod, and thanks for letting us know this in several angry, hate filled PM's on IRC.

You forgot double taps, Ralph. In Slapshot, there is an agility system called double taps. When you double tap any one of your movement keys fast enough, you get a quick thrust in that direction -- for a small charge to your "Stamina." This allows for quick dekes and fakes, as well as assisting in races to the puck.

Ok, so the progression of this has pretty much degenerated to a.) Ralph made a map and b.) Xenaero and I put some very limited ACS/DECORATE stuff in it. Right now you can gain possession of the puck (i.e. use SetActorPosition and some math to put the puck directly in front of you at all times, and some math to make sure you can't skate with the puck looking backwards. Although, some experimental code is underway to have a "tracer" shoot and die on a solid surface, and when it does so, the puck is updated. As far as I know, this is the only way to have small objects not teleport through solid objects. You can also shoot pucks and "charge" shots depending on how long you hold the attack button, but this is very primitive. However, the project has crawled to a slow since and had very little progression. So, I am taking over this project. It's going to be a lot of work but it's a great idea that has never been done before. Would anybody like to offer, any help at all is fantastic.

holy cow get hype

I love you donut.