[Mblackwell]

The Mechanic, on 29 October 2015 - 02:52 PM, said:

My top two errors these days are 1) using "var" instead of "varvar" e.g. setvar instead of setvarvar, doesn't always give an error message that is obvious but once you've seen it a few times you know _exactly_ what you feck'd up The other is getting { and } to balance, can lead to quite a bit of head scratching but using notepad++ with a CON-specific plug in can really help there.

If you format your tabs as 4 spaces and always do your code with indentations keeping track of brackets isn't very hard since you have a visual line to go from (and can always move down the lines and see if it's there).

These days I always write like this:

useractor notenemy MYACTOR
    ifvare SOMEVAR 0
        state dostuff
    else
    {
        getactor[THISACTOR].extra SOMEVAR
        ifvarg SOMEVAR 10
        {
            ifvarg SOMEVAR 20
                state domorestuff
            else
            {
                mulvar SOMEVAR 100
                getactor[THISACTOR].xrepeat SOMEOTHERVAR
                divvarvar SOMEVAR SOMEOTHERVAR
                state doevenmorestuff
            }
        }
    }
enda

Blame TerminX for always enforcing fairly strict style guidelines when you code with him.

[The Mechanic]

Mblackwell, on 29 October 2015 - 07:24 PM, said:

If you format your tabs as 4 spaces and always do your code with indentations keeping track of brackets isn't very hard since you have a visual line to go from (and can always move down the lines and see if it's there).

Yes - and no. The issue usually arrises when I modify a function such as commenting out blocks whilst trying to get my crap to work. It also takes me a few hours to switch between c#/c++/php/javascript mode and CON file mode during which time I do some real dumb things like

state my_really_cool_function
{
}

which I then compound replacing the trailing '}' with ends. I hate getting old.

Mblackwell, on 29 October 2015 - 07:24 PM, said:

These days I always write like this:

useractor notenemy MYACTOR
    ifvare SOMEVAR 0
        state dostuff
    else
    {
        getactor[THISACTOR].extra SOMEVAR
        ifvarg SOMEVAR 10
        {
            ifvarg SOMEVAR 20
                state domorestuff
            else
            {
                mulvar SOMEVAR 100
                getactor[THISACTOR].xrepeat SOMEOTHERVAR
                divvarvar SOMEVAR SOMEOTHERVAR
                state doevenmorestuff
            }
        }
    }
enda

Wot no comments ? Shame on you

Mblackwell, on 29 October 2015 - 07:24 PM, said:

Blame TerminX for always enforcing fairly strict style guidelines when you code with him.

Yes, and that is good. We differ on very few - I could write an essay on why you should ALWAYS follow an if statement with curley braces even for single statements and why I am obviously right But it's irrelevent, I've learnt over the years that it is far better to have a common standard whatever that standard is. I've asked if there is one of the Eduke source files that could be used as a suitable style reference.

Anyhow, it sounded like PsychoGoatee was put off playing with CON files because of getting a bunch of errors, just wanted to highlight that just one actual error can lead to a shed load of errors but not to panic it may well just be the first error that is important.

TTFN,
Jon

[Mblackwell]

Yeah, the first error you find is the most important. Everything is caused by it generally.

BTW I avoid { } for single statements because in CON it prevents the code from branching internally (and saves resources). Which is why things like nullop exist.

Also comments are only for when code is unclear on its own*. That code clearly says to do lots of stuff!

Spoiler

Which can happen fast with CON considering you have to break up math functions.

[Kyanos]

I came across a modelling trick from an old game. They mapped the uv coordinates to the bottom left corner, 1 pixel. The engine is then told to ''float'' the pixel around the texture, using numbers pulled from the angle of the camera, it makes the object look flat and shiny.

Would you guys duplicate that in EDuke32?

[Mark]

I can't picture in my head what that looks like or what it's use would be. Do you have a link to a screenshot or video of that old game?

[Kyanos]

It's from turok actually, I've started helping duke64 with his turok mod. A few HUD models (auto shotgun barrel) and the keystone stands (gold metal trim) Extra life triangles, and health pickups are good examples of the effect.

[Mark]

I'll check out a youtube vid of Turok then......

I guess I was wrong about something. I was mistaking an older game called Trespass with Turok. Anyway, I saw in Turok 2 the spinning pickups you mentioned. I would just create the spinning model ( or voxel if that's your thing ) and not worry about modifying the game engine.

BTW, was it Diaz that had screenshots of a fantastic looking jungle in his unfinished mod? Team up with him if he's still around.

[Kyanos]

I'm ripping the models, they come like that it's how I even figured it out. I have no problem changing them to a static skin, I just thought is was a cool feature and it would be a better mod if the effect worked the same way here.

added a video:

[Tea Monster]

Drek, on 11 November 2015 - 09:35 AM, said:

I came across a modelling trick from an old game. They mapped the uv coordinates to the bottom left corner, 1 pixel. The engine is then told to ''float'' the pixel around the texture, using numbers pulled from the angle of the camera, it makes the object look flat and shiny.

Would you guys duplicate that in EDuke32?

Correct me if I'm wrong, but that doesn't sound like best practice - that is what smoothing groups are for. As Mark says, if you can link to a vid or a tutorial, that would be great.

One big problem with EDuke and MD3 models is that NPherno's MD3 tool tends to babber up smoothing groups, placing them at UV seams, which is really bad.

One technique they use nowadays is vector normals. They used it in Alien Isolation and Star Citizen. You make your model so that the normals of the object hold all the shape. That way, the only normal maps that you need are textures (like rusty metal,worn paint, leather, etc. You can create all your spec and normal maps without doing any baking at all. Things like table tops and flat surfaces are easy to have looking 'flat' so that reflections behave as they should do. You still have to bake character details down from a high poly sculpt, but an awful lot of props can be made using this technique.

EDIT: Blender tut:

[Mark]

OK Drek. Now I see what you're after.

[Hendricks266]

For the Duke 64 mod, I'm going to connect the spriteext members xpanning and ypanning to the UV coordinate of models.

[Kyanos]

Hendricks266, on 11 November 2015 - 04:57 PM, said:

For the Duke 64 mod, I'm going to connect the spriteext members xpanning and ypanning to the UV coordinate of models.

Awesome. So I would be able to get at it in def or con somehow? On my end I want to do it for one or two surfaces in a md3 with more surfaces defined to regular textures.

[Mark]

Speaking of models, could you make it possible to assign additional normal and spec map skins to models using different pals like you can now with the diffuse skin?

I have some custom enemies with multiple skins but they all have to share the same normal and spec maps.

[Hendricks266]

Drek, on 11 November 2015 - 05:42 PM, said:

Awesome. So I would be able to get at it in def or con somehow? On my end I want to do it for one or two surfaces in a md3 with more surfaces defined to regular textures.

It would be from CON, and would apply to all surfaces.

[Kyanos]

Thanks for the info. I can definitely work with that, I'll just split apart some models and define the pieces to multiple sprites.

[Hendricks266]

You can now access a model's UV panning through setactor[<id>].xpanning and ypanning, in the range 0-255.

[Micky C]

What's the mapster script command for deleting sprites?

[Helixhorned]

Micky C, on 11 December 2015 - 03:53 PM, said:

What's the mapster script command for deleting sprites?

As stated in the M32script command index, there's deletesprite. It's not tested by a.m32 though, so... good luck .

[Micky C]

Hmm that's weird, could have sworn I did a search for "delete" on that page but maybe it was something else. Anyway I got it off Hendricks on chat a week ago and it did exactly what I wanted, saving many hours of finicky work

Not sure how the mapper who did all that work would feel about me undoing it though...

[LeoD]

After importing maphacks into Mapster's 3D mode via F9, is it possible to save these changes into the map file?

[Hendricks266]

LeoD, on 21 December 2015 - 06:30 AM, said:

After importing maphacks into Mapster's 3D mode via F9, is it possible to save these changes into the map file?

I don't see any mechanism to do this. I would have written an m32script to apply sprites' angoff members to their angles, but it doesn't look like m32script currently has access to spriteext[].

Is angoff the only thing you would want applied? (I don't see what else could be done.)

Helix: If I were to expose spriteext[] to m32script, would you prefer that I add the members to sprite[] (like how the game lumps sprite, hittype, and spriteext into getactor and sprite[]) or would you prefer I add a spriteext[] to the language?

[LeoD]

Hendricks266, on 21 December 2015 - 10:32 AM, said:

Is angoff the only thing you would want applied?

Ideally everything that can be done in maphacks. I might have been less of a nuisance during beta testing Decay if such a feature had been available. I admit that it's a niche application for limited purposes.

[Hendricks266]

mdx/y/zoff, pitch, roll, and flags (notmd, nomdanim, away1/2) are not stored in .map files at all. That leaves angoff and light (which I forgot about earlier). I've never created a Polymer light, so I don't know if all the parameters that the light command takes are covered by an SE light.

[LeoD]

Hendricks266, on 21 December 2015 - 11:24 AM, said:

mdx/y/zoff, pitch, roll, and flags (notmd, nomdanim, away1/2) are not stored in .map files at all.

So it is not possible to have pickups adapted to a sloped ground without maphacks. Important to know for a non-mapper like me. I suppose that the others (except notmd, nomdanim) could be translated from MHK to an M32 script which actually modifies the map.

While we're at it - the mdzoff parameter on floor (and ceiling?) aligned sprites is interpreted differently by Polymost and Polymer.
Vanilla Red 5:


Red 5 + MHK in Polymer renderer:


Red 5 + MHK in Polymost renderer:


Debug MHK attached. Is there a right or wrong, or is it just to be considered as two different legal interpretations?
In the latter case I'd prefer Polymost to be changed, since almost all maphacks are made using Polymer.

Attached File(s)

•  Red5-debug-maphack.zip (605bytes)
  Number of downloads: 566

[Hendricks266]

LeoD, on 21 December 2015 - 11:44 AM, said:

While we're at it - the mdzoff parameter on floor (and ceiling?) aligned sprites is interpreted differently by Polymost and Polymer.

The z offset should be in the same direction as it is without the floor-aligned bit set. Do you know which renderer is correct in this case?

[LeoD]

Hendricks266, on 21 December 2015 - 11:47 AM, said:

The z offset should be in the same direction as it is without the floor-aligned bit set. Do you know which renderer is correct in this case?

Uhm, for not floor aligned sprites I use mdxoff/mdyoff to move them up or down. I could try with a 512-pitched one ....

[LeoD]

LeoD, on 21 December 2015 - 11:53 AM, said:

Uhm, for not floor aligned sprites I use mdxoff/mdyoff to move them up or down. I could try with a 512-pitched one ....

In that case both renderers do the same.

sprite  3049 mdzoff      -4000       // tile0052 sixpack
sprite  3049 pitch       -512        // tile0052 sixpack

Maybe it's not the mdzoff parameter, but a difference in how floor-alignment is implemented, respectively.

[Jblade]

Any word on those increased sound limits btw? Right now we're at 3240 (and you know I'm actually using all of the stuff I ask to add in )

[Helixhorned]

Hendricks266, on 21 December 2015 - 10:32 AM, said:

Helix: If I were to expose spriteext[] to m32script, would you prefer that I add the members to sprite[] (like how the game lumps sprite, hittype, and spriteext into getactor and sprite[]) or would you prefer I add a spriteext[] to the language?

I'd go for the lumping, but that's just for simplicity's sake on your part. I don't really have any strong opinions regarding the evolution of the m32script language as its only use is to enable mappers getting done things quickly that would otherwise require manual labor. Users would have to know that the member is not part of sprite[], but I think we can assume this level of proficiency from the long-time mappers.

[Mark]

As I was working on a bonus map for Decay, the E1L1 remake I showed some pics of last year, I noticed how fast and stuttering the film reels move in the projection room of the cinema. The easy fix if someone wants to add it in officially involves slightly modifying the highres/sprites/props.def file. It slows the reels way down to a more normal speed and by not using the last frame of the animation the stutter disappears. The only values changed were fps 65 to fps 6 and cineline 19 to cineline 18. Its a step in the right direction until it gets replaced with a better model. Hopefully nobody used this reel for something else and the slower speed will ruin their effect. In which case you can use it for yourself if it doesn't get added in officially.

// Cineline (1055)
model "highres/sprites/props/1055_cineline.md3" {
scale 22 shade 6
skin { pal 0 file "highres/sprites/props/1055_cineline.png" }
anim { frame0 "cineline00" frame1 "cineline18" fps 6 flags 0 }
frame { name "cineline00" tile0 1055 tile1 1056 }
}