Duke4.net Forums: Those simple questions thread - Duke4.net Forums

Jump to content

  • 18 Pages +
  • « First
  • 3
  • 4
  • 5
  • 6
  • 7
  • Last »
  • You cannot start a new topic
  • You cannot reply to this topic

Those simple questions thread  "Simple questions, simple answers"

User is offline   Helixhorned 

  • EDuke32 Developer

#121

View PostRichardStorm, on 19 November 2013 - 08:23 AM, said:

Anything odd to know about sprite.extra ? sometimes i get 0 using getactor[whatever].extra... i set it via mapster... nothing overrides extra value ...


For actors, .extra actually holds their strength. For sectors, it's the lotag of a containing GPSPEED sprite, or 256 by default. In any case, I wouldn't use .extra for my own scripting purposes, better simply create a new per-actor gamevar.

Edit: oh, I noticed that getting values via the map is what you want. In that case, you could try putting them into {x,y,z}vel and extracting them at premap (EVENT_LOADACTOR). I think that's the standard procedure other mods handle it as well.
0

User is offline   Fox 

  • Fraka kaka kaka kaka-kow!

#122

Yeah. With eventloadactor you actually can extract the values before any script from the game takes place.
0

#123

How the hell i copypasta sectors with "new" mapster ?

I select both sprites and sectors with Rshift, but C or Ins just double sprites, and not sectors. What i'm missing ???
0

User is offline   Micky C 

  • Honored Donor

#124

It's right alt, not right shift, it's always been like that.
0

User is offline   MetHy 

#125

Selecting sectors with Alt Gr (right alt) doesn't work in the newest mapster. Try an earlier version.

This post has been edited by MetHy: 21 January 2014 - 05:30 AM

1

User is offline   Jblade 

#126

Shit, so it's not just me then? I noticed it but thought it was due to my keyboard or something.
0

User is offline   Daedolon 

  • Ancient Blood God

#127

It's a problem with SDL versions 1.2 and later, EDuke32 switched to 2.0 recently. A fix is coming though.
0

User is offline   Helixhorned 

  • EDuke32 Developer

#128

As suggested in another place, you may want to switch the OS keyboard layout to US before starting Mapster32. This may or may not solve the problem. I don't know why it's happening to you guys; for me it's fine in either Windows or Linux, so I can't debug this.
0

User is offline   neoacix 

#129

View PostHelixhorned, on 21 January 2014 - 08:19 AM, said:

As suggested in another place, you may want to switch the OS keyboard layout to US before starting Mapster32. This may or may not solve the problem. I don't know why it's happening to you guys; for me it's fine in either Windows or Linux, so I can't debug this.


Uhm.... maybe you should stick another keyboard with some foreign layout on your PC to debug this?!
Keycodes on foreign keyboards are not the same as on US-layout, as far as I know.
If I change the layout in my OS, the OS is emulating those codes for me, but mapster with SDL2 is ignoring this emulation, I guess.

So this maybe the reason why everything is fine for you, but not on foreign (non-US) keyboards.

This post has been edited by dpax: 22 January 2014 - 07:01 PM

0

#130

@helix
Ok helix, go buy an italian qwerty keyboard, and start debugging ;) :D just kidding..
0

User is offline   Helixhorned 

  • EDuke32 Developer

#131

View Postneoacix, on 22 January 2014 - 06:50 PM, said:

Uhm.... maybe you should stick another keyboard with some foreign layout on your PC to debug this?!
Keycodes on foreign keyboards are not the same as on US-layout, as far as I know.
If I change the layout in my OS, the OS is emulating those codes for me, but mapster with SDL2 is ignoring this emulation, I guess.

I have a German keyboard, by the way. Anyhow, I don't think it makes sense to reason at such a low level. What matters is what value SDL2 gives on pressing RAlt: in sdlayer.c, at line 2125 as of r4266:
        case SDL_KEYDOWN:
        case SDL_KEYUP:
            code = keytranslation[ev.key.keysym.scancode];

What's the value of ev.key.keysym.scancode? It should be SDL_SCANCODE_RALT (#defined to 230 in SDL2/SDL_scancode.h). Our translation then yields 0xb8, the value that's used for RAlt in mapster32.cfg, among others. If someone can do a quick debugging session by setting a breakpoint at that location and pressing RAlt, that may bring the bug closer to resolution.
0

#132

"MD3 wtf" serie...

I exported a monster into md3 from blender, for a project i'm working on with other guys. It works, but the light wtf :

Attached Image: test1.jpg

-Darkus flashlight code ( as planned in the mod )
-original .obj from the net
-blender 2.68, export script v.2.6 (win7)
-no normal or specular map, just texture.
-light works bad only in front of it

WHAT I'M SUPPOSED TO DO ???

P.S.
I hate how this thing is going on; i'm not supposed to do it cause i'm not a 3d/blender expert, too, but I'm the only who can do it right now unless i (we) find other skilled people.
0

#133

Sorry, but... Bump
0

User is offline   Mark 

#134

I had a skeleton model that didn't light properly with the flashlight. I ran the model through the program called " Npherno". I chose the option to rebuild normals and export it back out. It fixed my problem. If you don't want to go through the trouble of installing and using the program I'll do it for you right away if you attach the model to your post.

EDIT: I waited about 20 minutes and didn't hear back from you. I'm going now to get some dinner. Sorry.

This post has been edited by Mark.: 15 February 2014 - 04:19 PM

1

#135

Oh sry i was logged on this without reading ... i'll try right now with Npherno

EDIT: Used Npherno. Damn, it works. THANKS, i'll build a statue for you Mark. :blink:

This post has been edited by RichardStorm: 15 February 2014 - 04:44 PM

0

User is offline   Mark 

#136

Always happy to help.
0

User is offline   pmw 

#137

Couple versions ago, I had this same problem..now it's back.

I have my eduke in directory D:\Eduke\.
My mapster's location is D:\Eduke\Mapster.exe.

Now, my episode's maps are located in D:\Eduke\episode\1.map, 2.map, 3.map etc.
When I start my Mapster, load example episode\5.map, it works fine.

BUT, when I hit SAVE, mapster saves my map to D:\Eduke\5.map. Not under episode\ (!).

What I'm doing wrong? Or are the old bugs back?


vers:

Mapster32 2.0.0devel r4309 (64-bit)
Compiled Feb 8 2014 06:47:19

This post has been edited by pmw: 16 February 2014 - 11:10 AM

0

User is offline   Helixhorned 

  • EDuke32 Developer

#138

It's a known bug, and I agree that it's annoying. Currently, Mapster32 always saves in the directory that is the current working directory (usually, the one containing the exe on Windows, ~/.eduke32 on Linux). It's partially because a map could have been loaded from other sources than the OS's file system, namely GRP and ZIP files. So, in case it was really loaded from the local FS, we'd need to track that somehow.
0

#139

I bought DN3D megaton Edition a while ago on steam...

Now any eduke32 always recognize that steam folder's Duke3d.grp file, instead of the one inside eduke folder, how to avoid this ?
0

#140

Lil' bump :blink:
0

User is offline   LeoD 

  • Duke4.net topic/3513

#141

View PostRichardStorm, on 21 February 2014 - 04:40 AM, said:

I bought DN3D megaton Edition a while ago on steam...

Now any eduke32 always recognize that steam folder's Duke3d.grp file, instead of the one inside eduke folder, how to avoid this ?
eduke32.exe -usecwd
0

User is offline   pmw 

#142

Why new mapsters are changing top/bottom orientation of textures when I use . <- button for auto-aligning?
In earlier versions, it was fine, now it messes up everything.

Is this a bug, or just someone's "great" idea to change something which worked fine?
0

User is offline   pmw 

#143

I don't know does anyone read this topic...but my question belongs here:

Is there any way to avoid this problem:

Posted Image
Posted Image

I've made a table of sprites. I can see concrete sprite block from under the table -- not always, but from sometimes.
Same thing if I made a real red line block there, I can see it trough sprites.

Is there any way to avoid this?
0

User is offline   Daedolon 

  • Ancient Blood God

#144

Stop using the shitty 8bit renderer.

Or make the base out of sectors.

This post has been edited by Daedolon: 15 June 2014 - 03:45 PM

-1

User is offline   pmw 

#145

I'm never gonna stop using 8bit renderer.
What you mean by "base out of sectors"?

View PostDaedolon, on 15 June 2014 - 03:43 PM, said:

Stop using the shitty 8bit renderer.

Or make the base out of sectors.

2

User is offline   Gambini 

#146

View PostDaedolon, on 15 June 2014 - 03:43 PM, said:

Stop using the shitty 8bit renderer.

Or make the base out of sectors.


Making the base out of a sector would expose similar glitches.

Quote

Is there any way to avoid this problem:
The order in which the sprites are drawn is directed from their "origin" distance to the player. Think of that when building your spritework. For that table I´d use more and shorter sprites for the edges and the upper part.
1

User is offline   Forge 

  • Speaker of the Outhouse

#147

View Postpmw, on 15 June 2014 - 03:32 PM, said:

I've made a table of sprites. I can see concrete sprite block from under the table -- not always, but from sometimes.
Same thing if I made a real red line block there, I can see it trough sprites.

Is there any way to avoid this?

make the base out of sector work (red line walls for the box). & raise it until it is the height of the table top. texture the same as the table top.
put sprites around the box, but don't allow any part of the sprites to cross the box's sector lines that you don't want to disappear.

if the player can view a sector that has a sprite partially entered into it while at the same time they can no longer see the center of said sprite, you'll get those clipping out issues.

View PostGambini, on 15 June 2014 - 04:30 PM, said:

Making the base out of a sector would expose similar glitches.

The order in which the sprites are drawn is directed from their "origin" distance to the player. Think of that when building your spritework. For that table I´d use more and shorter sprites for the edges and the upper part.

^-this
____________
|...................|
|........|..........|<-sprite always stays in view on this side of the sector line because
|........O.........| the center of the sprite is on this side
|---------------|----------<-red sector line
|...................|
|___________|<-the part of the sprite on this side will clip out of sight if player stands close to or on the sector line - the sector that's clipping though from underneath is getting drawn at a different time than the sprite that makes up the table top because of distances between the player, the center of the sprite, and the sector that makes up the table base.

This post has been edited by Forge: 15 June 2014 - 05:36 PM

1

User is offline   pmw 

#148

Thanks for advice.

Now these really kicks ass:
Posted Image
3

User is offline   The Commander 

  • I used to be a Brown Fuzzy Fruit, but I've changed bro...

#149

Those walls really need attending to...
0

User is offline   Mike Norvak 

  • Music Producer

#150

View PostThe Commander, on 18 June 2014 - 06:07 PM, said:

Those walls really need attending to...


You can tell by the look of the entire shot, that those walls are unfinished...
0

Share this topic:


  • 18 Pages +
  • « First
  • 3
  • 4
  • 5
  • 6
  • 7
  • Last »
  • You cannot start a new topic
  • You cannot reply to this topic


All copyrights and trademarks not owned by Voidpoint, LLC are the sole property of their respective owners. Play Ion Fury! ;) © Voidpoint, LLC

Enter your sign in name and password


Sign in options